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 <[email protected]> Date: 1/4/19 17:57 (GMT-05:00) To: Joel Halpern <[email protected]> Cc: IETF Gen-ART <[email protected]>, [email protected], [email protected], IETF <[email protected]> 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
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
