[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:08 UTC 2012

On Fri, 25 May 2012 20:09:11 +0200, Ryan Koski <rkoski at godaddy.com> wrote:

> On May 25, 2012, at 9:10 AM, Yngve N. Pettersen (Developer Opera  
> Software ASA) wrote:
>> I object to "unauthorized" because Opera, and probably many other
>> browsers, do not consider it fatal, as it is (in my experience) the most
>> common response code from malfunctioning OCSP responders. In 2005/2006
> OK, so if an OCSP responder is malfunctioning and sending out  
> "unauthorized" responses, how is that different than a particular CA  
> that runs an OCSP responder that malfunctions and sends out signed  
> "Unknown" responses?  Either way, it is a CA with broken  
> infrastructure.  This is NOT the hard-fail problem; this is a problem of  
> a CA that is operating incorrectly.  It is not up to the client to work  
> around this kind of brokenness.

I expect that the overload of such a case would soon be noticed, as well  
as how clients react to it.

In any case, our users expect to be able to get to the sites they want to.  
We occasionally see bug reports and complaints from people that are  
prevented from going to sites by the antifraud system, or for revoked  
certificates. Sometimes such problems are caused by the website such as  
<http://my.opera.com/yngve/blog/show.dml/508407> and  
<http://my.opera.com/yngve/blog/show.dml/4391125>. Even when our action is  
non-fatal we get feedback, such as in this case  

Therefore, particularly when the event is happening frequently, as it was  
concerning the malfunctioning OCSP responders (which affected major  
sites), then the browser vendors are going to work around it, possibly  
lowering security in the bargain (although, in Opera's case we do indicate  
that there is a problem).

However, my intention is to get in place a system that will cause any  
certificate that was issued in the manner reported for the DigiNotar  
certificates (no trace in any database utilized for revocation) to be  
refused immediately, rather than waiting for the CA to notice that  
something odd is going on. This might not help if the attacker works  
within the system so that the revocation system sees it, by that  
dramatically increases the risk of discovery.

>> And please note, my suggestion is for non-issued certificates. The most
>> likely scenario for observing such requests are a fraudulently issued
>> certificate
> RFC 5019 (*emphasis_added_by_me*):
>    For example, OCSP responders that do not have access to authoritative
>    records for a requested certificate, *such_as_those_that_generate_and
>    distribute_OCSP_responses_in_advance_and_thus_do_not_have_the_ability
>    to_properly_respond_with_a_signed_"successful"_yet_"unknown"
>    response*, will respond with an OCSPResponseStatus of "unauthorized".
>    Also, in order to ensure the database of revocation information does
>    not grow unbounded over time, the responder MAY remove the status
>    records of expired certificates.  Requests from clients for
>    certificates whose record has been removed will result in an
>    OCSPResponseStatus of "unauthorized".
> Many, many people leave expired certs up on their web sites.  For

Expired certificates are not the target of my proposal, it specifically  
says that it applies to "a request for status of a certificate that has  
not yet been issued". Expired certificate have been issued once upon a  
time so they are not affected by this.

> reasons that are not clear to me, client software still attempts to do  
> OCSP validation of expired certificates.  This may be partly due to  
> clock skew on the clients, but we get OCSP requests for certs that

Probably more like: always do it; less complex logic, less chance of it  
being turned off accidentally.

> expired a long, long time ago.  So if the OCSP data producers stop  
> producing new responses for expired certificates (for the reason  
> mentioned in 5019: to keep the data set from growing unbounded), the  
> public-facing servers will see all of those requests for expired certs  
> as "unknown" and have to forward them back to some service with  
> real-time signing capability.

The fallback signer might have extra information available to resolve  
this, even if the responses are not in the pre-generated set of responses.

> And despite any of the above, your proposal requires making signing keys  
> available to public-facing OCSP servers.  Either directly on those

As I understand it, there are a number of CAs that do this already.

> servers themselves, or by allowing public-facing OCSP servers to  
> initiate a connection back to some system that has signing keys  
> available.  Again:  given our efforts to demand better network security  
> from CAs, I see this as a big step backwards.
> --
> Ryan Koski
> Systems Engineer
> GoDaddy.com, LLC
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> http://cabforum.org/mailman/listinfo/public

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