I concur with Geoff re the desirability of the staging period. I
disagree with Rob's suggestion that the staging period is at the
wrong place in the document, or in the phased approach to key
rollover.
From my perspective, the fundamental rationale for the staring period
is two-fold:
- we want a delimited interval after which a CA can have
reasonable confidence that all RPs will have retrieved the new CA
key, before transiting to a new CA key and subordinate, signed
products.
- we also want a delimited interval for RPs so that they can
acquire a new CA key prior to the transition to that key for
subordinate signed products.
Because of the naming conventions adopted by the repository design,
most of these new products overwrite old ones, so we want to maximize
the likelihood that an RP gets a consistent set of data.
I agree with Rob that there is no delimited period that will
guarantee that both CAs and RPs are in sync re a CA key transition.
But, that does not mean that we ought not select and publish such a
period, consistent with the other time intervals that we have
published, e.g., the frequency at which RPs SHOULD query the
repository.
As a compromise, we could re-phrase the staging period discussion to
RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not
just you, Rob, :-)) feels strongly.
I also agree that, as Roque noted, in the case of an emergency rekey,
the 24-hour staging period may be inappropriate. But an emergency
rekey is not the same as a planned key rollover. I suggest that we
note this difference up front and say that, in case of an emergency,
the CA re-issuing the cert which is being re-keyed SHOULD consider
the impact on routing of a quicker transition to a new cert+key, and
behave as it sees fit, given the circumstances surrounding the rekey.
Geoff, would you be comfortable with this rewording for emergency
rekey, and with the MUST->RECOMMEND, if Sandy determines that there
is WG consensus for that change?
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
