At 12:32 PM +1000 9/18/09, Terry Manderson wrote:
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" ;-)
yes, believes is more accurate, but that's why I put the "knows" in quotes :-).
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)
We were told over a year ago that, because of legitimate transfers,
looking for duplicates was bad idea, in the repository system. So,
I'm not sure if we want to do it in the 'assimilated relying party
rpki.'
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.
OK, we'll look into generating one.
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.
One cannot prevent 3rd parties from asserting themselves as TAs, but
the CP does not accommodate such entities as CAs, nor does the
repository system facilitate their use. The local TA management
proposal deals only with LOCAL perceptions of TAs. If an organization
wants to promote it's (local) view of TAs to others, it is up to that
entity to develop the necessary tools to do so, and to convince
others to make use of these tools. I think that represents a
reasonable tradeoff between allowing local TA management and
encouraging 3rd party TAs.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
