Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn

[Jim Schaad <[e-mail]>]

Yes that satisfies my concern.

 

From: Russ Housley <[e-mail]> 
Sent: Tuesday, November 6, 2018 6:07 PM
To: Jim Schaad <[e-mail]>
Cc: SPASM <[e-mail]>
Subject: Re: [lamps] WG Last call:
draft-ietf-lamps-hash-of-root-key-cert-extn

 

Jim:

 

* Section 2 - What operational considerations are there for when to
retire the old Root CA certificate when a new one has been
discovered and is to be used?


I'm not sure what you are requesting.  Install the new one, and
remove the old one?


When you install the new one, I don't believe that you are going to
remove the old one.  There are still going to be valid certificates
running around that will chain to the old root until you have done all
of the issuing of certificates to the new root.  This is going to take
time.  Additionally, if you are looking at something like the mail
case you want to keep the old root but mark it as being "expired" so
that you can validate the chain of certificates.


If one follows the old-with-new and new-with-old advice in RFC 2510, then
the replacement should not cause any disruption.  If you think it is useful,
an

operational consideration about this can be added.




This means that it might be some time before the old one is removed.


It should not need to linger...


Since it was not obvious to me, then yes the hint should be included.

 

Does this text address your concern:

 

5.  Operational Considerations

 

   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

   transition at the same time.

 

Russ