Subject: [sidr] Question about draft-ietf-sidr-rpki-algs migration text

From: Sean Turner <[email-masked]>
Date: Mon, 14 Jun 2010 15:08:38 -0400

Geoff,

In the rpki-algs document there's a note in section 3 that talks about 
algorithm agility.  Part of it copied below:

The alternate approach, of allowing
multiple signature algorithms in the RPKI certificate profile, and in
the specification of CMS signatures as used in manifests, ROAS, other
signed objects, and in the provisioning protocol, allows for
algorithm transition to occur within a single RPKI framework, and
allows for individual CAs to commence use of multiple algorithms in a
piecemeal fashion without reliance on the algorithm transition of the
immediate superior CA and without a forced synchronisation of
algorithm transition with subordinate CAs.  In the light of this
consideration, this document recommends the comprehensive revision of
the existing RPKI specification and architecture documents to include
provision for multiple signatures with multiple algorithms in order
to support an orderly transition to longer key sizes and to other
signature algorithms in the RPKI.

Question: Is the first sentence suggesting that the certificates 
should have two signatures applied?  I.e., do you consider a 
certificate to be an "other signed object."

spt

---

From: Sean Turner <[email-masked]>
Date: Mon, 14 Jun 2010 17:41:00 -0400

Geoff Huston wrote:
> On 15/06/2010, at 5:08 AM, Sean Turner wrote:
> 
>> Geoff,
>>
>> In the rpki-algs document there's a note in section 3 that talks about algorithm agility.  Part of it copied below:
>>
>> Question: Is the first sentence suggesting that the certificates should have two signatures applied?  I.e., do you consider a certificate to be an "other signed object."
> 
> nope! (although its an interesting idea, I was assuming that RFC5280 was more or less cast in concrete rather than plasticine.)

This is good news ;)  There's one place to put a signature value and 
it's a single valued field.

spt

> I was referring in that text to signed objects and the use of CMS and the option in CMS for multiple signatures, and I was advocating consideration of an approach that used a single collection of such signed objects. I'm sorry if the words are less than clear. Perhaps they should be removed in the next iteration of this draft in any case.
> 
> Geoff
> 
> 
> 
> 
> 
>

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 15 Jun 2010 17:20:26 -0400 (Eastern Daylight Time)

On Mon, 14 Jun 2010, Sean Turner wrote:

>>> Question: Is the first sentence suggesting that the certificates should 
>>> have two signatures applied?  I.e., do you consider a certificate to be an 
>>> "other signed object."
>> 
>> nope! (although its an interesting idea, I was assuming that RFC5280 was 
>> more or less cast in concrete rather than plasticine.)

Can you say more about what this means for the certificates?

Does this mean that there might be mulitple certificates, one per 
algorithm?  If so, how would this avoid the problems of consistency and 
coherency you note:

                           The latter option, that of the concurrent
    operation of parallel RPKI structures, poses some complex issues in
    terms of synchronisation of actions across the set of RPKI CAs, as
    well as issues of consistency and coherency in the operation of
    multiple parallel RPKI frameworks, as well as the uncertainties
    associated with a global determination of when any such transition
    can be considered "complete".

Pretty sure I'm not understanding the draft's recommendation here.

--Sandy, speaking as someone who wants to clarify the wg document, so 
probably as wg member

>
> This is good news ;)  There's one place to put a signature value and it's a 
> single valued field.
>
> spt
>
>> I was referring in that text to signed objects and the use of CMS and the 
>> option in CMS for multiple signatures, and I was advocating consideration 
>> of an approach that used a single collection of such signed objects. I'm 
>> sorry if the words are less than clear. Perhaps they should be removed in 
>> the next iteration of this draft in any case.
>> 
>> Geoff
>> 
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Jun 2010 08:02:04 +1000

On 16/06/2010, at 7:20 AM, Sandra Murphy wrote:

> Does this mean that there might be mulitple certificates, one per algorithm?

yes, that is the implication.

>  If so, how would this avoid the problems of consistency and coherency you note:
> 

It mitigates, but does not totally avoid these issues. 

It is easier to explain this if you use a taxonomy of the RPKI as having two distinct sets of "things" in it, with one set being the collection of CA and EE certificates and associated CRLs, and the other set being a a collection of digitally signed objects. The objects in the second set can be verified using validation paths that are in effect certificate chains where the certificates are drawn from the first set.

One approach to algorithm migration is to create an entirely different RPKI. That is, the actors need to maintain a new set of certificates that are identical in every respect save for the key algorithm and key values (and any names that are derived from the key values), and also maintain a "new" set of signed objects that are verifiable using exclusively these "new" certificates. 

Another approach to algorithm migration is to maintain a single set of signed objects, but use the multiple signature capability of CMS to allow an object with multiple attached signatures to be verified using either of the signatures, and hence either of the certificate sets and hence either of the algorithms. 

When an entity is capable of supporting the new algorithm it can add the additional signature to the entity's collection of objects that are signed by the entity. When a relying party is capable of using a new algorithm it may attempt to perform verification using the new algorithm instead of the "old" algorithm, and use a "either to validate" condition to ensure that if verification fails in the new algorithm it will try using the old algorithm before pronouncing that the object cannot be verified. There is some form of "fail safe" in this latter scenario becuase even if verification fails in the "new" world becuase of incomplete validation paths (due to lack of comprehensive use of the "new" algorithm by all issuers) there is still the onus on the Relying Party to undertake the same verification task using the "old" algorithm before pronouncing the object unverifiable. If you contrast this to a scenario of two distinct RPKI universes, each populated with its own set of signed objects, then how does a relying party know which signed objects from one RPKI universe are equivalent to which object in the other RPKI universe? Are the two RPKI universes mutually exclusive? Are Relying Parties meant to use one RPKI universe or the other as an  exclusive choice? What happens when the practical outcomes in terms of route origination filters differ between the two universes? Is the lack of clear determinism from the perspective of Relying Parties in the verification outcomes because of the diverse use of two distinct RPKI universes a desirable outcome?

The notes in the algorithm draft advocated the approach to multiple signatures on signed objects as representing some degree of mitigation of the issue of maintaining precise synchronisation of parallel and distinct RPKI universes. In the multi-signature approach there is still the same single collection of signed objects with the same set of intended semantics. The remaining task is to ensure that the two certificate sets offer the same verification outcomes, which looks like being the unavoidable minimal requirement for precise synchronisation in this scenario. 

> Pretty sure I'm not understanding the draft's recommendation here.

the above explanation may help - or of course it may not!

>>> I was referring in that text to signed objects and the use of CMS and the option in CMS for multiple signatures, and I was advocating consideration of an approach that used a single collection of…

My earlier apology over lack of clarity and my intent to remove these comments in the next iteration of the draft in any case still stand.

    Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 15 Jun 2010 18:53:01 -0400 (Eastern Daylight Time)

Thank you.  Yes this helps.

If I've got it correctly now, you are suggesting multiple signatures on 
signed objects as a rendezvous point in the independent parallel 
structures of the certificate side of the systems, a point at which the 
parallel structures must synchronize.

How strict is this synchronization?  The ROA would need to have two EE 
certs, and the requirement is that the ROA IP address prefix "is contained 
within the set of IP addresses specified by the EE certificate's IP 
address delegation extension".  Would you envision that the 
synchronization would insist that the two EE certs have exactly the same 
address delegation extension?  (Eliminating some degree of 
freedom/inconsistency between the parallel structures.)

--Sandy