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

From: Arturo Servin <[email-masked]>
Date: Fri, 17 Jun 2011 13:23:00 -0300

Roque,

	Some comments about the draft.

	I think that in phase 3 it is implicit that CAs must sign using algs A and B (it's a must in phase 2). Wouldn't be a good idea to make an explicit statement in phase 3 as well?

	There are some indent issues with some of the examples, i.e:

           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
               |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

	I guess it should be something like:

CA X-Certificate-Algorithm-Suite-A (Cert-XA)
           |
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
               		   |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

	In phase 4 the table has indent issues too.

	And after the table, this text is confusing:

	""All  signed products sets issued using the Algorithm Suite A MUST be
   published at their corresponding publication point but signed
   products sets issued using the Algorithm Suite C MAY be published at
   their corresponding publication points."

	Do you mean?

"All  signed products sets issued using the Algorithm Suite A and Algorithm Suite C MUST be
   published at their corresponding publication points."

	In section 5 I have a basic question What happen if the child ask the parent to sign with Alg. B but the parent only supports A, it just fails? Is there any message defined in the up/down specification to deal with this and signal the error?

	Section 6 answered a question that I had when I was reading the first part of the draft:

"As a general rule, the validation of signed products using different algorithm suites are
   independent and the RP MUST NOT keep any relationship between the
   different hierarchies" Also it says that an object is valid if it is valid in algs. A OR B. May be it would be good to mention this somewhere in the first part of the document but without going to too much detail.

	Also in the same section 6, I think that there is important to mention that in phase 0 (coming back to) the objects signed with C are not longer valid.

	Finally, Section 9. I would prefer a MUST instead.

	I think that's all so far.

Best wishes,
-as

On 27 Feb 2011, at 19:51, Roque Gagliano wrote:

> Dear WG,
> 
> We just submitted the -00 version of this algorithm agility draft, now as a WG item. 
> 
> The document includes the different changes requested since Beijing from the individual submission, notably:
>    1.  Change form "laisez faire" to "top-down"
>    2.  Included Multi Algorithm support in the RPKI provisioning
>        protocol
> 
>    3.  Included Validation of multiple instance of signed products
> 
>    4.  Included Revocations
> 
>    5.  Included Key rollover
> 
>    6.  Included Repository structure
> 
>    7.  Included Security Considerations
> 
>    8.  Included Acknowledgements
> 
> We look forward for your comments.
> Regards,
> Roque.
> 
> 
> On Feb 26, 2011, at 9:45 PM, [email-masked] wrote:
> 
>> 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)       : R. Gagliano, et al.
>> 	Filename        : draft-ietf-sidr-algorithm-agility-00.txt
>> 	Pages           : 25
>> 	Date            : 2011-02-26
>> 
>> This document specifies the process that Certificate 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 support 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-00.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <Mail Attachment>_______________________________________________
>> 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: Mon, 20 Jun 2011 15:02:21 -0400

Arturo,

Let me reply to a couple of the questions you raised, in my role as a 
co-author.

>...

I agree that several areas of text are confusing. The problems starts 
in 4.7, which says:

    Phase 4 starts at the Algorithm B Twilight Date.  At that date, the
    Algorithm A is labeled as "old" and the Algorithm B is labeled as
    "current":

The text should probably say:

    Phase 4 starts at the Algorithm A Twilight Date.  At that date, the
    Algorithm A is labeled as "old" and the Algorithm B is labeled as
    "current"

After the diagram, the text says:

    During this phase, all signed product sets MUST be issued using the
    Algorithm Suite A and MAY be issued using the Algorithm Suite C. All
    signed products sets issued using the Algorithm Suite A MUST be
    published at their corresponding publication point but signed
    products sets issued using the Algorithm Suite C MAY be published at
    their corresponding publication points.  Also, every RP MUST validate
    signed product sets using the Algorithm Suite A but also MAY validate
    signed product sets using the Algorithm Suite C.

