Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-01.txt

From: [email-masked]
Date: Fri, 08 Jul 2011 09:12:52 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : Algorithm Agility Procedure for RPKI.
	Author(s)       : Roque Gagliano
                          Stephen Kent
                          Sean Turner
	Filename        : draft-ietf-sidr-algorithm-agility-01.txt
	Pages           : 25
	Date            : 2011-07-08

   This document specifies the process that Certification Authorities
   (CAs) and Relying Parties (RP) participating in the Resource Public
   Key Infrastructure (RPKI) will need to follow to transition to a new
   (and probably cryptographically stronger) algorithm set.  The process
   is expected to be completed in a time scale of months or years.
   Consequently, no emergency transition is specified.  The transition
   procedure defined in this document supports only a top-down migration
   (parent migrates before children).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-01.txt

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 8 Jul 2011 18:14:47 +0200

In this new version we included the changes from the review by Arturo and several editorial nits.

Please take a look at the document and send your comments.

Roque.

On Jul 8, 2011, at 6:12 PM, [email-masked] wrote:

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 8 Jul 2011 12:08:48 -0700

Hi Roque,

This draft seems very complete. I have just a few questions and comments:

1. Section 2. "A failure to comply with this process during an algorithm transition MUST be considered as non-compliance with ...
I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply with this process would be result in non-compliance. It would be hopeful to more specific here.

2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues certificates to entities not under its administrative control." I believe this effectively  means "CAs that have children", and if that's the intended meaning perhaps that's a better statement. The present definition could apply to a CA cross-certifying another CA and other non-child certificate signing. Even if those situations don't expect to be possible within the RPKI, it would be helpful to clarify the definition. Also, it's not clear to me that a child CA is "under its administrative control" in the sense that the child CA (e.g., ISP) might not be administered by the parent (e.g., RIR).

3. Section 4.2. "The only milestone that affects both CAs and RPs, at the same moment is the EOL date.". But the "Process for RPKI CAs" figure shows that two milestones are aligned: (5) and (6). How do these reconcile?

4. Section 4.3. The alignment errors that Arturo mentioned don't seem to be fixed in -01. Did you mean to adjust them? Also, it might be worth stating explicitly in the Note following this first example that the indentation mean "signed by".

5. Section 4.5. "During this phase all signed product sets MUST be available using both Algorithm Suite A and Algorithm Suite B." It isn't clear to me what "During this phase" means in Phase 2. Does it mean "By the end of this phase"? Or does it mean "Before the start of Phase 3", which is not the same moment in time according to the figures in Section 4.2. I'm inclined to think it means "Before the start of Phase 3", because by Phase 3 "all product sets are available". Although again, Section 4.6 uses the phrase "During this phrase" so that also isn't clear and I would recommend being more precise here too.

6. Section 4.5. "An RP that validates all signed product sets using both Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results." The text added to this paragraph in -01 clarifies how to resolve certificate validation results that differ, but I think it would be helpful to include references to both Sections 6 and 7 here which cover issues when on there are differences in validation more thoroughly.

7. (nit) The references for I-D.ietf-sidr-cp didn't get updated to -17. I didn't check other references.

Thanks,
Brian

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 11 Jul 2011 11:29:02 +0200

Hi Brian,

Thank you very much for your review.

Please see my comments inline.

Roque

> I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply with this process would be result in non-compliance. It would be hopeful to more specific here.

(Roque) This is good feedback but I think we cannot delay the publication of the CP document. The idea is that the Algorithm Suites definition are part of the CP, consequently, the process to modify these suites should also be consider as a global RPKI requirement and thus tied to the CP.

> 2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues certificates to entities not under its administrative control." I believe this effectively  means "CAs that have children", and…

(Roque) These are the "CA that have children and with whom the signaling is carried out through the provisioning protocol". 

What about changing the definition to"

Non-Leaf CA: A CA that issues certificates to external entities by using the provisioning protocol described in [PROV.].

> 3. Section 4.2. "The only milestone that affects both CAs and RPs, at the same moment is the EOL date.". But the "Process for RPKI CAs" figure shows that two milestones are aligned: (5) and (6). Ho…

