Re: Algorithm revocation

["Tom Gindin" <tgindin@xxxxxxxxxx>]

     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 <maseberg@xxxxxxxxxxxxxxxx>@mailserver1.hrz.tu-darmstadt.de
on 02/20/2001 08:36:26 AM

Sent by:  maseberg@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


To:   Tom Gindin/Watson/IBM@xxxxx, ietf-pkix@xxxxxxx
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