Geoff, > > An update to the alg document would presumably say something along the lines > of "The standard algorithm used in the RPKI is <X>, and use of > RSASSA-PKCS1-v1_5 is deprecated. The process of migration to use of algorithm > <X> is described in RFC Z." This algorithm document could be further updated > to refer to other algorithms and still reference the same migration process > description. >
Correct, that was what I tried to (badly as I can see) communicate. Roque. > Geoff > > > > > On 30/06/2010, at 11:49 PM, Roque Gagliano wrote: > >> 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 >> >> _______________________________________________ >> 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
