Re: [therightkey] EXTERNAL: Re: [cabfpub] Updated Certificate Transparency + Extended Validation plan

["Mehner, Carl" <[e-mail]>]

Ryan,

Today EV certificates do display the EV green bar treatment in Chrome on iOS (albeit briefly) as well as a message about validating the organization and location when you click on the certificate (vs just the “website has been verified” that you get in Chrome on Android for EV and on any platform for non-EV certs)



Following the mobile stipulations in number 7 on your document, in the case of Chrome on iOS, this would be the downgrade that Wayne mentions. A certificate appears as EV in Chrome for iOS on 31 Jan 2015, and would not display as EV after 1 Feb 2015.





Carl Mehner



From: therightkey [mailto:[e-mail]] On Behalf Of Ryan Sleevi
Sent: Tuesday, February 04, 2014 10:40 PM
To: Wayne Thayer
Cc: therightkey; Ben Laurie; certificate-transparency; Jeremy Rowley; CABFPub
Subject: EXTERNAL: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan







On Tue, Feb 4, 2014 at 8:31 PM, Wayne Thayer <[e-mail]<mailto:[e-mail]>> wrote:



   On Tue, Feb 4, 2014 at 7:12 PM, Wayne Thayer <[e-mail]<mailto:[e-mail]>> wrote:



      On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <[e-mail]<mailto:[e-mail]>> wrote:

      I’m confused as well.  Does that mean Android will start showing an EV indicator?

      From: therightkey [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Wayne Thayer
      Sent: Tuesday, February 04, 2014 7:33 PM
      To: Ryan Sleevi
      Cc: [e-mail]<mailto:[e-mail]>; Ben Laurie; [e-mail]<mailto:[e-mail]>; CABFPub
      Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan



         Hi Wayne,

         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.

         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.

      In that case, what does this statement mean?

      Chrome for mobile platforms will cease to show EV indicators for certificates that are not CT qualified according to the criteria below.



      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.



      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.



   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.



   Wayne,



   While I appreciate your position, I am absolutely baffled as how you can present this as a "downgrade".



   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.



   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.



   Ryan,



   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!





   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?



   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.





   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?



   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.



   A certificate which does not display as EV today, and which does not display as EV tomorrow, does not particularly seem like a "downgrade"?



   If this still doesn’t make sense, maybe we can discuss it at the CAB Forum meeting in a few weeks.



   Also, can someone answer my question on point #5 in my original message?