<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The proposal is more likely to force CAs into using their own infrastructure to provide revocation information than forcing CDNs and hosting providers to use
IPv6, slowing OCSP response times. However, nothing wrong with gathering the information and looking at which CDNs and providers we need to get on board with the proposal.
<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Monday, December 15, 2014 2:59 PM<br>
<b>To:</b> Eddy Nigg<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] Preballot for IPv6 Support<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Dec 15, 2014 at 1:16 PM, Eddy Nigg <<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 12/15/2014 11:02 PM, Ryan Sleevi wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
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.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">As both servers and clients transition to IPv6-only networks, the goal is to ensure that services RPs need are accessible.
<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
Hardly 5 % as of today - and I assume they all (must) support IPv4 in any case since the vast majority doesn't support IPv6.
<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
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.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Consider "Real demand for it" being at least one browser with a non-trivial user base requesting it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><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 :-)<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) This isn't just about revocation checking. As I noted in the preballot, it's also about authorityInfoAccess for intermediates.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) As I explained in the preballot, this also applies to servers' ability to fetch fresh OCSP responses. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>