<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<div>On 12/15/2014 11:02 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">As discussed on our call last week, I'd like to put
together a ballot requiring that CAs support IPv6 for their
external (relying party facing) infrastructure.</div>
</blockquote>
<br></span>
Funny that you want to start with that part first - most of the time
that's the part CAs have the least control over it and depend on
third parties.</div></blockquote><div><br></div><div>I'm not sure I follow this. CAs aren't required to delegate their infrastructure out to third-parties. If they chose to, then they have to pick third-parties who are capable of meeting the Baseline Requirements (e.g. the current 24/7 uptime requirements or the 10 second availability).</div><div><br></div><div>If a new requirement comes down, the question is how long will it take for the CAs to either get their infrastructure updated, get their third parties to update, or transition to new third parties. That's fundamentally the question I'm asking. This is surely NOT a problem that's impossible. If CAs are telling third parties that they need IPv6 support, then eventually there will be IPv6 support.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>As both servers and clients transition to IPv6-only
networks, the goal is to ensure that services RPs need are
accessible. </div>
</div>
</blockquote>
<br></span>
Hardly 5 % as of today - and I assume they all (must) support IPv4
in any case since the vast majority doesn't support IPv6. <br></div></blockquote><div><br></div><div>That's an assumption that is, in part, caused by the unavailability of some services over IPv4. This is a collective action problem, as the CA industry is quite familiar with, so I don't understand why "we don't support it today" is necessarily an argument for why "we shouldn't support it tomorrow".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Before proposing dates/timelines, it'd be helpful to
understand where the CA's current infrastructure and plans
are, so that we can reach a happy medium.</div>
</div>
</blockquote>
<br></span>
I believe this is premature by any standard. Of course CAs may and
probably want to support IPv6 as soon as there is a real demand for
it. It's also not overly difficult - but the real problem is the
third party service providers involved including CDNs and ISPs which
must provide IPv6 support first before the CA can.<br></div></blockquote><div><br></div><div>I fail to see how this is premature. It's exactly the same conversation that had to happen with SHA-1 - CAs weren't moving to support it, so eventually timelines had to be set. This is a classic collective action problem, and it's simply a question of what is a reasonable timeframe for CAs to move, and why.</div><div><br></div><div>You've indicated "CDNs and ISPs must provide IPv6 support first". A number of them do. A number of them don't. The entire point of a preballot is to get a sense of what those numbers are, and for CAs that have contracts with those that do not support IPv6, how long would it take a reasonable CA to support it?</div><div><br></div><div>You've indicated it's not overly difficult, so is it a matter of 3 months? 6 months? 10 years? That's the set of information that's useful to discuss, rather than assume it will happen.</div><div><br></div><div>Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
But besides that I'm a bit curious why Google would have even the
slightest interest in revocation checking services and how they are
accessed considering that its products don't check revocation in
first place :-)<br></div></blockquote><div><br></div><div>1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates.</div><div>2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses. </div><div><br></div><div>I appreciate the feedback, Eddy, but your response seems mostly reactionary, without having read the proposal or justifications provided therein. It'd be helpful to know what concrete concerns you'd have and what it would take to address them.</div><div><br></div><div>Regardless, I don't think it's a good state in the present form that, for counter-example, a CA could provide an OCSP responder or AIA caIssuers solely available over IPv6, when as you note, there's a non-trivial majority of clients with IPv4-only stacks. So consider this proposal as a way to close that ambiguity as well.</div></div></div></div>