My second response to Steve Kent, also sent to the sidr WG 24 hours ago, does not appear to be in the WG mailing list archive either.
Let met try once more to send this to the sidr wg. Geoff -------------------------- On 14/06/2010, at 12:15 AM, Stephen Kent wrote: > At 9:20 AM +1000 6/12/10, Geoff Huston wrote: >> On 12/06/2010, at 8:08 AM, Stephen Kent wrote: >> >>> >>> Given these assumptions, we have adopted an initial design in which both >>> key rollover and algorithm suite migration entail an interval during which >>> old and new CA certificates, CRLs, and signed objects are maintained in >>> parallel in the repository system. For key rollover, we anticipate that >>> this interval will be relatively brief, say 3-7 days. For algorithm suite >>> migration we anticipate that it will be much longer, as noted above in >>> assumption #3. >>> >> >> For algorithm suite migration this extended period of parallel operation >> with an imposition of top down migration is certainly an interesting >> approach. The comments in section 3 of draft-ietf-sidr-rpki-algs-01.txt >> address this form of algorithm migration and cast some doubt as to the >> feasibility of such an approach within the scope of conventional operational >> practices when looking at the behaviour of widely distributed data >> structures. > > Can you elaborate on this concern? > >> If the operational impost of maintenance of parallel structures over an >> extended period was considered to be too risky in terms of ensuring a >> requirement for precise coherence between the multiple structures and >> ensuring identical outcomes for every relying party , are there alternative >> approaches that mitigate some of these risks? > > I initially investigated an approach that allows a CA at any point in the > hierarchy to begin using the next alg suite, subject only to the constraint > that the CA's parent is prepared to effect PoP with the new alg suite when > issuing a cert to that CA. However, this approach seems to result in much > greater complexity than a top-down approach. As a general comment, I have doubts about any high degree of isomorphism between key rollover and algorithm migration, and consequently I wonder if the proposed approach of attempting to use a single document is creating a artificial incentive to define a single approach when in fact they are operationally quite distinct functions and may justifiably be efficiently addressed by distinct algorithms. If that is indeed the case that the most operationally effective and efficient procedures are quite distinct then the rationale to describe these procedures in a single document would appear to me to pretty much entirely unconvincing. With respect to a CA performing a key rollover, as I understand it, a key rollover is intended to be a local operation performed by a CA. While there is a forced impact on the CA's immediate parent in terms of issuing a new certificate, the intent of the key rollover procedure was, I thought, to limit the impact on the CA's subordinates. An algorithm migration is a collective procedure where, as I understand it, there is the desire to head to an end state where all parties, CAs, EEs, and Relying Parties have migrated to exclusive use of the "new" algorithm, and the issue here is to define a procedure for collective action across the entire RPKI that does not necessarily involve critical or forced dependencies. At present the key rollover procedure is documented as part of the "design notes" of the res-cert draft. The choice of a design note was to delineate the standard specification component of the draft, namely that of a standard profile of fields for certificates, CRLs an d certificate requests, from the descriptions of procedures and constraints that were not necessarily an integral part of the standard specification. With respect to algorithm migration migration, there is an imposed requirement for some level of coordination of actions over an extended period, and also a need for duplication of actions, which is not necessarily the case in key rollover. In one form of the key rollover algorithm (the one documented in draft-ietf-sidr-res-certs) the entity performing the key rollover firstly requests a certificate for the new key, while leaving the old certificate in place. The entity can then wait for replying parties to "catch up", by giving relying parties some time to retrieve the new certificate. After this time it is an option for the entity to reissue the subordinate products using the new key, and it is possible to have the old set of subordinate products be overwritten (or replaced) with the new set. The algorithm migration procedure cannot assume that there is some small "catch up" time after which all relying parties can be assumed to be able to use the new algorithm. The consequ ence, as I understand it, is that the entity has to in effect operate in a mode where all actions are duplicated, once for each algorithm. This is, in effect, specifying the construction and operation of a parallel RPKI structure that is entirely distinct from the "current" RPKI structure by virtue of its exclusive use of a "new" algorithm for signature generation. The latter option, that of the concurrent operation of parallel RPKI structures, poses some complex issues in terms of synchronisation of actions across the set of RPKI CAs, as well as issues of consistency and coherency in the operation of multiple parallel RPKI frameworks, as well as the uncertainties associated with a global determination of when any such transition can be considered "complete". This poses some issues which to my mind are not dissimilar to the difficulties that are being presented with the current IPv6 transition. The notes in the draft-sidr-algs draft pointed to the possible direction of main tained a single collection of signed objects, and use a CMS structure of multiple signatures. while this does not mitigate the need for multiple certificate hierarchies (one per algorithm) it does at least address the issue of multiple distinct sets of signed objects by collapsing these back to a single (distributed) set of signed objects, regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
