On Tue, Nov 8, 2011 at 5:40 AM, Roque Gagliano <[email protected]> wrote: > Hi Brian, > Thanks for your comments. > Please see inline. > Roque > > (snif) > > So the analogous high-level design for agility SHOULD be as follows: > - new CP documents may be published, with new OIDs > > > The CP document in section 6.1.5 refers the definition of the Algorithm > Suite to the draft-ietf-sidr-rpki-algs document. There are not OID defined > in the CP document. That is why in our document we refer to an update of > this document instead.
I was actually referring to the OID _of_ the CP document itself, draft-ietf-sidr-cp-17, in section 1.2. And in draft-ietf-sidr-res-certs-22, section 9, use of that OID is referenced, including how the change of OID gets handled. The change-of-OID process identified there would be necessary, even if the res-certs format did not change, so long as there was some other reason for the OID change. And in draft-ietf-sidr-cp-17, section 9.12.3 describes when the OID must change. Clearly, changing the algorithm RFC used by the CP, would require a new CP with a new OID, since it directly affects acceptability of RPKI certificates. > - ONLY when a CA with a given CPS decides to change CP does that CA > need to execute a locally-significant key+alg roll > - The CA would issue new certs with the new CP which itself lists > additional algorithms > - The same procedure would be executed in multiple phases - issue new > child certs published under the old main cert; move them to the new > cert, rewriting/overwriting in the same location > > > In section 4.1 we defined: > > CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST > be ready to process a request from a child CA to issue a > certificate under the Algorithm B suite What I am saying is, there is no reason to require a change to a child's CPS, and thus its CP, and thus its algorithm suite, simply because the parent CA is making this change. The whole 'all (non-leaf)' stuff is un-necessary. Each CA may operate its CPS independently. Algorithms are explicitly included via OIDs in every cert. A child CA may need to sign with algorithms accepted by the parent CA, but they can issue certs with a different CP, signed according to the algorithms _of_that_CP_ (their own CP, independent of the choice of CP used by the parent CA). The choice of algorithm acceptability for a given cert, comes from the CP. It needs internal consistency. There is no further requirement on algorithm choice. > If I summarize your comment, you are stating that the definition of "ready" > for a CA should also include an update on its CPS to refer to the new suite. > This was understood but as what each CA will need to do to be ready to > process requests from a child CA is local to that CA, we did not got into > the details. Okay, yes, that was the bit I said was technically correct... > The process that you have described is indeed the proposed algorithm in the > document for the CAs, where we adopted a "top-down" process and we maintain > the two suites independent. The document also includes the transition to the > new suite on the RPs that are distributed globally. That's the part I disagree with entirely - there is no "top-down" required at all. There is no "globally". There is only the requirement operationally that any newly published CP with new OID be supported by RPs. The publishing the new CP with new OIDs with sufficient time for RPs to implement those changes is the only timeline issue. It is a "sunrise" issue - a minimum time after publication before ANY CA begins to issue certs using the new OID. After that date, any CA may choose to use the new CP, without requiring any change to either the CA's parent, or the CA's children, except as relates to the algorithms used on new certs, which the child needs to discover. This has no bearing on the CP _used_ by the child CA in issuing certs to grand-child CAs - that is under the local policy of the child CA. Every CA is free to choose the CP it uses from among the published CPs, modulo the issue date plus delay required (6 months in the initial CP document). Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change algorithm suite. Perhaps a separate BCP can recommend, or even require, use of some subset of CP documents, or at some point an old CP could be moved to historic or depracated status. However, that should _not_ be part of the alg-agility document. Agility should limit itself to the mechanism by which a _single_ CA changes algorithm suite, including the possibility that the new suite still include all the algorithm(s) from the previous suite, the possibility that multiple algorithms are part of the new suite, as well as case of (but not a requirement that) _an_ older algorithm is dropped from the suite. > Regards, > Roque Sincerely, Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
