On Dec 5, 2008, at 5:31 AM, Geoff Huston wrote:
...
I am arguing that the res-cert draft is appropriately phrased in
making no particular call on IANA to represent itself as the "root"
TA fpr the RPKI, and arguing that the draft is appropriate in that
it paints the picture that the selection of TA material is a matter
for relying parties to determine and simply describes how TA
material can be packaged in a way that creates stable TA material.
i.e. I am not heading down the path of saying where it should be - I
am limiting myself to a "not here please" statement.
Geoff -
That indirection would be a wonderful, elegant solution to
the situation, but unfortunately in its present form it
creates much larger problem than it solves.
In particular, we need to keep in mind that the usefulness of
the RPKI system for most parties is going to be predicated
upon providing a well-understood, deterministic mechanism for
verification of assertions across the entire Internet numbering
resource space.
The ability to perform such validation is well-defined in a
world with a single PKI hierarchy covering the resource space,
and (with all due respect to drc :-) it would be understandable
if an IETF WG decided omit specification of the TA entity in
the IANA Considerations section due to the inherently political
nature of the question, and with the hope that the Trust Anchor
determination for such a system would indeed be addressed
someplace else. While this would fail to allow for immediate
implementation of the full desired functionality, advancing a
res-cert draft without the TA specified would still allow for
technical validation of the solution and insertion of the
appropriate TA once that matter had been settled "elsewhere".
However, the res-cert-15 draft sidesteps this issue instead
by introduction of the alternative of having a "trust anchor
collection"; i.e. multiple RPKI certificate hierarchies to
cover the entire Internet numbering resource space. This
proposal of multiple PKI hierarchies for a single resource
space is completely new technical construct which lacks
definition of many desired operations such as the process
for overall assertion validation, and process for transfer
of resources between RPKI hierarchies.
As a result, the IETF is being encouraged to advance an
incomplete *technical* solution. Even if a well-understood
and accepted set of "trust anchor collection" material is
determined elsewhere sometime in the future, it's inclusion
still leaves unaddressed how a third-party makes use of the
constellations of RPKI certificate hierarchies to come up
with a generally understood consistent answer in validation
of any given RPKI assertion, nor would it address how routine
PKI functions should be implemented between the multiple RPKI
hierarchies that have been introduced as the "solution" to the
TA specification problem.
It's not the omission of the "root" TA for RPKI which is the
issue, it's the introduction of the ill-defined technical
construct of a "trust anchor constellation" which (IMHO) makes
the current res-cert draft fundamentally flawed.
My related observation is pretty much the same as yours - these are
thorny matters with many interests and perspectives. I for one don't
see this matter being resolved by a simple SIDR WG discussion - oh
no - thats just the opening statements in something that I fear will
carry on, like DNSSEC, for a decade or longer. So maybe I should
just reconcile myself to the fact that progress on these drafts is
not going to be glacial - its going to be geological, and I should
spare my fingers the trouble of typing too much too early, becuase
it seems that this particualr set of issues is going to be hanging
around for decades, like this complete set of SIDR WG drafts. Oh
what fun. not.
The set of changes getting from res-cert-13 to res-cert-15
introduces technical ambiguity as noted above, and it seems
quite appropriate that incomplete specifications move at
glacial pace, if at all.
/John
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
