On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <[email protected]> wrote: > You suggested that we codify how the community should deal with problems > that motivate delaying a phase transition. We're not writing the timeline > document now, but the text at the beginning of this message is an effort to > make sure such considerations are addressed in that document.
When you say "timeline document", do you mean "timeline for specific implementation of the phases in this document"? I ask because the algorithm-agility sure looks like a timeline document. The main concerns rise from the content and order of the phases, and their consequences. > Phase 0 is the start of the process, when a new algorithm suite has been > selected and the timeline published. > > Phase 1 requires all CAs to be able to issue certificates under Suite B. > > Phase 2 requires that CAs MUST publish all signed products under Suite B, as > well as Suite A, and RP MAY be prepared to validate these products using > Suite B. > > Phase 3 requires that RPs MUST be able to process Suite B signed products, > and RPs are encouraged to validate signed products using Suite B. > > Phase 4 begins the phase out of Suite A. > > > First, not that a CA cannot unilaterally decide to transition to a new > algorithm. There is a requirement that the issuer of its certificate is > prepared to accept a certificate request under the new algorithm suite > (because of the PoP requirement). This statement is entirely predicated on having Phase 2, as it is currently defined, after Phase 1 (CAs ready for receiving B) and before Phase 3 (when RPs are able to validate using B). I don't see what this step in this order, buys us, or even that it is necessary at all. Let's take a look at what happens after Phase 3: - RPs speak "B". - CAs can process "B". Is this not the (only!) pre-condition required for supporting any of the four combinations? > If we allow CAs to "do their own thing," there is the potential for > four combinations: > - a Suite A certificate issued under Suite A > - a Suite A certificate issued under Suite B > - a Suite B certificate issued under Suite A > - a Suite B certificate issued under Suite B > > The exponential growth arises if we have Suite A and B product sets at each > tier. I don't see the requirement to support more than one certificate (ie of more than one of the four types.) After Phase 1 and Phase 3, but ignoring your Phase 2, we know: - RPs speak "B" - CAs can accept requests with PoP == "B". A certificate of any of the four types can be issued by any CA, and validated by any RP. Which type depends only on the CA (signature alg) and the subordinate CA (key/PoP type). There is no exponential growth _unless_ multiple cert types for each cert are maintained, which I disagree with as being a requirement _at_all_. I do not see a reason to need more than one certificate, regardless of which of the four types it is. So, the only possible danger with allowing any CA to switch to "B" whenever it wants, is that should that occur before the end of phase 3 (when all RPs speak "B"), all subordinate certificates will be at risk for not validating with those RPs who are not "B"-ready. However, experimentation during the early deployment stages, almost demands for this ability, and that there would be the expectation of such failure by those using (or more accurately, testing) code prior to widespread adoption. Earliest work would be done using leaf "B" certs, and early-deployment code. Gradually additional levels of testing (B-B and B-B-B), until enough traction in deployment in CA code and RP code has occurred. This eventually culminate with "B" root transition. Deploying code without this incremental testing, and then expecting it to "just work", suggests a lack of experience and familiarity with the deployment of new operational code features in a multi-vendor environment on the Internet... _Especially_ if there is no compelling reason. Can you show me what compels the maintenance of both types of certificates, and a "fall-back-to-A" logic? We have another term for "fall-back-to-foo" - it's called a "downgrade attack". I'll withdraw my objection if anyone can make a truly compelling case using only the assumptions above - Phase 1 and Phase 3, followed by widespread issuance of production "B" certs, on a timeline entirely determined by local CA decisions. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
