On 10/12/2008, at 3:07 AM, Heather Schiller wrote:
Stephen Kent wrote:
Steve
P.S. Irrespective of my analysis above, yes, I do prefer a singly-
rooted PKI, with IANA as the only TA, but I can live with a set of
TAs so long as I can count them on my fingers, and they all are
authoritative for the resources in question :-).
_______________________________________________
Steve, That's the concern -- what happens if 2 RIR's assert
authority to the same resource?
WG chair hat off
And no I'm not Steve either. :-)
There is no protection anywhere in the RPKI to prevent overlap as an
intrinsic property of the RPKI in the case where a single issuer may
certify the same resource to two different entities simultaneously.
Certificates do not generally prevent this situation of overlap.
And in some cases this may be a feature rather than a bug. When you
consider the case of a transfer of resources between two entities it
may be prudent to certify the new entity with the resources while the
old entity is also certified with the resources in order to allow
relying parties to synchronise their local cached state of the
distributed repository with the new entity's certified resources
before the CA revokes the old entity's certificate that included the
transferred resources.
As far as I can tell certificates cannot provide any particular
"protection in terms of duplication. The protection, and assurance, is
reliant on the accuracy and integrity of the processes used by all
involved parties in the correct and diligent administration of number
resources. I don't see how certificates can provide any intrinsic
protection against procedural failures - it is incumbent on the CAs
here to be very diligent in their administration of these resources
and ensure that their records, and their issued certificates are
accurate.
As far as I understand the situation this statement applies
irrespective of any particular TA model.
regards,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
