On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote:
Since Sandy's Last Call on this document there have been a few
changes to the document which I should note here.
...
Following advice from Steve Kent, the section on Trust Anchors was
revised (section 6). The change has concerned the terminology used to
described the various structures proposed in the TA model.
The clarifications and additions in section 6.3 are a major
step forward in understanding the intent of the draft with
respect to Trust Anchors. With the improved understanding,
there are some questions raised as to how exactly the full
set of assertions should be obtained for any given Internet
numbering resource.
The draft uses the term "default trust anchor collection" in
section 6.3 ("Relying Parties can assemble the default trust
anchor collection by using the registry TA certificate for each
nominated trust anchor...") but doesn't specify how to navigate
the multiple RPKI hierarchies that occur only in the presence
of a "trust anchor collection", nor does it provide guidance
on to perform overall interpretation of multiple valid assertions
which might occur in presence of a "trust anchor collection".
The semantic logic regarding how to handle sets of overlapping
and contradictory assertions is essential for consistent
interpretation of the certificates contained in the full set
of RIR/IANA RPKI hierarchies. Note that RFC 3779 not only
doesn't provide any assistance in resolving this situation,
it specifically sets rules to prevent such an situation from
occurring:
"Sections 2 and 3 specify several rules about the encoding of the
extensions defined in this specification that MUST be followed. These
encoding rules serve the following purposes. First, they result in a
unique encoding of the extension's value; two instances of an
extension can be compared for equality octet-by-octet. Second, they
achieve the minimal size encoding of the information. Third, they
allow relying parties to use one-pass algorithms when performing
certification path validation; in particular, the relying parties do
not need to sort the information, or to implement extra code in the
subset checking algorithms to handle several boundary cases (adjacent,
overlapping, or subsumed ranges)."
In its present form, the draft departs from the single certificate
hierarchy envisioned in RFC 3779 ("IP address space is currently
managed by a hierarchy nominally rooted at IANA, but managed by
the RIRs"), and thus makes numerous combinations of conflicting
assertions possible for the same numbering resource. Without
unstated information on how to obtain and correctly interpret
such combinations, the ambiguities that result prevent using
the proposed model with multiple RPKI hierarchies to ascertain
information for a given numbering resource with any degree of
certainty. As this is *the* utility value of an RPKI system
for many in the community, I'd recommend we either correct the
model or supply the missing information which will allow for
deterministic use of the total RPKI infrastructure.
/John
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