(Roque) 
I will change that, however, the milestone 5 (Twilight Date) is the date where the NEW becomes CURRENT and the CURRENT becomes OLD. If the RP and the CA did their part of the work, they should both be ready at that time to issue/revoke and validate certificates with both algorithms, so there is no "action" that should be taken at 

> 4. Section 4.3. The alignment errors that Arturo mentioned don't seem to be fixed in -01. Did you mean to adjust them? Also, it might be worth stating explicitly in the Note following this first ex…

(Roque)
Thanks. I will correct and do better "quality control".

> 5. Section 4.5. "During this phase all signed product sets MUST be available using both Algorithm Suite A and Algorithm Suite B." It isn't clear to me what "During this phase" means in Phase 2. Doe…

(Roque) "During this phase" means since start to end of these phase (i.e. after "CA Go Algorithm B date"). In Phase 2 all products are available using both algorithms but not all RP MUST validate them both, that only happens in Phase 3 (after "RP Ready Algorithm B Date")

> 6. Section 4.5. "An RP that validates all signed product sets using both Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results." The text added to this paragraph in -01 clarifies h…

(Roque) ok. will add.

> 7. (nit) The references for I-D.ietf-sidr-cp didn't get updated to -17. I didn't check other references.

(Roque) ok.

Thanks again,

Roque

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 11 Jul 2011 11:22:06 -0400 (Eastern Daylight Time)

> (Roque) This is good feedback but I think we cannot delay the publication of the CP document. The idea is that the Algorithm Suites definition are part of the CP, consequently, the process to modif…

You seem to be saying that the alg transition mechanism is an addition to
the global cert policy - an addendum/update of the CP (RSN an) RFC.

True?

If so, that should be noted.

--Sandy, speaking as wg chair, ceremonial vestments and badges donned

---

From: Brian Weis <[email-masked]>
Date: Mon, 11 Jul 2011 09:43:13 -0700

Hi Roque,

> (Roque) This is good feedback but I think we cannot delay the publication of the CP document. The idea is that the Algorithm Suites definition are part of the CP, consequently, the process to modif…

I didn't intend to affect the CP document. But since this statement implies that this document "updates" the CP, then I think the this document should say so at the top. I believe that was Sandy's point.

> Non-Leaf CA: A CA that issues certificates to external entities by using the provisioning protocol described in [PROV.].

That's a good precise definition.

> I will change that, however, the milestone 5 (Twilight Date) is the date where the NEW becomes CURRENT and the CURRENT becomes OLD. If the RP and the CA did their part of the work, they should both…

I understand now, but that's a subtle interpretation of "affects". It might be clearer to say something like "The only milestone at which both CAs and RPs take action at the same moment is the EOL date". (And that's a powerful statement, in my opinion.)

> (Roque) "During this phase" means since start to end of these phase (i.e. after "CA Go Algorithm B date"). In Phase 2 all products are available using both algorithms but not all RP MUST validate t…

According to a dictionary I consulted, I note that "during" does mean "throughout" so the use of that word is accurate with your clarification. But I do think it would be clearer if "During the phase" was replaced with "Throughout this phase",  "From the start of this phase", or something that is less semantic.

Thanks,
Brian

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 11 Jul 2011 19:04:21 +0200

Hi Sandra,

> the global cert policy - an addendum/update of the CP (RSN an) RFC.

We could ask the CP or the Alg. document authors to add a reference during the  AUTH48 process. That would be an easy fix.

Roque.

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 11 Jul 2011 19:11:32 +0200

Hi Brian,

See inline.

> I didn't intend to affect the CP document. But since this statement implies that this document "updates" the CP, then I think the this document should say so at the top. I believe that was Sandy's…

(Roque) I am fine with either solutions. I guess Steve may want to give his opinion on this point.

> That's a good precise definition.

(Roque) Ok.

> I understand now, but that's a subtle interpretation of "affects". It might be clearer to say something like "The only milestone at which both CAs and RPs take action at the same moment is the EOL…

(Roque) Ok.

> According to a dictionary I consulted, I note that "during" does mean "throughout" so the use of that word is accurate with your clarification. But I do think it would be clearer if "During the pha…

(Roque) Ok, I will replace for "throughout".

Roque.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jul 2011 13:17:22 -0400

