Re: [Gen-art] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

["[e-mail]" <[e-mail]>]

If the new self-signed cert uses a new key, wouldn't that be rejected as violating the promise in the current cert?  I am missing something.
Thanks,Joel


Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Russ Housley <[e-mail]> Date: 1/4/19  17:57  (GMT-05:00) To: Joel Halpern <[e-mail]> Cc: IETF Gen-ART <[e-mail]>, [e-mail], [e-mail], IETF <[e-mail]> Subject: Re: Genart last call review of
  draft-ietf-lamps-hash-of-root-key-cert-extn-03 
Joel:

Thanks for the review.

> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
> Reviewer: Joel Halpern
> Review Date: 2019-01-04
> IETF LC End Date: 2019-01-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This draft is nearly ready for publication as an Informational RFC.
> 
> Major issues: N/A
> 
> Minor issues:
>    The explanation at the end of section 5 about the remedy for losing access
>    to the new root key left me confused.
> It looks like the situation is that there is a certificate out there, with the
> hash of root key extensions. The certificate owner loses access to the new key
> pair underlying the hash. The certificate owner clearly has to issue a new key
> pair.  So far, so good.
> 
> What the text seems to say is to simply issue a new self-signed certificate. 
> There are two possibilities for what is intended. I think the idea is that the
> new certificate will use the existing key pair (not the promised one, nor
> another new one) for its own signature, and include a new hash of root key for
> the newly generated pair.  If the certificate owner can do that (I have not
> dived into the rest of the certificate operations to figure out if that is
> legal) then it works.  Please add some words explaining that better. If the
> certificate owner can not simply issue a new self-signed certificate with the
> existing key pair, then I am lost.  It appears that the text says that the
> certificate owner issues a new self-signed certificate using a new key pair. 
> But that will fail the check against the previous certificate hash of root key.
> I am hoping that it is the first of these alternatives, and all that is needed
> is clearer explanatory text stating that the new cert uses the existing key
> pair, and includes a new hash of root key promise.

Joel, the Root CA want to start using a different key par, but they have lost access to the one that was previously generated for that purpose.  So, the remedy is to create a new self-signed certificate with a newly generated key.

Does that help?  If so, what would make the paragraph more clear?

Russ