Speaking as wg chair, I aggree with Geoff's understanding of the current
wg document strategy.
I can see drawbacks to the suggested process.
The sidr-rpki-algs draft was instituted so that changes in algorithm would
not require changes in the base specs, as an ease to implementers of the
base spec and an ease to process.
If we combine the discussion of the transition/migration procedure with
the discussion of required algorithms, we complicate the process both now
(we have to wait until both issues achieve consensus to progress either
work) and also when either the algorithm requirements or the transition
procedure changes.
I believe there is reason to keep the discussion of algorithms
requirements separate from discussion of transition/migration procedures.
--Sandy, speaking as wg chair
On Thu, 1 Jul 2010, Geoff Huston wrote:
I disagree Roque. My understanding was that all the references to algorithms
used in the RPKI were collected into a single document that itself could be
updated without requiring updates to all the other documents - That central
reference point is the rpki-algs document. A second document was proposed that
described how to migrate the RPKI from one algorithm suite to another. The
latter document does not obsolete the former.
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.
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
