On 16/06/2010, at 7:20 AM, Sandra Murphy wrote:
>
>
> On Mon, 14 Jun 2010, Sean Turner wrote:
>
>> 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:
>>>> 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."
>>> 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?
yes, that is the implication.
> 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".
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 sign
ed 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 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.
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
