<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-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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">Rolling out a new extension and tying the value to the vetting level isn’t trivial to implement in some of the products, unfortunately. DV is easy because we
verify the domain upon issuance, so those have all been compliant with the 10 methods as of March. The issue is with the managed PKI (similar to Entrust I believe). Knowing the method and the validation version for some of the older domains is “hard”, but
given sufficient time to comply (or sufficient time before browsers penalize certs with no value or old values), we can do it.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">What is the proposed timetable in the ballot for having this extension implemented? I’m assuming CAs can issue without this extension and those would be treated
like certificates based on outdated validation methods.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Do you have a timetable and plan for how Google would use this data to degrade the UI or block access?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Gerv: Same question for you, what would you do this this data?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><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>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Wednesday, May 17, 2017 2:34 PM<br>
<b>To:</b> Gervase Markham <gerv@mozilla.org><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <public@cabforum.org>; Doug Beattie <doug.beattie@globalsign.com><br>
<b>Subject:</b> Re: [cabfpub] Preballot - Revised Ballot 190<o:p></o:p></span></p>
</div>
</div>
<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 Wed, May 17, 2017 at 2:23 PM, Gervase Markham <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.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">
<p class="MsoNormal">On 17/05/17 18:04, Ryan Sleevi via Public wrote:<br>
> I totally appreciate that sentiment, but you realize one area of the<br>
> concern and issues has been the proposal - made by Kirk, Gerv, and<br>
> Jeremy - to allow the reuse of insecurely-validated domain names.<br>
<br>
This is why I am proposing this. Not because I like it, but because CAs<br>
have not kept records of which method was used, any per-method variance<br>
would require them to redo all validations. (And I'm not up for<br>
requiring every CA to redo every validation, either, and it wouldn't<br>
pass even if I was.) So we sigh, grandfather everything in one last<br>
time, and make it a requirement that CAs record the method used so that<br>
in future, we can do method-specific rules.<br>
<br>
What's the alternative proposal, given that many or most CAs can't do<br>
per-method rules right now?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The proposed extension would be simply that the CAs which haven't maintained those records can still signal a BR version 1.4.2 (or 1.4.1 or equivalent). As they gather/complete such records, they can signal a BR version 1.4.x.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As those who have maintained records revalidate, they can signal 1.4.x. If they reuse information, and it wasn't to 1.4.x, they can signal 1.4.2<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So the capability remains. The signalling is optional until some phase in, with the intent that in the future, it can make such grandfathering technically reliable, which can open up greater flexibility for CAs and the ecosystem in assessing
the risk of accepting such certificates. Modulo things which undermine the underlying cryptographic signature (e.g. the choice of algorithm and keys), this allows us greater flexibility to discuss how best to grandfather other aspects, whether about the certificate
themselves or the issuance systems. <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>