Subject: Re: [sidr] GOST & SIDR

From: Stephen Kent <[email-masked]>
Date: Mon, 4 May 2009 08:34:12 -0400

I have been ion vacation (yes, again) so I'm very late to this 
discussion.  I think there are some valid issues being raised, and 
some red herrings.

Yes, we need to accommodate algorithm agility. I believe that the 
formats of all of our data structures already do this, i.e., they 
explicitly state which algorithms were used for signing and hashing 
the objects in question.

I am not convinced that the S/MIME cert extension is applicable here. 
My recollection is that this extension is intended to convey 
algorithm capabilities of a recipient to a prospective sender, so 
that the sender can select appropriate algorithms to use in 
protecting a message. Thus the info being communicated is relevant to 
the set of senders who communicate with a given recipient. The 
(public) RPKI context is different; every relying party (primarily 
ISPs) MUST be able to process the signed objects generated by every 
cert issuer (primarily ISPs).

We have not documented how one would transition from one algorithm 
suite to another, given our syntactic ability to express the old and 
new suites.  I agree with Russ's observation that this need not be 
solved immediately, since we have a while before it is likely that we 
will need to do that. Joel's observation that this may require 
parallel sets of certs is certainly one way to do this, and it may be 
the one we adopt. That solution is messy, as Randy noted, but not 
impossible to accommodate.

Sandy noted that islands of RPKI use could employ different 
algorithms without affecting everybody else.  That is true, and is 
relevant for closed RPKI contexts of the sort that we have discussed. 
However, this is different from the public RPKI use that is the 
primary motivation for this work.  I think we need to be more careful 
in our documents to distinguish between these two cases, i.e., the 
public RPKI context and private RPKI contexts.

The message that triggered this thread was prompted by comments from 
Dimitri, and his concern is different from all of the discussion that 
followed on the list. What Dimitri was proposing is that the 
architecture allow country-specific algorithm choices for the 
(public) RPKI.  I think this is a very bad idea. If we agree to do 
this, then there is no limit to the set of algorithms that may need 
to be supported in software (and, eventually, in router hardware), 
and that is not a reasonable outcome.

The (public) RPKI is global in its scope. Thus if different countries 
elect to employ different algorithms these countries are imposing a 
burden on the rest of the relying parties (all other ISPs in the 
world). Or, as someone noted, the allocations and origin AS info 
associated with the ISPs in these countries will be ignored by 
others. Neither if these is a good outcome.

The PKI standards produced by PKIX do not specify any mandatory to 
implement algorithms. This is because those standards are generic and 
may often be used in closed PKIs where the algorithm choices have 
only local impact. This is not true for the RPKI. In this context, a 
mandatory to implement set of algorithms is necessary, and that is 
what has been specified in the cert profile, and maybe in some other 
documents. I agree that we should consolidate the specification of 
this algorithm suite, so that when new algorithms are agreed upon for 
use in the RPKI, the number of documents that need be changed will be 
minimized. Probably the preferred solution here is to focus the 
algorithm specs in the CP, and have the cert/CRL profile, and the ROA 
and manifest specs reference the CP.

We also need to better distinguish the one public RPKI from private 
RPKI contexts. For example, a private RPKI context probably need not 
abide by the same CP as the public RPKI, and thus there is no need 
for these folks to put the public RPKI policy OID in certs used 
exclusively in that context.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 4 May 2009 09:55:39 -0400 (Eastern Daylight Time)

Steve, welcome back from your vacation.

Thank you for your comments.  For one thing, they provide a synopsis of 
the arguments put forth up to this point.  Perhaps it is a good thing to 
have someone summarize an argument chain occasionally, and if that means 
sending someone on vacation, that's tolerable, right?

I would like to clarify one of your comments:

>implement algorithms. This is because those standards are generic and may
>often be used in closed PKIs where the algorithm choices have only local
>impact. This is not true for the RPKI. In this context, a mandatory to
>implement set of algorithms is necessary, and that is what has been
>specified in the cert profile, and maybe in some other documents.

The cert profile currently says that the one algorithm suite is a MUST, 
which I believe means that certs using other algs would be non-compliant. 
I see a difference between that statement and making one algorithm a 
mandatory-to-implement.  Do you?  Can you say which you think is the 
better approach?

--Sandy

On Mon, 4 May 2009, Stephen Kent wrote:

