Re: Algorithm revocation
"Tom Gindin" <tgindin@us.ibm.com> Tue, 20 February 2001 15:55 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14561 for <pkix-archive@odin.ietf.org>; Tue, 20 Feb 2001 10:55:48 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA22064; Tue, 20 Feb 2001 07:54:52 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Feb 2001 07:53:27 -0800
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA21708 for <ietf-pkix@imc.org>; Tue, 20 Feb 2001 07:53:26 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA252926; Tue, 20 Feb 2001 10:52:21 -0500
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA42310; Tue, 20 Feb 2001 10:49:37 -0500
Importance: Normal
Subject: Re: Algorithm revocation
To: Soenke Maseberg <maseberg@darmstadt.gmd.de>
Cc: ietf-pkix@imc.org
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF6787E633.706C37B8-ON852569F9.005262A8@somers.hqregion.ibm.com>
From: Tom Gindin <tgindin@us.ibm.com>
Date: Tue, 20 Feb 2001 10:53:04 -0500
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.6a |January 17, 2001) at 02/20/2001 10:53:25 AM
MIME-Version: 1.0
Content-type: text/plain; charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA21711
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA22064
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14561
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@darmstadt.gmd.de>@mailserver1.hrz.tu-darmstadt.de on 02/20/2001 08:36:26 AM Sent by: maseberg@mailserver1.hrz.tu-darmstadt.de To: Tom Gindin/Watson/IBM@IBMUS, ietf-pkix@imc.org 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
- Re: Algorithm revocation Tom Gindin
- Re: Algorithm revocation Soenke Maseberg
- Re: Algorithm revocation Tom Gindin
- Re: Algorithm revocation Stephen Kent
- Re: Algorithm revocation Sönke Maseberg
- Re: Algorithm revocation Sönke Maseberg
- RE: Algorithm revocation Bland, Graham
- Re: Algorithm revocation Stephen Kent
- Re: Algorithm revocation Joerg Seidel
- Re: Algorithm revocation Sönke Maseberg
- Re: Algorithm revocation Joerg Seidel
- Re: Algorithm revocation maseberg