Re: Online Certificate Revocation Protocol

[Tony Bartoletti <azb@xxxxxxxx>]

At 10:09 AM 6/13/01 -0400, jim wrote:
> I have to jump in again.  Mark is correct.  Remember that we are talking a 
> Certification Revocation List (CRL).  This is vastly different than a 
> Compromised Key List (CKL).  We place a certificate on the CRL because 
> there is a larger problem other than just the signing key.  If the token 
> set is damaged or destroyed (this is a good place to insert Bob's 
> reflection on bent keys), the cert needs to be added to the CRL.  If there 
> is some way to ensure that only a keyset is damaged, the cert can be 
> rekeyed so that service for the DN continues.  It specifically does come 
> back to the concern of knowing what is considered destroyed and what is 
> considered bent.  Since I have not seen the equivalent of a CKL in the 
> IETF world, I have to assume that the only way to truly cancel usage of a 
> key is either to put the cert on the CRL or to rekey the cert so that the 
> old key is no longer valid.  The question becomes how to demonstrate that 
> a key has been invalidated without invalidating the DN or cert.
>
> I think Santosh and I agree that the question is one of trust as to 
> whether the key is truly destroyed as opposed to being unusable to the 
> user, but the issuing authority still has the responsibility for making 
> that determination and if needed, revoking the cert to invalidate the 
> key.  There is a fine line between what happens technically and what needs 
> to happen procedurally.  Thus, I still side with Mark and the proponents 
> of transaction notarization (accomplishable through a retrievable audit 
> trail) as a better, more secure process.  I am not arguing about what 
> needs to happen as far as the technical capability of key management, but 
> from the risk mitigation standpoint, which is what business needs to deal 
> with.  They need to have an electronic system that is as inherently secure 
> as their paper system or PKI will never get off the ground.
>
> Jim

A (X.509) certificate is a CAs attestation of a given key->DN 
binding.  Thus, a new key *dictates* a new and different certificate.

This is the first time I've come across the terminology "the cert can be 
rekeyed".  This is a curious turn of phrase!  It sounds like "we changed 
the key, but don't fret, the *certificate* remains the same."

To my understanding, rather than "rekey a cert", you want to "recertify a DN".

___tony___





Tony Bartoletti 925-422-3881 <azb@xxxxxxxx>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900