On Nov 6, 2008, at 2:03 PM, Sandra Murphy wrote:
One clarification in res-cert-14 (section 1, page 4-5) indicates:
While this profile describes the structure of a default Trust Anchor
for this PKI, Relying Parties (RPs) in this PKI are free to select
the trust anchors upon which they rely, and thus the PKI as viewed
by
RPs need not match the public resource allocation hierarchy as
described here.
So while the intent of the RPKI is to mirror the allocation hierarchy,
Is it?
the relying party may select a trust anchor that is not the IANA, so
the RPKI mirrors only the allocation relationship of the public
resource allocation hierarchy, not necessarily the tree itself with
IANA at the apex.
There's no requirement that IANA sign anything (or any requirement
that any other part of the existing public resource allocation
hierarchy sign anything), so there's no need for an IANA
considerations section.
Does that clear up your question?
This discussion, and that of BOAs et al. have me wondering if we
shouldn't be talking more about where that apex falls, and if it's
one or six, and the implications of all these things, as they're
sure to have considerable impact on operational and deployability
work we do here.
I believe there are indeed considerable IANA implications in this
discussion and this is something that needs to be well understood
when architecting solutions in this area.
With that, I'm quite interested in understanding any perspectives
folks are willing to provide.
Thanks!
-danny
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr