Hi Steve, Just one comment of procedure. We have now the document draft-ietf-sidr-rpki-algs, so I guess your procedure should be in a document that obsoletes that document in the future. There is no real reference to algorithms in the CP now.
Roque. On Jun 23, 2010, at 6:11 PM, Stephen Kent wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
