Stephen: I have text about the need for backup in the Operational Consideration, which includes the point that HSMs fail.
I have text about the significant advance in cryptoanalytic capabilities in the Security Considerations. Russ > On Jan 6, 2019, at 6:03 PM, Stephen Farrell <[email protected]> wrote: > > > Hi Russ, > > I should probably re-read the draft after the latest changes > but ISTM that the crypto-break reason for problems here is > far far less likely than the mucked-up-HSM reason. I think > that means that calling out the more likely reason is perhaps > a better plan. > > In addition, (and this is the bit I need to ponder), if the > lifetime of a root key associated with one of these hashes > (or commitments/pins) is say 10 years, then I'd say that may > make a HSM muck-up sufficiently likely that more than just > clarifying text might be needed. For example, perhaps one > might say that this extension SHOULD only be used if a new > key will go live within a couple of years or something like > that. As I said, I'll re-read the latest draft and see if > I can suggest some text. (Separately, if anyone has some > experience of the relative (in)stability of backup CA keys > over that kind of duration, then that'd be useful information.) > > Cheers, > S. > > On 06/01/2019 19:25, Russ Housley wrote: >> Joel: >> >> I propose a replacement paragraph. I hope it is more clear on the points >> raised on this thread: >> >> The Root CA needs to ensure that the public key in the next >> generation certificate is as strong or stronger than the key that it >> is replacing. Of course, a significant advance in cryptoanalytic >> capability can break the yet-to-be-deployed key pair. Such advances >> are rare and difficult to predict. If such an advance occurs, the >> Root CA remains committed to the now broken key. This leaves the >> Root CA with no alternative but to deploy a new self-signed >> certificate that contains a newly-generated key pair, most likely >> using a different signature algorithm, in the same manner as the >> initial self-signed certificate, thus losing the benefits of the Hash >> Of Root Key certificate extension altogether. >> >> Let me know if this helps... >> >> Russ >> >> >>> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern <[email protected]> wrote: >>> >>> Maybe I am missing something simple, but I do not see where the text in >>> section 5 on dealing with a lost promised key says anything about the need >>> to "go through the process that was used to set up the initial trust >>> anchor." All it seems to say is "to deploy a new self-signed certificate." >>> Maybe what is needed is a little elaboration on what that deployment is to >>> be, as it is not the same as deploying a properly promised new key pair. >>> >>> Yours, >>> Joel >>> >>> On 1/6/19 12:09 PM, Russ Housley wrote: >>>> 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 >> >> > <0x5AB2FAF17B172BEA.asc>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
