Subject: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

From: Adam Montville <[email-masked]>
Date: Tue, 08 Jan 2019 06:16:12 -0800

Reviewer: Adam Montville
Review result: Ready

This draft is ready. It's a clever (though not foolproof) way to prime the pump
for root certificate updates. I'm not an ASN.1 expert, so I can't really opine
on the structure in Section 3, but from what I can tell it looks sane.
Operational considerations seems sane. Security considerations rely on those
from RFC5280, and additionally addresses: 1) analysis before the
next-generation root certificate is released, 2) key strength considerations
(equal or greater than current), 3) unforeseen cryptoanalytic advances, 4)
typical hash pre-image attacks, and 5) early release of the next-generation
public key.

One area in the security considerations that could be enhanced is the
recommended action to take in the case of an early next-generation public key
release. The language in the draft states: "The second transition occurs when
the Root CA is confident that the population of relying parties have completed
the first transition, and it takes the Root CA to the freshly generated key
pair." The question that came to mind was: What might bring about such
confidence? I'm not sure that it's possible to generalize an answer to that
question, however.

Kind regards,

Adam

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Jan 2019 12:33:45 -0500

> On Jan 8, 2019, at 9:16 AM, Adam Montville <[email-masked]> wrote:
> 
> Reviewer: Adam Montville
> Review result: Ready
> 

Adam:

Thanks for the review.

I can assure you that I compiled the ASN.1 module.

This paragraph is the result of the discussion in the LAMPS WG session in London.  The timing is not that critical if the oldWithNew and newWithOld advice from RFC 2510 (updated to RFC 4210) is followed.  This is talked about in Section 5 on "Operational Considerations".  I have an update to the paragraph in Section 5 based on other comments:

   Guidance on the transition from one trust anchor to another is
   available in Section 4.4 of [RFC4210].  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 advice avoids the need for all relying
   parties to make the transition at the same time.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 08 Jan 2019 13:55:28 -0500

>    parties to make the transition at the same time.

I'm not convinced that this analysis is correct, as i tried to explain
in more detail in Message-Id: <[email-masked]>.

I hope my analysis in that e-mail is wrong, but i've received no
feedback on it yet.

Maybe some additional guidance about which parties should ship which
certificates in which contexts would clarify matters?  Or maybe i'm just
missing something obvious to other people -- i'd be happy to see a
clarification.

Regards,

         --dkg