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

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jun 2010 12:11:21 -0400

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 25 Jun 2010 07:23:30 +1000

Hi Steve,

I'll interleave my comments against each section in your note - I think it probably makes my queries a little clearer in terms of the additional context.

On 24/06/2010, at 2:11 AM, 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.
> 
> -	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.)

I assume that you are defining the distinction between a "non-leaf" CA and a "leaf" CA as being one where a "leaf" CA only has EE subordinates. It this a correct assumption. Your final comment about this date applying to IANA and the RIRs does not quite capture for me the same goal as the body of this paragraph. 

I also gather the impression that you see Proof of Possession validation requiring the CA to have the ability to process the algorithm used by the subordinate when the subordinate entity generated the key pair. The RPKI provisioning protocol does not specify any such direct test using the subordinate's public key value. I am wondering if there is a missing element in the provisioning protocol, namely the inclusion  of such a direct test of PoP, and what they would imply in any case. Is the nature of the PoP test one of the issuer assurring itself that the requestor really is the party they are purporting to be, or whether the PoP test is one of the issuer assuring itself that the requestor really has possession of the associated private key?

If the former is the case, then the issuer does not necessarily need to have the ability to process the algorithm identified in the certificate request. If the latter than the rescert provisioning protocol may well be missing a needed step in verification of the request.

Am I missing something here?

> 
> -	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.
> 

How does a requestor specify the algorithm to be used by the issuer? Again my concerns here is that there is something missing in section 6 of the res-cert draft if it is indeed necessary that the requestor specify the algorithm that the issuer must use in generating the certificate the describes the subject.

> 
> -	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.)
> 

Now here I'm somewhat confused. Are you talking about a parallel, but entirely distinct certificate hierarchy? i.e. are you in effect saying that the condition here is that all certificates issued for a subject using subject key algorithm X are issued by the issuer with a certificate signature algorithm also of algorithm X? 

> -	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.)

I want to conform something here - are the CAs for the new and old suite distinct? Whats the scope of the CRLs? I assume that it would be an undesireable situation if a  CRL from the "new" suite attempts to revoke a certificate from the "old" suite, and I'm unsure what mechanism would be used to prevent such a scenario from occurring.

> 
> 
> -	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.)

What you are in effect saying, as far as I can tell, is that the RP is to switch over to believe the new "suite" if the results of the "new" and "old" differ. I wonder how such a switch in collective RP behaviour could be coordinated so precisely across all RPs. Or are you saying that the onus is on all CAs to ensure that the two environments are absolutely and precisely synchronized such that there is no possibility for such a situation?

> 
> -	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.
> 
indeed!

> 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.

regards,

  Geoff

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 05:32:25 -0400

Geoff,

Thanks for your comments. response inline.

>...
>
>
>I assume that you are defining the distinction between a "non-leaf" 
>CA and a "leaf" CA as being one where a "leaf" CA only has EE 
>subordinates. It this a correct assumption. Your final comment about 
>this date applying to IANA and the RIRs does not quite capture for 
>me the same goal as the body of this paragraph.

Yes, leaf CAs are ones that issue only EE certs.

My parenthetical comment was meant to note that this first date might 
apply only to top tier CAs, IF we choose to adopt a top-down 
deployment approach. The rest of the text does not make such an 
assumption, so maybe it was a mistake to make this comment here, sine 
I failed to carry it through i the rest of the discussion. Let's 
table the top-down discussion for now.

>I also gather the impression that you see Proof of Possession 
>validation requiring the CA to have the ability to process the 
>algorithm used by the subordinate when the subordinate entity 
>generated the key pair. The RPKI provisioning protocol does not 
>specify any such direct test using the subordinate's public key 
>value. I am wondering if there is a missing element in the 
>provisioning protocol, namely the inclusion  of such a direct test 
>of PoP, and what they would imply in any case. Is the nature of the 
>PoP test one of the issuer assurring itself that the requestor 
>really is the party they are purporting to be, or whether the PoP 
>test is one of the issuer assuring itself that the requestor really 
>has possession of the associated private key?

The CP mandates that every CA engage in PoP as part of cert issuance. 
if the provisioning protocol does not make use of PoP, there is a 
mismatch.  I have not looked at the protocol, so I can't say any more 
on that topic.

>If the former is the case, then the issuer does not necessarily need 
>to have the ability to process the algorithm identified in the 
>certificate request. If the latter than the rescert provisioning 
>protocol may well be missing a needed step in verification of the 
>request.

Agreed.

>How does a requestor specify the algorithm to be used by the issuer? 
>Again my concerns here is that there is something missing in section 
>6 of the res-cert draft if it is indeed necessary that the requestor 
>specify the algorithm that the issuer must use in generating the 
>certificate the describes the subject.

Good question. The parent CA might establish a separate "portal" via 
which requests are made to the new vs. current alg suite. I have not 
looked at the cert request formats to see if there is a provision to 
indicate the alg suite to be used, but your comment suggests that 
there is not. So, I think it might be easier to say that each CA must 
advertise (via its CPS) how subjects can indicate the alg suite under 
which a request is to be fulfilled.

>...
>
>Now here I'm somewhat confused. Are you talking about a parallel, 
>but entirely distinct certificate hierarchy? i.e. are you in effect 
>saying that the condition here is that all certificates issued for a 
>subject using subject key algorithm X are issued by the issuer with 
>a certificate signature algorithm also of algorithm X?

essentially, yes. Parallel CA certs, CRLs, manifests, and ROAs. As 
noted, if we adopt the suggestion you made about revising the 
manifest and ROA formats to accommodate dual sigs, we could have just 
one set of these objects, but the CAs certs and CRLs are distinct.

>...
>
>I want to conform something here - are the CAs for the new and old 
>suite distinct? Whats the scope of the CRLs? I assume that it would 
>be an undesireable situation if a  CRL from the "new" suite attempts 
>to revoke a certificate from the "old" suite, and I'm unsure what 
>mechanism would be used to prevent such a scenario from occurring.

The CAs represent the same administrative entity, which may or may 
not have the same name, depending on the outcome of another 
discussion.  The CA instances use different keys to sign certs and 
CRLs, so there is no ambiguity re CRL scope. Each CRL lists serial 
number of certs issued under the corresponding CA key.

>...
>
>What you are in effect saying, as far as I can tell, is that the RP 
>is to switch over to believe the new "suite" if the results of the 
>"new" and "old" differ. I wonder how such a switch in collective RP 
>behaviour could be coordinated so precisely across all RPs. Or are 
>you saying that the onus is on all CAs to ensure that the two 
>environments are absolutely and precisely synchronized such that 
>there is no possibility for such a situation?
>

This is the date after which CAs are relieved of the burden of 
issuing signed objects under the old suite. It is not a statement 
about RP behavior, but we are past the RP Ready date, so RPs MUST be 
able to process new alg suite signed objects, and not rely on any old 
alg suite objects.

>>  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 

I have a minor in understatement :-).

Steve

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 30 Jun 2010 15:49:13 +0200

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:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Thu, 1 Jul 2010 04:52:04 +1000

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

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 30 Jun 2010 16:14:49 -0400 (Eastern Daylight Time)

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