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
On Wed, 16 Jun 2010, Geoff Huston wrote:
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 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 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
