[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation

[Brian Smith]

On Fri, Sep 19, 2014 at 4:18 AM, Rob Stradling <rob.stradling at comodo.com> wrote:
> On 18/09/14 22:04, Brian Smith wrote:
>> On Thu, Sep 18, 2014 at 2:08 AM, Rob Stradling <rob.stradling at comodo.com>
>> wrote:
>>> On 18/09/14 04:55, Brian Smith wrote:
>>> It would be great if OCSP Stapling was already deployed sufficiently
>>> ubiquitously for this workaround to be viable.  Unfortunately, it's still
>>> not.
>>
>> There's no way for me to access the accuracy of that statement. Also,
>> your definition of "viable" is very different than mine, because I
>> think browsers shouldn't show the EV indicator unless there's a
>> stapled OCSP response, *regardless* of CT.
>
> Brian, that's an interesting point of view.  Is it just your own private
> opinion, or is it shared by Mozilla?

That is my view.

> IINM, in Chrome's case CRLSets cover all EV certs, so there wouldn't be much
> point making Stapled OCSP a prerequisite for getting the EV indicator.

I think that is debatable. Part of the purpose of requiring a stapled
OCSP response is making up for the limitations of CRLSets. In Chrome's
case, making a stapled OCSP response mandatory for EV would benefit
them because they could remove the EV enries from their CRLSet.
Reducing the size of the CRLSet and/or making room for more non-EV
entries would benefit them, AFAICT.

>> (The only useful thing about EV is its effect on encouraging CT adoption.)
>
> Really?

Yes.

>> That's a private matter between the CAs and Google.
>
> It ceases to be a private matter if we accept that it impacts the BRs/EVGs.

That's circular reasoning. I'm saying the BRs don't need to be changed
because it is a private matter. You are saying it isn't a private
matter because the BRs need to be changed.

Cheers,
Brian