I think it might be helpful to explore some aspects of how we
envision migrating to a new algorithm suite, without debating all of
the details of migration. This way we can determine if there is
agreement on general principles re migration before we try to resolve
details.
My notion is that the process of migration begins with the
publication of a new CP version by the IETF. That process will be
very visible and take several months to complete, at a minimum. The
new CP would specify the next algorithm suite by reference to an
existing RFC that defines the signature algorithm and hash algorithm
that comprise the suite. That RFC will have been around for a while,
because we would not consider migrating to anything other than a
well-established, mature algorithm suite. Thus the suite itself will
have been defined in an RFC well in advance.
I think new CP should specify the following milestones:
- CA Ready <next alg suite name>: By this date all (non-leaf)
CAs MUST be ready to process a request from a child CA to issue a
certificate containing a key for the new signature algorithm. The
certificate that is issued would be signed under the current
algorithm suite. The reason we need this date is because a
certificate request requires the issuing CA to verify proof of
possession (PoP) for the new key by the requesting party. Thus by
this date all CAs MUS be able to perform the PoP procedure, even if
they are not yet ready to issue certificates under the new algorithm
suite. (If we decide that a top-down migration approach is desirable,
this date might apply to IANA and the RIRs, rather than to all CAs.)
- CA Set <next alg suite name>: By his date all CAs MUST be
prepared to issue a certificate signed under the new algorithm suite
to a child CA that requests such. At this stage there is no
requirement that any CA issue such certificates, but rather that all
(not leaf) CAs be prepared to do so upon request.
- CA Go <next alg suite name>: By this date, all (non-leaf) CAs
MUST have re-issued all child CA certificates, under the new
algorithm suite, as well as CRLs, manifests, and ROAs. The old suite
is still in use and thus CAs are maintaining parallel, synchronized
sets of signed objects under old and new algorithm suites. (If we
adopt dual-signatures for ROAs and manifests, one set of those
objects can satisfy this requirement. However, a certificate or CRL
has only one signature, so corresponding copies of these objects are
still required.)
- RP Ready <next alg suite name>: By this date all RPs MUST be
prepared to process certificates issued under the new algorithm
suite. Since all CAs are publishing all sighed products under both
suites by now, RPs have plenty of material to process to verify that
they get the same results under old and new suites. My recommendation
would be that if the results from the new suite don't agree with the
results from the current suite, stick with the results from the
current suite while you try to figure out the problem. (This may
require contacting some of the CAs to see why there is a mismatch,
but since you can keep using the products under the current alg
suite, there should be time to resolve the problems.)
- Twilight <old alg suite name>: At this date a CA MAY cease
issuing signed products under the old algorithm suite, at its
discretion. (This affects the children of the CA, so there is a need
for coordination. But, since this date is after RP Ready, no RPs
should require signed products under the old algorithm suite at this
stage.)
- EOL <old alg suite name>: At this date NO signed objects
under the old algorithm suite are generated or consumed. More
formally, every CA and every RP MUST NOT generate certs, CRLs, or
other RPKI signed objects under the old alg suite. The transition is
now complete.
Note that during the interval when current and new algorithm suites
are in use (from CA Set <alg suite name> until Twilight <alg suite
name>) a CA MUST be prepared to process key rollover requests for
children under both current and new suites. There are a lot of
details to be worked out for this.
I have intentionally not suggested any durations for the intervals
defined by the ordered list above. Clearly that is one of the topics
we need to address, if we agree to a model that adopts a timetable
like this. But, first we need to discuss whether these are the right
milestones.
Comments and suggestions are solicited.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
