[cabfpub] [cabfman] Update of Yngve's BR 1.1 issues + #10

Yngve N. Pettersen (Developer Opera Software ASA) yngve at opera.com
Fri May 25 19:07:09 UTC 2012

On Fri, 25 May 2012 19:49:43 +0200, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

> Yngve,
>> The scenario I write about here should be fairly infrequent; preferably  
>> it
>> should never happen. If it should happen, a few seconds delay is not a
>> problem, but we need a hard fail for the site using it.
> A few seconds delay *is* a problem. At the CABF Revocation meetings and  
> lists, I've heard several browser vendors complain that CAs take too  
> long to respond to OCSP requests. I doubt anyone would implement  
> hard-fail if they had to wait several seconds to get a response.

I suspect you are confusintg two different cases: The normal case, and the  
abnormal case.

In the normal case, yes, the lookup delay should be as short as possible.  
But this proposal is not about the normal case.

In the abnormal case, when the client is asking for the status of a  
certificate that according to the responder's own databases does not  
exists, and never existed, then a longer delay in order to phone home in  
order to make sure (it might have been issued since the last update from  
home) can be tolerated.

>> Which is generally considered non-fatal by many, if not all, browsers (I
>> seem to recall FF consider such returns fatal). In fact, in the Opera
>> 8.5x/8.6x timeframe we observed this response code from a major CA for  
>> two
>> *weeks*, among several such incidents.
> Instead of going to extreme measures like redefining established RFCs,  
> let's just not tolerate such behavior from CAs! The whole point of

That is part of the revocation workgroup goals. And, currently, we don't  
see such failures often, although I did last see an OCSP happen when I was  
booking the hotel for the Governance meeting in April.

However, we are currently dealing with the legacy of those previous  
failures, and the revoked status is AFAIK the only response we can be sure  
all clients treat as a fatal error, and for a fraudulently issued  
certificate it is also the correct response (or will be as soon as the CA  
takes notice)

> Baseline Requirements is to raise the bar for all CAs. IMO, that's more  
> easily achieved than changing RFCs.

Yngve N. Pettersen
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01

More information about the Public mailing list