To avoid confusion (because we re-label the alg suites during this 
phase), we probably should say something like:

    During this phase, all signed product sets MUST be issued using
    Algorithm Suite A (formerly B) and MAY be issued using Algorithm Suite
    C (formerly A). All signed products sets issued using Suite A MUST be
    published at their corresponding publication points, but signed
    products sets issued using Suite C MAY be published at their corresponding
    publication points.  Also, every RP MUST validate  signed product sets using
    Suite A but also MAY validate signed product sets using Suite C.

>
>	In section 5 I have a basic question What happen if the child 
>ask the parent to sign with Alg. B but the parent only supports A, 
>it just fails? Is there any message defined in the up/down 
>specification to deal with this and signal the error?

The short answer is yes. Based on feedback we received after briefing this
to SIDR at an IETF meeting, we adopted a top-down algorithm transition model.
So, a child can request a cert under the new alg ONLY after its parent has
begun to offer that alg for its signed products. This is stated in 4.2:

    In order to facilitate the transition, CAs will start issuing
    certificates using the Algorithm B in a hierarchical top-down order.
    In our example, CA Y will issue certificates using the Algorithm B
    suite only after CA X has started to do so (CA Y Ready Algorithm B
    Date > CA X Ready Algorithm B Date).  This ordered transition avoids
    the existence of mixed certificates.

>...
>
>	Also in the same section 6, I think that there is important 
>to mention that in phase 0 (coming back to) the objects signed with 
>C are not longer valid.

Section 4.8 (Return to Phase 0) says:
	At this phase, ALL signed product sets using Algorithm Suite
	C MUST be considered invalid.  CAs MUST neither issue nor publish
	signed products using Algorithm Suite C.

Section 6 discusses how to deal with signed products when more than one
instance exists, under different alg suites.  Since 4.8 says that CAs MUST
NOT issue or publish Suite C products, I don't think we need to say anything
in section 6.

Hope this helps,

Steve

---

From: Arturo Servin <[email-masked]>
Date: Tue, 21 Jun 2011 12:46:59 -0300

Stephen, 

	Thanks for the reply, it clarifies my questions.

	Just one nit:

> NOT issue or publish Suite C products, I don't think we need to say anything

	Would it be possible to say what to do to validate objects in 4.5? Perhaps:

"
   An RP that validates all signed product sets using both Algorithm
   Suite A or Algorithm Suite B, SHOULD expect the same results. Objects are valid if they are signed using either Algorithm
   Suite A or Algorithm Suite B.
"

	Or something like that. This is mention in 6, but I think it would be good to mention it (very simply) before.

Regards,
-as

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Jun 2011 11:59:26 -0400

At 12:46 PM -0300 6/21/11, Arturo Servin wrote:
>    Suite A or Algorithm Suite B, SHOULD expect the same results. 
>Objects are valid if they are signed using either Algorithm

We could add text to 4.5 to make it clearer what an RP ought to do, 
but I fear  that the text above might confuse an RP.

When I read it I get the sense that different answers from the two 
alg suites indicates a problem. What we want to say is that an RP can 
use validated results from either set of signed objects. So, if you 
fetch both sets, and validate one set first, then you are done. if 
you try to validate one set and fail, then try the other. if that one 
validates, you are OK. Only of both sets cannot be validate is there 
a problem.

Steve

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 22 Jun 2011 10:39:43 +0200

Hi Arturo,

> 	In phase 4 the table has indent issues too.

(Roque) thanks, will correct.

>    published at their corresponding publication points."

(Roque) See Steve's answer

> 	In section 5 I have a basic question What happen if the child ask the parent to sign with Alg. B but the parent only supports A, it just fails? Is there any message defined in the up/down specific…

(Roque) I want to add that each algorithm suite correspond to a different "resource class" of the provisioning protocol. Consequently, you would be trying to access a class that does not exist in the server and you should get the error code : "1201 request - no such resource class"

Thanks!

Roque