<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 8:31 PM, Wayne Thayer <span dir="ltr"><<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div><div class="h5">
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 4, 2014 at 7:12 PM, Wayne Thayer <span dir="ltr">
<<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <span dir="ltr">
<<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.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">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’m confused as well.  Does that mean Android will start showing an EV indicator?</span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> therightkey [mailto:<a href="mailto:therightkey-bounces@ietf.org" target="_blank">therightkey-bounces@ietf.org</a>]
<b>On Behalf Of </b>Wayne Thayer<br>
<b>Sent:</b> Tuesday, February 04, 2014 7:33 PM<br>
<b>To:</b> Ryan Sleevi<br>
<b>Cc:</b> <a href="mailto:therightkey@ietf.org" target="_blank">therightkey@ietf.org</a>; Ben Laurie;
<a href="mailto:certificate-transparency@googlegroups.com" target="_blank">certificate-transparency@googlegroups.com</a>; CABFPub<br>
<b>Subject:</b> Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan</span></p>
</div>
</div>
<div>
<blockquote style="border:none;border-left:solid #b5c4df 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in">
<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"><span style="font-size:10.5pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Calibri,sans-serif">Hi Wayne,</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Calibri,sans-serif">Considering we already do not indicate EV on Android, nor have we ever, I don't think this perceived loss of functionality is as significant as you may believe.</span></p>

</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Calibri,sans-serif">Further, considering the very real and distinct performance characteristics of mobile (radio warmups, RTTs, initcwnds), the idea of fetching OCSP, or, worse, CRLs - especially
 when some CAs have CRLs that are quite large (20+ MB) - in order to assure the EV display is... non-ideal. So again, the EV indicator on mobile is not as strong or as present as it may be on desktop platforms.</span><span style="font-size:10.5pt"> </span></p>

</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Calibri,sans-serif">In that case, what does this statement mean?</span></p>
</div>
<div>
<p style="margin:0in;margin-bottom:.0001pt"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif">Chrome for mobile platforms will cease to show EV indicators for certificates that are not CT qualified according to the criteria below.</span></p>

</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It means that for any CAs that hope to be recognized as EV on Chrome for mobile platforms (which include iOS), implementing CT by the dates outlined is seen as a requirement for such treatment. We wanted to specifically call attention to this - the whitelist
 is seen as a temporary measure for Desktop, but given the unique characteristics of mobile platforms, we're pursuing this requirement at a more aggressive pace.</div>
<div><br>
</div>
<div>While Chrome for Android - and the Chrome-based WebView, as the WebView preceding it - do not provide special treatment for EV, any future plans for EV indications on these platforms have incorporated the above requirements and dates.</div>

<div> </div>
</div>
</div>
</div>
</blockquote>
</span></div>
<div>In that case, my original objection stands – this policy retroactively downgrades existing EV certificates if and when a mobile platform chooses to implement an EV indicator. There are certainly times when it’s necessary to apply a new policy to existing
 certificates to protect relying parties, but IMO this isn’t one of them.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Wayne,</div>
<div><br>
</div>
<div>While I appreciate your position, I am absolutely baffled as how you can present this as a "downgrade".</div>
<div><br>
</div>
<div>If and when Android supports EV, certificates that fail to meet this requirements will continue to appear exactly the same as they do today and they have in the past. Certificates which do conform to these program requirements will, presumably, be granted
 distinguishing UI. To the customer who purchased a certificate today, their certificate will continue to appear in that future world exactly how it appears today, presumably - providing them exactly what they expected.</div>

<div><br>
</div>
<div>I can only interpret your objection as an objection to root store programs requiring additional requirements above and beyond that of the EV Guidelines. I can only presume that you have similar objections to root store programs requiring additional requirements
 above and beyond the Baseline Requirements - as (to the best of my knowledge) - every root program already does today.</div>
</div>
</div>
</div>
</blockquote>
</span>
</div></div><div>
<div><br>
</div>
<div>Ryan,</div>
<div><br>
</div>
<div>I believe that I have repeatedly stated my support for Google’s overall plan to implement CT, so please don't blow this discussion out of proportion by interpreting it as me objecting to anything and everything a root store operator chooses to do unilaterally.
 On the other hand, more coordination amongst root store operators would be great!</div>
</div><div class="im">
<div><br>
</div>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Could you perhaps quantify exactly what you see as the downgrade, given that such a hypothetical user experience (as again, EV is not presently implemented in Chrome for Android) does not change?</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div><div>My concern is one of timing. Rather than letting perfectly good EV certificates expire naturally or be grandfathered in, they are treated as non-EV certificates under this policy. When I use the terms ‘downgrade’ and ‘retroactive', I am specifically referring
 to a policy in which some EV certificates issued prior to the implementation of the policy (retroactive) are treated as non-EV (downgrade). I now understand that there is currently no change in how they are displayed in Chrome for Android, but (1) the policy
 and your comments imply that there will be, and (2) however hypothetical it may be, a precedent is being set here.</div>
<div><br></div></div></blockquote><div><br></div><div>I'm still not sure I follow the argument, so apologies for my ignorance. EV treatment will only be granted to certificates that conform to these policies. Are you imagining a scenario in which a certificate appears as EV in Android (which again, is not a feature currently implemented), and then later in the future, no longer does?</div>
<div><br></div><div>And I'm not sure what your view of the precedent is. Chrome has already applied policies it believes are necessary to protect users - we no longer treat internal host names as secure, for example, independent of the Baseline Requirements 2015 sunset. Equally, we are aggressively proceeding with ensuring that the security indicator is appropriate for certificates that fail to meet minimum cryptographic requirements or validity dates.</div>
<div><br></div><div>A certificate which does not display as EV today, and which does not display as EV tomorrow, does not particularly seem like a "downgrade"?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>
</div>
<div>If this still doesn’t make sense, maybe we can discuss it at the CAB Forum meeting in a few weeks.</div>
<div><br>
</div>
<div>Also, can someone answer my question on point #5 in my original message?</div>
<div><br>
</div>
</div>

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