[cabfpub] [therightkey] Updated Certificate Transparency + Extended Validation plan

[Wayne Thayer]

On Tue, Feb 4, 2014 at 7:12 PM, Wayne Thayer <wthayer at godaddy.com<mailto:wthayer at godaddy.com>> wrote:

On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
I’m confused as well.  Does that mean Android will start showing an EV indicator?
From: therightkey [mailto:therightkey-bounces at ietf.org<mailto:therightkey-bounces at ietf.org>] On Behalf Of Wayne Thayer
Sent: Tuesday, February 04, 2014 7:33 PM
To: Ryan Sleevi
Cc: therightkey at ietf.org<mailto:therightkey at ietf.org>; Ben Laurie; certificate-transparency at googlegroups.com<mailto:certificate-transparency at googlegroups.com>; 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.

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140205/a3001ad4/attachment-0001.html