<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 4:46 PM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-8813041845444114034WordSection1">
<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. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></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?</span></p></div></div></blockquote><div><br></div><div>I was thinking SHOULD effective immediately (since we know SHOULDs are useless as policy), but a MUST with something larger - perhaps even as late as a year out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-8813041845444114034WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">  I’m assuming CAs can issue without this extension and those would be treated
 like certificates based on outdated validation methods.</span></p></div></div></blockquote><div><br></div><div>Exactly :) There's a large LARGE corpus of certificates (e.g. everything out there) that wouldn't have this extension for at least (phase in time + validity time). So if we phased in within a year, it'd still be effectively four years before this would be reliable. But that's all the more reason to specify it _now_, particularly when it's most meaningful/impactful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-8813041845444114034WordSection1">
<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?</span></p></div></div></blockquote><div><br></div><div>I think you're reading into something that I didn't say. I think it's important to simply be able to measure and assess - much like the conversations related to Enterprise RAs.</div><div><br></div><div>If there was a misissuance, for example, imagine how useful it would be to be able to programatically identify which are the 'affected' certs - and which were issued with more modern ways.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-8813041845444114034WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div><br></div></div>