At 12:08 PM -0700 7/8/11, Brian Weis wrote:
>1. Section 2. "A failure to comply with this process during an 
>algorithm transition MUST be considered as non-compliance with ...
>I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply 
>with this process would be result in non-compliance. It would be 
>hopeful to more specific here.

Agreed. The CP cites the alg spec (draft-ietf-sidr-rpki-algs). 
However, this doc say that the alg specs doc will be updated to 
reflect the new alg suite, and to include the timeline for the alg 
transition. Once that happens, a failure to comply with the alg 
transition procedure described here will imply noncompliance with the 
CP.

>2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues 
>certificates to entities not under its administrative control." I 
>believe this effectively  means "CAs that have children", and if 
>that's the intended meaning perhaps that's a better statement. The 
>present definition could apply to a CA cross-certifying another CA 
>and other non-child certificate signing. Even if those situations 
>don't expect to be possible within the RPKI, it would be helpful to 
>clarify the definition. Also, it's not clear to me that a child CA 
>is "under its administrative control" in the sense that the child CA 
>(e.g., ISP) might not be administered by the parent (e.g., RIR).

There is no cross-certification (in the common, but incorrect, use of 
the term) in the RPKI, because of the constraints imposed by the 3779 
extensions. Still, I agree that the definition could be improved. How 
about:

Non-leaf CA: A CA that issues certs to other CAs in a non-leaf CA. In 
contrast, a leaf CA is a CA that issues only EE certs.

>...
>
>
>5. Section 4.5. "During this phase all signed product sets MUST be 
>available using both Algorithm Suite A and Algorithm Suite B." It 
>isn't clear to me what "During this phase" means in Phase 2. Does it 
>mean "By the end of this phase"? Or does it mean "Before the start 
>of Phase 3", which is not the same moment in time according to the 
>figures in Section 4.2. I'm inclined to think it means "Before the 
>start of Phase 3", because by Phase 3 "all product sets are 
>available". Although again, Section 4.6 uses the phrase "During this 
>phrase" so that also isn't clear and I would recommend being more 
>precise here too.

Yes, it would be more accurate to say "at the start of Phase 2, all 
signed products ..."

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 11 Jul 2011 13:44:01 -0400 (Eastern Daylight Time)

On Mon, 11 Jul 2011, Stephen Kent wrote:

>> 1. Section 2. "A failure to comply with this process during an algorithm 
>> transition MUST be considered as non-compliance with ...
>> I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply with 
>> this process would be result in non-compliance. It would be hopeful to more 
>> specific here.
>
> Agreed. The CP cites the alg spec (draft-ietf-sidr-rpki-algs). However, this 
> doc say that the alg specs doc will be updated to reflect the new alg suite, 
> and to include the timeline for the alg transition. Once that happens, a 
> failure to comply with the alg transition procedure described here will imply 
> noncompliance with the CP.

S---T---R---E---T---C---H???

If the non-compliance with this draft was to fail to update the algs 
document, then the failure to comply with the procedure would not imply 
non-compliance with the CP.

--Sandy, speaking as wg chair

>> certificates to entities not under its administrative control." I believe 
>> this effectively  means "CAs that have children", and if that's the 
>> intended meaning perhaps that's a better statement. The present definition 
>> could apply to a CA cross-certifying another CA and other non-child 
>> certificate signing. Even if those situations don't expect to be possible 
>> within the RPKI, it would be helpful to clarify the definition. Also, it's 
>> not clear to me that a child CA is "under its administrative control" in 
>> the sense that the child CA (e.g., ISP) might not be administered by the 
>> parent (e.g., RIR).
>
> There is no cross-certification (in the common, but incorrect, use of the 
> term) in the RPKI, because of the constraints imposed by the 3779 extensions. 
> Still, I agree that the definition could be improved. How about:
>
>> available using both Algorithm Suite A and Algorithm Suite B." It isn't 
>> clear to me what "During this phase" means in Phase 2. Does it mean "By the 
>> end of this phase"? Or does it mean "Before the start of Phase 3", which is 
>> not the same moment in time according to the figures in Section 4.2. I'm 
>> inclined to think it means "Before the start of Phase 3", because by Phase 
>> 3 "all product sets are available". Although again, Section 4.6 uses the 
>> phrase "During this phrase" so that also isn't clear and I would recommend 
>> being more precise here too.
>
> Yes, it would be more accurate to say "at the start of Phase 2, all signed 
> products ..."

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jul 2011 14:05:51 -0400

