[...] > > > A possible work around I can see here is to allow for some time between > steps 3 and 4 of the process described in the res-certs document, and > publish the NEW certificate before activating it. This could give > relying parties time to use the new certificate as another TA next to > the 'current' certificate. But like I said, I think this makes the whole > system more complicated.
what was _not_ documented in the notes in the res-certs drafts was for the entity performing the key rollover to wait for <a period> between steps 3 and 4 to allow the NEW CA certificate to be published and to allow Relying Parties to collect this certificate and load it into their local cache. That way, when the NEW CA executes step 5, replying parties will be in a position to recognise these subordinate objects as valid. Some previous thoughts of the appropriate value of the period was 24 hours, assuming that Relying Parties use a refresh cycle of a similar or shorter duration. [...] >> >>> >>> B) The old key remains active for *this* child CA, until it requests on >>> its own initiative. When it does the new key becomes active for this >>> child as well. And the system keeps track of this internally.. >> >> One issue here is that in such a case the old key is kept active for an >> indeterminate period. If this old key has been compromised, then is it >> really appropriate to keep this key in an active state? If the CA wants to >> retire the old key, why should it be held up awaiting an action by the child >> that may not occur for weeks, months,...? > > True. I guess there is no real reason, unless we would need the > 'prepare' state somehow because of Roque's concerns. > I was trying to point out that not only is there no compelling reason to do so, but this procedure (Option B) introduces a vulnerability vector if a party cannot retire a potentially compromised key. I believe that it is strongly preferable that a key owner can retire a key from use without awaiting on external dependencies, which is one of the attributes of the key rollover procedure described in the res-cert draft. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
