RE: Algorithm revocation

["Bland, Graham" <Graham.Bland@xxxxxxxxxxxxxxx>]

Sonke,

Comments in line:

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:maseberg@xxxxxxxxxxxxxxxx]
Sent: 21 February 2001 10:02
To: tgindin@xxxxxxxxxx; ietf-pkix@xxxxxxx
Subject: Re: Algorithm revocation


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.

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.

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.

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?  

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.

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.
_______________________________________________________________________