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

[Ryan Koski]

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.


> 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 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 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.

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