Joel: If access to the key is lost, the commitment is broken, so the Root CA must make a fresh start using a completely unrelated key. Maybe the word "remedy" is creating the wrong impression for you.
Russ > On Jan 4, 2019, at 6:42 PM, [email protected] wrote: > > 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 > > _______________________________________________ > Spasm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
