Subject: RE: key update - problem

From: Carlisle Adams <[email-masked]>
Date: Wed, 15 Mar 2000 13:30:12 -0500

Hi Pat,

> ----------
> From: 	Patrick G. Moore[SMTP:[email-masked]]
> Sent: 	Tuesday, March 14, 2000 5:23 PM
> To: 	Carlisle Adams; [email-masked]
> Subject: 	Re: key update - problem
> 
> Carlisle Adams wrote:
> > 
> > When doing a key update it is not necessary to supply the old public key
> and
> > to prove possession of the old private key all over again.  In the
> request
> > for a certificate for the new key pair, it is sufficient to put a
> pointer to
> > the old certificate that is being updated/replaced.  This is the purpose
> of
> > the OldCertId control (see Section 6.5 of RFC 2511).
> > 
> > The key update request needs to contain the new public key and POP for
> the
> > new private key, but need not contain anything pertaining to the old
> > certificate beyond this pointer.
> > 
> > Carlisle.
> 
> Hi Carlisle,
> 
> RFC 2510 says to use a secure transport for requests.  I would think, for
> POP
> of an old key, you could put the update request in the body of a signed
> S/MIME
> message, signed with the old cert.  Are there any profiles defined for CMP
> over
> different transports, like S/MIME, http, FTP etc..., which address this
> issue?
> It seems appropriate for key updates, so that an imposter can't request a
> new
> key
> for an existing cert.
> 
> Pat
 
Perhaps my (slightly hasty) answer was not sufficiently clear.  What I meant
to convey was that the key update request itself (i.e., the CertReqMsg in
RFC 2511) need not contain anything pertaining to the old certificate
(including POP of the old private key), with the possible exception of the
OldCertId control.

However, the key update request is a PKIBody, framed by PKIHeader and
PKIProtection fields (and perhaps extraCerts) to form the full PKIMessage.
In typical use, the key update request (i.e., this request for a replacement
certificate) will be signed by the private key corresponding to the current
certificate.  That is, the PKIHeader protectionAlg will contain a
MSG_SIG_ALG and PKIProtection will contain a digital signature created using
the (current / soon-to-be-old) private key.  In a sense this might be
considered to be POP of the old key but, more correctly, it is simply strong
authentication of the update request message (which avoids the
impostor-requesting-a-new-key-for-an-existing-cert problem).

Carlisle.

---

From: "Patrick G. Moore" <[email-masked]>
Date: Wed, 15 Mar 2000 14:53:54 -0500

Thanks Carlisle,

I should have read more carefully.  It seemed strange to me that
the Certificate Management Protocol wasn't self-contained in
this regard.

Pat