Folks:
To me re-keying means issuing a new certificate to the same DN.
-----Original Message-----
From: Tony Bartoletti [mailto:azb@xxxxxxxx]
Sent: Wednesday, June 13, 2001 2:07 PM
To: jim; Santosh Chokhani
Cc: Scherling, Mark; thayes@xxxxxxxxxxxx; 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 <azb@xxxxxxxx>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900