Subject: [lamps] AD Review of draft-ietf-lamps-hash-of-root-key-cert-extn

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Dec 2018 15:26:38 -0800

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12208

This looks basically good. One issue we should discuss.

COMMENTS
S 2.
>      The successors to the Root CA self-signed certificate can be
>      delivered by any means.  Whenever a new Root CA certificate is
>      received, the recipient is able to verify that the potential Root CA
>      certificate links back to a previously authenticated Root CA
>      certificate with the hashOfRootKey certificate extension.  That is,
>      validate the self-signed signature and verify that the hash of the

Nit: I think you want to "verify" the signature. With that said, is
that necessary?

S 5.
>      Guidance on the transition from one trust anchor to another is
>      available in [RFC2510].  In particular, the oldWithNew and newWithOld
>      advice ensures that relying parties are able to validate certificates
>      issued under the current Root CA certificate and the next generation
>      Root CA certificate throughout the transition.  Further, this
>      technique ovoids the need for all relying parties to make the

Nit: "avoids"

---

From: Russ Housley <[email-masked]>
Date: Sat, 22 Dec 2018 12:35:35 -0500

Eric:
> https://mozphab-ietf..devsvcdev.mozaws.net/D12208 <https://mozphab-ietf.devsvcdev.mozaws.net/D12208>
> 
> 

Yes, I think both checks are needed.

Are you asking me to change "validate" to "verify"?  If so, I would say: "verify the signature on the self-signed certificate."

> >      technique ovoids the need for all relying parties to make the

Yes, that is a typo.  I will correct it.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Dec 2018 06:28:22 -0800

On Sat, Dec 22, 2018 at 9:35 AM Russ Housley <[email-masked]> wrote:

> https://mozphab-ietf..devsvcdev.mozaws.net/D12208
> <https://mozphab-ietf.devsvcdev.mozaws.net/D12208>
>
>
> Are you asking me to change "validate" to "verify"?  If so, I would say:
> "verify the signature on the self-signed certificate."
>

I think that would be clearer. However, it would be useful to lay out why
you think this is necessary. Is the idea that an attacker could substitute
a new trust anchor with different metadata?

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Dec 2018 10:10:22 -0500

> On Dec 24, 2018, at 9:28 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Sat, Dec 22, 2018 at 9:35 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Eric:
>> 
> I think that would be clearer. However, it would be useful to lay out why you think this is necessary. Is the idea that an attacker could substitute a new trust anchor with different metadata?

If the subject public key matches the hash, but the signature on the certificate is not checked, then an arbitrary Root CA distinguished name could be provided.  Checking the signature makes sure the name that the key owner intends is used.  This is important for path validation.

Russ