At 11:29 AM +0200 7/11/11, Roque Gagliano wrote:
>...
>(Roque) These are the "CA that have children and with whom the 
>signaling is carried out through the provisioning protocol".
>
>Non-Leaf CA: A CA that issues certificates to external entities by 
>using the provisioning protocol described in [PROV.].

I disagree with Brian here.  the prov protocol is one way to have certs issued,
but it is not the only way, e.g., see the managed CA services offered by most
of the RIRs.  I'd prefer the definition I suggested in my (belated) 
reply to Brian's message.

Steve

---

From: Brian Weis <[email-masked]>
Date: Mon, 11 Jul 2011 12:14:19 -0700

On Jul 11, 2011, at 11:05 AM, Stephen Kent wrote:

> of the RIRs.  I'd prefer the definition I suggested in my (belated) reply to Brian's message.

I agree that Steve's definition is clearer.

Thanks,
Brian

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jul 2011 14:46:53 -0400

At 1:44 PM -0400 7/11/11, Sandra Murphy wrote:
>>transition procedure described here will imply noncompliance with 
>>the CP.
>
>document, then the failure to comply with the procedure would not 
>imply non-compliance with the CP.
>

Sandy,

But stretching is the usual pre-exercise warm up, and the transition to a
new alg suite will be an exercise, so ... :-).

Stated less circuitously, the CP currently mandates support for the algs
in the Alg Spec. These algs used to be in the CP, but it was decided to
move them into a separate doc, to avoid the need ti change the CP when the
algs change. An early version of the alg transition doc called for updating
the CP to reflect alg transition. But, we moved the algs spec to a separate
doc, so the alg transition now cals for the alg spec to be replaced with
a new doc that calls out the new algs and provides the transition timeline.

We have gone down the path of document modularization and 
indirection, this is where we wound up!

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 11 Jul 2011 17:29:49 -0400 (Eastern Daylight Time)

On Mon, 11 Jul 2011, Stephen Kent wrote:

>>> Agreed. The CP cites the alg spec (draft-ietf-sidr-rpki-algs). However, 
>>> this doc say that the alg specs doc will be updated to reflect the new alg 
>>> suite, and to include the timeline for the alg transition. Once that 
>>> happens, a failure to comply with the alg transition procedure described 
>>> here will imply noncompliance with the CP.
>> 

Yes, especially when the exercise involves significant muscle movement, 
and alg transition involves significant movement of the brain muscle, 
so...  :-)

> We have gone down the path of document modularization and indirection, this 
> is where we wound up!

I understand the reasoning (I can stretch that far).

But the desired outcome is for any violation of the transition procedure 
to violate the CP.  Right?

As you said, this follows from the first step of the procedure, which is 
to update the alg document with the transition timeline, thereby 
indirectly updating the CP with the transition.  Subsequent violation of 
the transition procedure would therefore violate the CP.

But if the violation of the transition procedure is to fall at the first 
hurdle - to fail to update the alg document with the transition timeline, 
then any subsequent violation of the procedure would no longer violate the 
CP, even indirectly.

Right?

--Sandy, speaking as wg chair.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jul 2011 18:03:49 -0400

>But the desired outcome is for any violation of the transition 
>procedure to violate the CP.  Right?

agreed.

>As you said, this follows from the first step of the procedure, 
>which is to update the alg document with the transition timeline, 
>thereby indirectly updating the CP with the transition.  Subsequent 
>violation of the transition procedure would therefore violate the CP.

right.

>But if the violation of the transition procedure is to fall at the 
>first hurdle - to fail to update the alg document with the 
>transition timeline, then any subsequent violation of the procedure 
>would no longer violate the CP, even indirectly.
>
>Right?

yes, but that is a procedural hurdle that, presumably, is within the 
purview of the WG and the IESG. So I didn't think it belonged in the 
doc. But, we both agree that a more explicit statement of how this 
doc relates to the CP is needed.

Steve