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 consequence, 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.
I think that is a fair characterization.
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".
If we have an ability to lock a directory, and if we put the current and next algorithm signed products in the same directory, then I believe that the problem of consistency is manageable, on a local, per-CA basis. It certainly is manageable for RPs, under the locked directoty assumption.
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 maintained 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,
If we have dual signature ROAs and manifests, that does seem to make life easier for repository maintainers, i.e., they need not generate two versions of the same data structures and sign them separately. They do, however, have to generate two sets of keys and certs, one for each alg suite, and populate the ROAs and manifests with pairs of these EE certs. RP's incur some added complexity dealing with dual signatures and dual EE certs (single use), but I find it hard to quantify that.
Also, we still need to have one CRL per alg suite, because a CRL cannot have more than one signature. So, we would have two CRLs in the same directory, both covered by the same manifest.
It's not clear to me when (and for how long) a subordinate CA cert would have a doppleganger, i.e., a second cert issued under the new alg suite, but containing a key form the old alg suite. Then, when the subordinate CA is capable of issuing signed products under the new suite, would we not have old and new alg suite versions for it's CA cert, as well? I recall that you voiced concern that we might have an exponential growth in the repository tree, depending on how alg suite migration worked. I don't think it is that bad, but I can imagine a doubling or quadrupling of signed products under some scenarios.
(I wonder if these scenarios provide examples where the AIA extension should point to the directory, vs. the cert file?)
Amnyway, the savings in the number of directory signed products is mostly in terms of the number of ROAs, which are reduced by 1/2 if we use dual signature CMS objects. But, each of these objects is bigger that an single sig object, as it holds two EE certs and two sigs. I have not asked anyone to generate single vs. dual sig instances of a ROA, but I bet the size of one dual sig ROA is not much smaller than two, single-sig ROAs. (The cert and sig elements of the CMS blob are the biggest pieces, I believe.) So in terms of directory space and transmission volume, dual sigs may not be much of a win. Still, we may still want to consider this approach, to simplify repository maintenance.
Steve _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
