On 13/12/2010, at 5:36 AM, Rob Austein wrote: > At Tue, 07 Dec 2010 11:19:22 +0100, Tim Bruijnzeels wrote: >> >> If I remember correctly I think Roque and Steve mentioned that CA >> certificates on any level may be used by RPs as a Trust Anchor -- even >> if you did not plan to make yourself available as a TA (i.e. publishing >> your cert info as per TA draft). The staging period was introduced to >> give RPs down the chain from you at least some opportunity to notice the >> change and start using the new cert in place of the old one.. > > I am far from certain that I buy this argument (and yes, I understand > that you're trying to recount it from memory, not necessarily > advocating it). Every RPKI operator in the world must be *required* > to publish keys using new certs for 24 hours just in case some > stranger somewhere happens to be constructing trust anchors using > their certs?
In my opinion is that the answer to your question is yes, and no. Yes, in this document every RPKI _CA_ operator in the world is *required* to publish keys using new certs for a "staging period" (>= 24 hours) before using this CA to publish this CA's subordinate products. No, this is not directly related to trust anchors. > > To be clear: I do not object to *allowing* prepublication of certs > using new keys, there are scenarios where it makes a lot of sense (eg, > having a new key out there all ready to use so one can roll quickly in > the event of a key compromise). It's putting this in as a hard > *requirement* imposed on every RPKI operator that bothers me. On the other hand, as I understand it, the staging period is intended to catch relying parties that fall out of sync with the distributed repository publication process, and manage to gather a new CA cert, but not collect the new subordinate set of products (maybe they are using some form of local repository cache synchronisation that uses some custom synchronization algorithm). This anomalous situation will of course be suboptimal for the RP given that the set of subordinate products is no longer able to the validated using the NEW CA. The staging period specified in the draft for the NEW CA is intended to minimize the deterimental impacts of this lack of synchronisation between producer and consumer. As I recall, no specific algorithm is specified as mandatory for an RP to use in terms of the manner by which the local repository cache is synchronized against the distributed repository publication system, with a logical inference that no particular RP repository synchroniza tion behaviour can be assumed to be used uniformly by all RPs. > >> But as I said, if I remember correctly.. maybe Roque or Steve can >> comment on this? > > And, even if the WG buys this argument, it would need to go in the > draft. > The draft considers keyroll for CAs. To the extent that a TA is a CA, this document covers TAs only by virtue of that level of indirection. To the extent that the TA may have some additional requirements regarding use of keys, this document does not encompass that. Maybe the TA draft is the appropriate place to consider what particular requirements one may want to place on a TA key rollover, bearing in mind that the TA's key fingerprint may have already been widely circulated using more persistent media. > As for why I think there may be a need for some kind of staging (or, > at least, a need for the absence of a hard requirement for immediate > revocation of OLD CA after reissuing all subordinates under NEW CA): > think about network partitions. In particular, think about network > partitions that leave the publication point holding the CRL covering > OLD CA itself reachable while leaving the publication point for OLD > CA's and NEW CA's subordinates unreachable. RP wants to continue > using cached copies of subordinates issued by OLD CA, since RP can't > reach the new subordinates issued by NEW CA -- but OLD CA has been > revoked. Oops. Thud. One of many oops thud opportunities in a distributed repository scheme where there is rollover and update of individual components of the distributed system. The algorithm described in this document assumes a repository overwrite procedure of NEW over OLD for the subordinate products, hence the desire to avoid a THUD opportunity by requiring that the immediate superior CA publish the NEW CA certificate well in advance of publishing the subordinate products of the CA. The old CA could be kept around, as distinct from the draft's advice to generate a revocation request "without and intervening delay" between publication of the subordinate products of the NEW CA and this revocation request, but what is the appropriate delay to make as a minimum *requirement*? What about a CA that encounters key compromise? If they have been prudent and already published a NEW CA, then rollover from OLD to NEW CA can be effectively performed immediately. But if this draft then *requires* the compromised old key to continue to exist for a period prior to revocation, then how does this continued existence of a CA with a compromised key add to the overall robustness of the system? I suspect that there are a number of trade-offs in this environment, and the algorithm described in the draft represents one such set of trade offs. There are others, as you have pointed out in your note, but I am personally not convinced at this point that the alternative approach you describe here offers a net gain to both CAs and RPs. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
