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

[Ryan Sleevi]

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

>
> On Tue, Feb 4, 2014 at 6:38 PM, Jeremy Rowley <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] *On Behalf Of *Wayne
>> Thayer
>> *Sent:* Tuesday, February 04, 2014 7:33 PM
>> *To:* Ryan Sleevi
>> *Cc:* therightkey at ietf.org; Ben Laurie;
>> 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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140204/34aa8118/attachment-0003.html>