RE: Online Certificate Revocation Protocol

[Santosh Chokhani <[e-mail]>]

Folks:

To me re-keying means issuing a new certificate to the same DN. 

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Wednesday, June 13, 2001 2:07 PM
To: jim; Santosh Chokhani
Cc: Scherling, Mark; [e-mail]; Ietf-Pkix
Subject: Re: Online Certificate Revocation Protocol



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 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900