Subject: [sidr] alg migration (long)

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jun 2010 15:43:22 -0400

>  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