|
|
FGs are already a locus of trust: By peering with tree roots, they
effectively vouch for the validity of roots already. For each FG to
provide a list of certificates for the roots with which it peers is
conceptually no different than providing a list of DNS names for these
roots, and offers lots of security benefits. (If there are bandwidth
concerns, you could just as easily define a mechanism for querying for
specific certs or domain names.)
I'm not sure what the basis is for your argument that this type of
cross-certification doesn't scale. Any given FG is only concerned with
the roots from which it receives information, and for any given
validation resolver/seeker is only concerned with certification of a
root by its FGs. So the number of certs at each FG scales as O(#roots)
and the number of certs for each resolver/seeker validation scales as
O(#peeredFGs) in the worst case. Cert path length only grows as
O(avgTreeDepth + 1), since a FG can create new certs for roots it learns
about through its peers.
--Richard
Henning Schulzrinne wrote:
However, unless there is a global root, the VSP has no way to
distinguish a valid Taiwanese cert from some randomly created one. Just
being able to retrieve the cert makes no difference. The impostor can
point to a cert by his best buddy and the VSP has no way to distinguish
them. The only good way is to recognize, ssh-style, that the new
certificate for Taiwan differs from the one the VSP saw last week, which
means that the new one is probably dubious. This may well be sufficient
in practice.
I don't see how you avoid either cross-certification, which doesn't
scale, or a global root certificate. ISPs have a far easier time with
that, since AS "territories" are not in dispute, for example.
Richard Barnes wrote:
Yes, whoever validates the signature an object signed by the Taiwanese
LoST server will need to get certificates from Taiwanese tree. This
is not a hard problem: There are existing mechanisms to do this using
LDAP, FTP, and HTTP (RFC 2559 and 2589). The RIRs are just throwing
everything in one big, distributed database that ISPs fetch using rsync.
Also, remember that this validation doesn't necessarily have to be
done in real time with the call. I think it was Barbara that said in
an earlier discussion that it would be good enough to have a forensic
capability.
--RB
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|