Joel: As the text already says, the Root CA will need to go through the process that was used to set up the initial trust anchor. The relying party will not accept the new self-signed certificate until that is done, and that process is completely disconnected from the previous certificate.
The paragraph we are discussing is all about handling a failure, and the new certificate extension is not offering any assistance if the failure occurs. That is what the paragraph is trying to say. Russ > On Jan 4, 2019, at 10:10 PM, Joel M. Halpern <[email protected]> wrote: > > I understand that the issuer has no choice. > What I can't see is how any validator will accept the new certificate. > The new cert will fail the validation check required by the field in the > existing certificate. > So it seems that the only remedy is to wait until the exist certificate > expires, so that the hash is no longer valid, and then a new cleann cert can > be issued that will be accepted. > > But there is no reference in the "remedy" to waiting for the expiration. > In fact, it is only imiplictly stated that the hash expectation is no longer > valid once the certificate is expired. > > Another possibility is that I am completely missing the point of the new > field. If the new clean unexpected cert will be accepted, what behavior is > improved by having the hash in the current cert. > > Yours, > Joel > > On 1/4/19 9:41 PM, Russ Housley wrote: >> 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] >>> <mailto:[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] <mailto:[email protected]>> >>> Date: 1/4/19 17:57 (GMT-05:00) >>> To: Joel Halpern <[email protected] <mailto:[email protected]>> >>> Cc: IETF Gen-ART <[email protected] <mailto:[email protected]>>, >>> [email protected] <mailto:[email protected]>, >>> [email protected] >>> <mailto:[email protected]>, IETF >>> <[email protected] <mailto:[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] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