> I have been ion vacation (yes, again) so I'm very late to this discussion.  I 
> think there are some valid issues being raised, and some red herrings.
>
> Yes, we need to accommodate algorithm agility. I believe that the formats of 
> all of our data structures already do this, i.e., they explicitly state which 
> algorithms were used for signing and hashing the objects in question.
>
> I am not convinced that the S/MIME cert extension is applicable here. My 
> recollection is that this extension is intended to convey algorithm 
> capabilities of a recipient to a prospective sender, so that the sender can 
> select appropriate algorithms to use in protecting a message. Thus the info 
> being communicated is relevant to the set of senders who communicate with a 
> given recipient. The (public) RPKI context is different; every relying party 
> (primarily ISPs) MUST be able to process the signed objects generated by 
> every cert issuer (primarily ISPs).
>
> We have not documented how one would transition from one algorithm suite to 
> another, given our syntactic ability to express the old and new suites.  I 
> agree with Russ's observation that this need not be solved immediately, since 
> we have a while before it is likely that we will need to do that. Joel's 
> observation that this may require parallel sets of certs is certainly one way 
> to do this, and it may be the one we adopt. That solution is messy, as Randy 
> noted, but not impossible to accommodate.
>
> Sandy noted that islands of RPKI use could employ different algorithms 
> without affecting everybody else.  That is true, and is relevant for closed 
> RPKI contexts of the sort that we have discussed. However, this is different 
> from the public RPKI use that is the primary motivation for this work.  I 
> think we need to be more careful in our documents to distinguish between 
> these two cases, i.e., the public RPKI context and private RPKI contexts.
>
> The message that triggered this thread was prompted by comments from Dimitri, 
> and his concern is different from all of the discussion that followed on the 
> list. What Dimitri was proposing is that the architecture allow 
> country-specific algorithm choices for the (public) RPKI.  I think this is a 
> very bad idea. If we agree to do this, then there is no limit to the set of 
> algorithms that may need to be supported in software (and, eventually, in 
> router hardware), and that is not a reasonable outcome.
>
> The (public) RPKI is global in its scope. Thus if different countries elect 
> to employ different algorithms these countries are imposing a burden on the 
> rest of the relying parties (all other ISPs in the world). Or, as someone 
> noted, the allocations and origin AS info associated with the ISPs in these 
> countries will be ignored by others. Neither if these is a good outcome.
>
> The PKI standards produced by PKIX do not specify any mandatory to implement 
> algorithms. This is because those standards are generic and may often be used 
> in closed PKIs where the algorithm choices have only local impact. This is 
> not true for the RPKI. In this context, a mandatory to implement set of 
> algorithms is necessary, and that is what has been specified in the cert 
> profile, and maybe in some other documents. I agree that we should 
> consolidate the specification of this algorithm suite, so that when new 
> algorithms are agreed upon for use in the RPKI, the number of documents that 
> need be changed will be minimized. Probably the preferred solution here is to 
> focus the algorithm specs in the CP, and have the cert/CRL profile, and the 
> ROA and manifest specs reference the CP.
>
> We also need to better distinguish the one public RPKI from private RPKI 
> contexts. For example, a private RPKI context probably need not abide by the 
> same CP as the public RPKI, and thus there is no need for these folks to put 
> the public RPKI policy OID in certs used exclusively in that context.
>
> Steve
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 May 2009 10:04:00 -0400

At 9:55 AM -0400 5/4/09, Sandra Murphy wrote:
>Thank you for your comments.  For one thing, they provide a synopsis 
>of the arguments put forth up to this point.  Perhaps it is a good 
>thing to have someone summarize an argument chain occasionally, and 
>if that means sending someone on vacation, that's tolerable, right?

It's a tough approach to the problem, but I'm happy to make the sacrifice :-).

>The cert profile currently says that the one algorithm suite is a 
>MUST, which I believe means that certs using other algs would be 
>non-compliant. I see a difference between that statement and making 
>one algorithm a mandatory-to-implement.  Do you?  Can you say which 
>you think is the better approach?

For the public RPKI, we need a (very short) list of mandatory to 
implement algorithms, and a statement about which algorithms MUST be 
used at any point in time.

I think the cert profile (and the ROA and manifest docs) should 
remove all algorithm references, and have the CP specify algorithm 
mandates.

Steve