Re: Algorithm revocation

[Soenke Maseberg <maseberg@xxxxxxxxxxxxxxxx>]

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