Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BE91310C4 for ; Sun, 6 Jan 2019 16:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WfzK2yLjeSx for ; Sun, 6 Jan 2019 16:35:01 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD95129AB8 for ; Sun, 6 Jan 2019 16:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EBEF300AA2 for ; Sun, 6 Jan 2019 19:07:20 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2ni3bPq5cuKF for ; Sun, 6 Jan 2019 19:07:15 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id EBE483001B2; Sun, 6 Jan 2019 19:07:14 -0500 (EST) From: Russ Housley Message-Id: <236EE9E9-4525-4309-B237-400CB19BAC94@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 6 Jan 2019 19:25:31 -0500 In-Reply-To: <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> Cc: Joel Halpern , LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF To: Stephen Farrell References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 00:35:03 -0000 --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 >=20 > Hi Russ, >=20 > 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. >=20 > 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.) >=20 > Cheers, > S. >=20 > On 06/01/2019 19:25, Russ Housley wrote: >> Joel: >>=20 >> I propose a replacement paragraph. I hope it is more clear on the = points raised on this thread: >>=20 >> 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. >>=20 >> Let me know if this helps... >>=20 >> Russ >>=20 >>=20 >>> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern = wrote: >>>=20 >>> 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. >>>=20 >>> Yours, >>> Joel >>>=20 >>> 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 = wrote: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> 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, jmh.direct@joelhalpern.com = wrote: >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Joel >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>>>>>=20 >>>>>>> -------- Original message -------- >>>>>>> From: Russ Housley > >>>>>>> Date: 1/4/19 17:57 (GMT-05:00) >>>>>>> To: Joel Halpern > >>>>>>> Cc: IETF Gen-ART >, = spasm@ietf.org , = draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org = , IETF = > >>>>>>> Subject: Re: Genart last call review of = draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>>>=20 >>>>>>> Joel: >>>>>>>=20 >>>>>>> Thanks for the review. >>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> Summary: This draft is nearly ready for publication as an = Informational RFC. >>>>>>>>=20 >>>>>>>> Major issues: N/A >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Does that help? If so, what would make the paragraph more = clear? >>>>>>>=20 >>>>>>> Russ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Spasm mailing list >>>>>>> Spasm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/spasm >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXDKcewAKCRCK5O7Q9ZwR y0iKAKCt6t85y2UuOwmM8ng0WLBR3/MlZQCdHVMLFjtk1w9vtCqouoYLcbx6EC8= =BSiS -----END PGP SIGNATURE----- --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218--