Hi Steve,
On 17/09/2009, at 1:53 AM, Stephen Kent wrote:
In the local TA management scheme I described, an RP gets to specify
the set of resources it believes is associated with a given key
(cert). The software enables an RP to assert what it "knows" to be
true, overriding what the
"knows" == "believes" ;-)
repositories and the putative TAs may assert. So, if there is a
conflict relative to the info that the RP says it knows to be true,
what the RP says it knows to be true prevails (locally). If the
conflict arises at a point that is below a cert that the RP ad
adopted as a TA, and if the RP has no other info about the resources
in question, then no, the software can't help with such a problem
problem.
right, so the software isn't currently intended to traverse the
'assimilated relying party rpki' to pick out conflicts. nor highlight
that in terms of the TA set chosen by the relying party. (I'm saying
that is a deficiency, just thinking aloud)
I think references to the IANA->RIR->... hierarchy are appropriate
for describing the extant allocation process. Moreover, it is
appropriate to note that the RPKI is designed to mimic that
hierarchy. It is also important to note that the choice of TAs is
always a local matter. If folks want, I can prepare an
(informational) I-D that describes one way of managing TA locally,
as per my presentation at the SIDR meeting.
I think I would like to see such an I-D.
Sure. But if we are looking for a qualitative trust statement of
TAs, where does one look? Or don't we? Is this just not a problem
to care about?
Statements about perceived trust in TAs are useful in PKIs that
anoint 3rd parties as TAs, independent of real world authorization.
The RPLI is not such a PKI. Instead it seeks to have the real world
entities that manage allocation of resources act as CAs. I would
urge us to NOT try to make the RPKI into a trusted 3rd party PKI.
while I agree the intent isn't to make a 3rd party PKI, won't that
happen anyway? At least I see it as likely, irrespective of the
allocation resource hierarchy.
Cheers
Terry
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
