Roque,
(Roque) I believe the issue with RFC6487 is what "single" means when
in Section 4.8.7 says: "single reference to thepublication point of
the immediate superior certificate".
I agree that 6487 is ambiguous re the cited text. My point, however, is
that it is not appropriate to say that 6487 did something wrong when it
imposed further restrictions on what 5280 says. That's what a profile
often does.
(Roque) The idea is to foster diversity. So, you need to see the union
of all IP addresses you are resolving to make sure that they do not
all depends on one ROA.
I am not sure about what do you meant by Anycast. This is a TCP
service, so there are some load balancing technique that you can apply
that are based on anycasting the DNS servers that resolve the domain
name and have inconsistent zones around the globe but I am not sure
that was your concern.
Anycast is not intrinsically a TCP service; it is an IP layer service.
My question is whether a CA might use an anycast address for access to
publication points, and if so, how would this relate to you proposal to
check that all pub point addresses were not covered by a set of ROAs
associated with the CA. But, I'm willing to defer that question for now.
(Roque) The problem that we were raising on depending on DNS based
mechanisms for a single FQDN, is that you depend on that single FQDN
resolution. With lets say two URI, you can set one operator to be one
CDN and another operator to be a second CDN.
yes, you could do that, but is it necessary? In what other contexts,
where high availability is required, do we define this many ways to
ensure user access to published data?
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
