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? 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. > 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. 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
