Subject: Re: [sidr] algorithm suite migration (top level scenario)

From: Roque Gagliano <[email-masked]>
Date: Thu, 1 Jul 2010 09:38:53 +0200

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-masked]
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> _______________________________________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 2010 16:34:09 -0400

At 10:46 AM +1000 6/26/10, Robert Loomans wrote:
>...
>
>The provisioning protocol uses PKCS #10 certificate requests, and 
>doesn't currently have any provision for PoP.

PKCS #10 includes provision for POP for keys/algs that support 
signatures, e.g., RSA.  RFC 5272 section 6.3 says:

Proof-of-possession information for key pairs, however, is carried 
separately for each PKCS #10 or CRMF certification request.  (For 
keys capable of generating a digital signature, the POP is provided 
by the signature on the PKCS #10 or CRMF request. ...)

Section 3.4.1 of the provisioning protocol says:

[Certificate request]
       value is the certificate request.  This is a Base-64 encoded 
DER version of a request formatted using PKCS#10.

If one follows the usual PKCS #10 convention of signing the request 
with the private key corresponding to the public key in the request, 
we have PoP. I had assumed (perhaps erroneously) that the CMS 
envelope would be signed using a BPKI key, for authorization purposes.

But, the nesting of all of this, including the XML, is complex, so ...

A diagram might help :-).

>...
>
>The key and algorithm info are in the certificate request. Is that enough?

In PKCS #10 these would refer to the key being certified by the 
Issuer.  What we need here is the ability to specify which of two 
algs are to be used by the issuer. Again, I have never looked closely 
at this document and thus I'm not sure to which specific fields you 
are referring.

Steve