[cabfpub] Ballot 106 - Extended deadline to prohibit OCSP good response for non-issued certificates

[Tom Albertson]

I was away on vacation until the middle last week, what did I miss?  Well, Ballot 106 apparently.  Which has received a lot of thoughtful comments and criticisms, but is not receiving enough support to approve extending the deadline for a few months for reconsideration of the change to the BR Section 13.2.6.  So respectfully on behalf of Microsoft I'd like to withdraw the ballot for additional work, until such a time that we may resubmit it for your consideration. 

All the best,

Tom

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Stephen Davidson
Sent: Tuesday, July 23, 2013 3:31 PM
To: Chris Palmer; Rob Stradling
Cc: CABFPub
Subject: Re: [cabfpub] Ballot 106 - Extended deadline to prohibit OCSP good response for non-issued certificates

Making sure we are on same page.  It's not about standing up a new OCSP responder, it's changing the way that OCSP works.

Before:  More or less universally OCSP consumed CRL.
Diginotar: Certs were issued that the CA did not know it issued, therefore they could not be revoked.
After:  OCSP must be based on complete whitelist.

The issue is that - outside of the top SSL CAs - many CAs use OCSP software from external vendors.  CA/B Forum never communicated with those vendors that it was changing, in effect, a standard mode of operation.
And major changes needed to be made to expose a whitelist to the OCSP.  That's messing with the CA not just tweaking an addon.
In some cases this new setup needs to be signed off by external accreditors/regulators from a security perspective (not just a "does it meet the changed BR requirement" perspective).
Some external OCSP vendors were fast to implement patches for OCSP whitelist when used with their own CA - claiming compliance with this requirement - but patches when using an external CA have been much slower.




________________________________________
From: public-bounces at cabforum.org [public-bounces at cabforum.org] on behalf of Chris Palmer [palmer at google.com]
Sent: Tuesday, July 23, 2013 6:45 PM
To: Rob Stradling
Cc: CABFPub
Subject: Re: [cabfpub] Ballot 106 - Extended deadline to prohibit OCSP good response for non-issued certificates

On Tue, Jul 23, 2013 at 2:25 PM, Rob Stradling <rob.stradling at comodo.com> wrote:

> Unless Google have backtracked and I missed it, Chrome only uses OCSP 
> when the TLS server sends a Stapled OCSP Response.  So in the 
> (majority) case of lack of support for OCSP Stapling by TLS Servers, 
> Chrome won't check OCSP _at all_.
>
> So I'm puzzled.  Why would you remove EV indicators due to 
> non-compliant OCSP in the many cases where you're not actually relying on OCSP at all?

When validating EV certificate chains, Chrome first checks the CRLSet, if the issuer is covered by one. That gets us the benefit of revocation without the latency cost. If no CRLSet covers that issuer, we check any stapled OCSP. Failing that, we do check OCSP, taking the latency hit.

A CA that has trouble standing up a new OCSP server in a timely manner is not one we'd like to give EV treatment to. This is especially important for OCSP Must Staple to be viable.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public