[cabfpub] Preballot for IPv6 Support

[Ryan Sleevi]

On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg <eddy_nigg at startcom.org> wrote:
>
>
> On 12/15/2014 11:02 PM, Ryan Sleevi wrote:
>
> 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.
>
>
> 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.
>

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).

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.


>
>
>  As both servers and clients transition to IPv6-only networks, the goal
> is to ensure that services RPs need are accessible.
>
>
> Hardly 5 % as of today - and I assume they all (must) support IPv4 in any
> case since the vast majority doesn't support IPv6.
>

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".


>
>  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.
>
>
> 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.
>

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.

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?

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.

Consider "Real demand for it" being at least one browser with a non-trivial
user base requesting it.


>
> 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 :-)
>

1) This isn't just about revocation checking. As I noted in the preballot,
it's also about authorityInfoAccess for intermediates.
2) As I explained in the preballot, this also applies to servers' ability
to fetch fresh OCSP responses.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141215/ec8f9bf6/attachment-0003.html>