Subject: Re: Algorithm revocation

From: "Tom Gindin" <[email-masked]>
Date: Tue, 20 Feb 2001 10:53:04 -0500

There are two reasons IMO why "revokedAlgorithms" does not belong in
the base CRL structure.  First, a CA is not authoritative for the
revocation status of an algorithm or key length in the way in which it is
authoritative for the revocation of certificates it issued; two CA's can
easily disagree about whether RSA-768 is usable for digital signatures and
it is up to the RP software to decide which to trust.  I myself would make
a "revokedAlgorithms" extension non-critical, since its main effect would
be to issue warnings to distributed RP's that "your trusted server thinks
that you should stop trusting keys like these, in case you hadn't heard".
Second, as a practical matter, adding an extension will not break existing
software in the way that adding a new field to the base structure will.
     It is true that timestamps using a compromised algorithm are
themselves compromised.  However, the basic rule behind a pyramided set of
timestamps is that if there is no time T at which ALL of the keys used for
signatures in the set with timestamps before T had been compromised, then
the set has not been compromised.  Since the compromise of an algorithm is
a public event, it is much easier to support a statement that "no
compromise occurred before time T1" for an algorithm compromise than for an
individual key compromise.
     I don't really want to get into multiply-signed CRL's.  It makes
better sense IMHO for the CA to generate the same TBSCertList, sign it with
each of the multiple keys, and publish them under the same attribute.  This
would be more efficient over the network if the client used the internal
value filtering that you may have seen discussed last month on this list
(especially in the messages entitled "Certificate Matching"), and in
draft-legg-ldapext-component-matching-00.txt.

          Tom Gindin

Soenke Maseberg <[email-masked]>@mailserver1.hrz.tu-darmstadt.de
on 02/20/2001 08:36:26 AM

Sent by:  [email-masked]

To:   Tom Gindin/Watson/IBM@IBMUS, [email-masked]
cc:
Subject:  Re: Algorithm revocation

Hi.

Tom Gindin wrote:

>     I don't see the point of having entry extensions inside
> revokedAlgorithms, nor do I see any need to extend the base CRL structure
> for them.  The criticality of this extension as a whole is a matter of
> opinion.

minimumSafeKeyBits is a good idea. But I think, revokedAlgorithms is at the
same level as revokedCertificates.
What about the following extensions of Certificate and CRL Profile)
[<draft-ietf-pkix-new-part1-04.txt>]?

  CertificateList  ::=  SEQUENCE  {
      tbsCertList            TBSCertList,
      signatureAlgorithm     AlgorithmIdentifier,
      signatureValue         BIT STRING,
      additionalsignatures   SEQUENCE OF SEQUENCE {           --EXTENSION
         signatureAlgorithm     AlgorithmIdentifier,
         signatureValue         BIT STRING
         }  OPTIONAL
      }

  TBSCertList  ::=  SEQUENCE  {
      version                Version OPTIONAL,
      signature              SEQUENCE OF AlgorithmIdentifier,  --
EXTENSION
      issuer                 Name,
      thisUpdate             Time,
      nextUpdate             Time OPTIONAL,
      revokedCertificates    SEQUENCE OF SEQUENCE  {
         userCertificate        CertificateSerialNumber,
         revocationDate         Time,
         crlEntryExtensions     Extensions OPTIONAL
         }  OPTIONAL,
      crlExtensions          [0]  EXPLICIT Extensions OPTIONAL,
      revokedAlgorithms      [1]  SEQUENCE OF CompromisedAlgorithm
OPTIONAL      -- EXTENSION
      }

   CompromisedAlgorithm ::= SEQUENCE {
      signatureAlgorithm      AlgorithmIdentifier,
      minimumSafeKeyBits      INTEGER DEFAULT 1000000000,  -- or any very
large number
                           -- would a combination of { KeyUsage flag, Size
}
be more useful?
      revocationDate          Time,
      explanatoryText         UTF8String OPTIONAL
      }

> However, signed timestamp pyramiding ought to protect against later
> compromises of algorithms which are not believed to be questionable at
the
> time of the OCSP check.

The problem of timestamps occurs if they uses the compromised signature
algorithm too.

Regards,
Sönke

---

Sönke Maseberg
Dipl.-Math.

GMD - Institut für Sichere Telekooperation
Rheinstr. 75, D-64295 Darmstadt
Tel: 06151/869-60036, Fax: 06151/869-224

Technische Universität Darmstadt
Institut fuer Theoretische Informatik
Lehrstuhl Prof. J. Buchmann
Alexanderstr. 10, D-64283 Darmstadt

---

From: Sönke Maseberg <[email-masked]>
Date: Wed, 21 Feb 2001 11:02:14 +0100

Tom,

I would like to quote 'PKIX Roadmap - March 10, 2000'
[<draft-ietf-pkix-roadmap-05.txt>] part 3.5.6.4 Revocation

 When a PKC is issued, it is expected to be in use for its entire
 validity period. However, various circumstances may cause a PKC to
 become invalid prior to the expiration of the validity period. Such
 circumstances include change of name, change of association between
 subject and CA (e.g., an employee terminates employment with an
 organization), and compromise or suspected compromise of the
 corresponding private key. Under such circumstances, the CA needs to
 revoke the PKC.

Under the assumption that a signature algorithm is compromised suddenly,
the CA have to revoke all of the certificates that use this algorithm.
And if the CA has a lot of CHs the CRL would be very large and not
practically to handle. So IMO 'revokeAlgorithms' would be a possibility
to revoke implicitly all shocked certificates.

The basic rule behind a pyramided set of timestamps is good if not the
same signature algorithm for all signatures is used. Otherwise if the
signature algorithm is compromised at time you cannot proof the time of
creation of a signature.

Sönke

---

From: "Bland, Graham" <[email-masked]>
Date: Wed, 21 Feb 2001 13:53:43 -0000

Sonke,

Comments in line:

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 21 February 2001 10:02
To: [email-masked]; [email-masked]
Subject: Re: Algorithm revocation

Tom,

The example you quote covers the compromise of a private key i.e. its
disclosure or suspected disclosure. I do not believe it was intended to
cover the total and sudden compromise of an algorithm where the CA
certificate is also compromised.

It is extremely unlikely that an algorithm is suddenly compromised, a far
more likely scenario is that over time the strength of the algorithm with a
given key length is reduced.  I think all would agree that 40 bit DES is
compromised.  However I am certain that a large proportion of internet
browsers still only support 40 bit DES.  If you were responsible for the
operations of a CA would you now refuse to issue 40 bit SSL certificates?.
If so at what point in time would you have made that decision and what
criteria would you use to justify it?  

I agree, if you require this then you must implement multiple time stamping
services and select on the basis of the signature algorithm required.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________