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

[Ryan Sleevi <[e-mail]>]

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

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