Subject: Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

From: Joel Halpern <[email-masked]>
Date: Fri, 04 Jan 2019 13:20:36 -0800

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.

Nits/editorial comments:  N/A

---

From: Russ Housley <[email-masked]>
Date: Fri, 4 Jan 2019 17:57:19 -0500

Joel:

Thanks for the review.

> 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

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 04 Jan 2019 18:42:09 -0500

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-masked]> Date: 1/4/19  17:57  (GMT-05:00) To: Joel Halpern <[email-masked]> Cc: IETF Gen-ART <[email-masked]>, [email-masked], [email-masked], IETF <[email-masked]> Subject: Re: Genart last call review of
  draft-ietf-lamps-hash-of-root-key-cert-extn-03 
Joel:

Thanks for the review.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 4 Jan 2019 21:41:15 -0500

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-masked] wrote:
> 
> Thanks,
> Joel
> -------- Original message --------
> From: Russ Housley <[email-masked]>
> Date: 1/4/19 17:57 (GMT-05:00)
> To: Joel Halpern <[email-masked]>
> Cc: IETF Gen-ART <[email-masked]>, [email-masked], [email-masked], IETF <[email-masked]>
> Subject: Re: Genart last call review of   draft-ietf-lamps-hash-of-root-key-cert-extn-03
> 
> Joel:
> 
> Thanks for the review.
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Jan 2019 22:10:14 -0500

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-masked] 
>> <mailto:[email-masked]> 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
>>
>>
>>
>> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
>> To: Joel Halpern <[email-masked] <mailto:[email-masked]>>
>> Cc: IETF Gen-ART <[email-masked] <mailto:[email-masked]>>, 
>> [email-masked] <mailto:[email-masked]>, 
>> [email-masked] 
>> <mailto:[email-masked]>, 
>> IETF <[email-masked] <mailto:[email-masked]>>
>> Subject: Re: Genart last call review of   
>> 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.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Sun, 6 Jan 2019 12:09:11 -0500

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-masked]> wrote:
> 
> 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.
> 
> 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 Jan 4, 2019, at 6:42 PM, [email-masked] <mailto:[email-masked]> wrote:
>>> 
>>> Cc: IETF Gen-ART <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>, IETF <[email-masked] <mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Jan 2019 12:27:15 -0500

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

---

From: Russ Housley <[email-masked]>
Date: Sun, 6 Jan 2019 14:25:19 -0500

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-masked]> 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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Jan 2019 17:45:59 -0500

Good enough.
I suspect that any effort to refine further would be overkill, given 
that this is expected to be a rare case.
I think the small addition should be enough to alert any implementor or 
deployer to the challenges they might face.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Jan 2019 23:03:20 +0000

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.

---

From: Russ Housley <[email-masked]>
Date: Sun, 6 Jan 2019 19:25:31 -0500

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-masked]> wrote:
> 
> 
> Hi Russ,
> 
> <0x5AB2FAF17B172BEA.asc>