Hello everyone, I have reviewed this draft and I have several questions and comments. As a relative newcomer to this list, I have not at all ruled out the possibility that some comments and questions below are the result of my own naivety. However, I have done the obvious background reading to try and minimize the incidence of this. :-P
As a reader, Section 2 para 4 kind of confuses me. There is a vague discussion of "a period of time" and "'staging period,'" but neither is explained until much later in the draft. My suggestion is to be more explicit about _why_ the draft has the need for this waiting period. From reading the entire draft, it later seems that this is to ensure that the new CA is propagated widely enough before going live? Could the draft just say something along those lines? Later in the Section there is a 6-step rollover process: - In step 2 I am a little worried about the notion that no rollover is possible until the issuer has issued a request and received a responded with new certificate. I can clearly see how clean this model is, but practically speaking, doesn't that mean that an authority cannot take action in response to an event (such as a key compromise) until someone else's operational cycles are met? - Related to this, I am also a little confused about the "CPS." I'm wondering how realistic it is for someone to predict their turnaround time on something like this. What if the prediction is very off (sometimes, occasionally, etc)? To be clear, my trepidation on this doesn't come from ambiguity of the concept (it does seem quite clean), but from some observations of complications in the DNSSEC rollout. When implementing some simple ideas, things have sometimes become very complicated. :) - Also in step 2 I don't understand why the issues must select a distinct subject name? Also, is there an expectation that this is globally distinct? - In step 3, the second bullet includes the statement "As quickly as possible..." I think it might be more instructive to explain some tradeoffs of various timing decisions? As a reader, I don't clearly understand why this should be done quickly, or what the draft considers "quickly." Would it be possible to explain why delaying causes trouble, and at what point delaying causes that trouble, etc? - Also in step 3, I believe the third bullet explains that the new CA needs to create a temporary EE cert solely to seed the new CA's manifest, and then below the private portion of that EE's key [must|should|may] be destroyed. I don't think I understand why so many moving parts exist here. Is this because the manifest cannot begin by being empty? If so, why not, and why not define something that can securely illustrate an empty manifest? I can clearly see how this is intended to work, but not why it needs so many moving parts. In its current form, it seems like there is a fair amount of room for operational mistakes to wreak some havoc? For example, what if the private portion of the EE key is compromised? Is this a problem? - In step 4, the text says "all RPs." Does this mean all RPs in the Internet, or some other subset, and if the former what order of magnitude are people envisioning for the number of global RPs? - Also in step 4, I was wondering what happens if the load of keeping the current CA and the new CA up to date causes them to fall behind? I think that (assuming the current and new CAs are on the same directory repo) the text essentially requires the directory repo to do double duty (i.e. double its load) during a rollover. What if it cannot keep up, it will be in a rollover state forever, right? - A somewhat related concern in step 4, I think revocation gets kind of hairy too: if a cert is issued during a rollover, and then revoked before the rollover finishes, I don't think the text explains how this should be represented in the new CA. The text says new certs should go in the new CA, but it also says no revocations should go in the new CA's CRL. The staging period exists so that RPs can be learning of the new CA, right? So they would see the new cert, but no revocation? Finally, the end of Section 5 really got my attention with the text, " When a CA rekeys, it changes many signed objects, thus impacting all RPs." This statement makes me wonder how large an effect any given CA can have on global stability. Could this be a [D]DoS vector? I think some clarification on how to determine the impact a single party can have on the rest of the RPs would be very useful here? I hope some of this made sense, :) Eric On 11/17/10 8:56 PM, "Sandra Murphy" <[email protected]> wrote: > > > Geoff Huston has requested a WG LC for draft "CA Key Rollover in the > RPKI". > > The document and the draft version history are available at > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-keyroll. > > The Last Call will end Wed, 1 Dec 2010 (AOE). > > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. > > --Sandy, speaking with wg chair derby on > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
