Re: DISCUSSION: Nonce-specific error code for OCSP

[David Engberg <dave@xxxxxxxxxxxxxx>]

Sorry, didn't mean to start a rehash of the original nonce argument.
My original point was in response to precise protocol assertion from 
Mike's last email:

    Further, the requestor which sent a nonce and received a
    non-nonced response can today infer "responder does not support
    nonces."

I was basically trying to say that, at a protocol level, this statement 
is false.

If a client sends a request to a responder that includes a nonce, and 
that client receives either:
   (a) an unsigned OCSPResponseStatus
    - or -
   (b) a signed response with no nonce and no special extensions
then that client has no way to tell whether that OCSP responder is 
intentionally configured to ignore nonces, or whether an attacker on the 
network is providing (a) bogus or (b) replayed information.

If the signed body of the response contains an extension that says "this 
OCSP infrastructure never provides nonces for any requests", then the 
client can securely determine that this declaration came from a trusted 
entity (the OCSP signer) and not an intermediate attacker.



> The requirement is to bind a request to its associated response
> and thus enable relying parties to mitigate replay risks.  I
> remain curious to an understanding of how unilateral server-side
> response extensions achieve this effect.

I disagree.  The real requirement is that the certificate status 
response be as provably up-to-date as possible for a given request.  All 
this "binding" stuff is just a particular mechanism which MAY achieve 
that requirement.

A nonce can be used to strongly bind a response to a specific request. 
This proves that the response is "fresh" from a responder.  This MAY 
give indication that the underlying status information is up-to-date. 
If, however, the response was provided by a responder which is using a 
CRL that is 11 hours old, the nonce is only providing me with the 
illusion of immediacy.  If a cert was revoked 6 hours ago, that 
responder will provide "fresh" responses validating that cert until the 
next CRL is released and processed.

A response based on a start time (thisUpdate) and end time (nextUpdate) 
more accurately reflects the real underlying status information in any 
system with responders using periodic CRLs.



> In the instance of explicit delegation from a certification
> authority, there then exists a business entity which places
> itself in a position of risk against damage claims.  Are you
> suggesting that an OCSP responder's unilateral inclusion of a
> technical artifact is an assertion of willingness to absorb such
> risks?

Oh, I don't think that lawyers would be quite as clear on the liability 
distinction between ACME Novelty's CA and its Responders.  In both 
cases, ACME has IT personnel running servers with HSMs that provide 
digitally signed information attesting to the identity and status of 
ACME employees.  I don't think you'd avoid any lawsuits by asserting 
that a revoked certificate was "validated" using a compromised ACME OCSP 
Responder rather than a bad CRL from a compromised ACME CA.

But I certainly wouldn't advocate any sort of unilateral inclusion of 
technical artifacts ... that's why we're discussing this as part of the 
standards process.

Thanks,
Dave