On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
> Nicolas Williams <nicolas.willi...@oracle.com> writes:
> >Sorry, but this is wrong.  The OCSP protocol itself really is an online
> >certificate status protocol.  
> It's not an online certificate status protocol because it can provide neither
> a yes or a no response to a query about the validity of a certificate.

You should be more specific.  I'm looking at RFC2560 and I don't see

OCSP Responses allow the Responder to assert:

 - A time at which the given cert was known to be valid (thisUpdate;

   Relying parties are free to impose a "freshness" requirement (e.g.,
   thisUpdate must be no more than 5 minutes in the past).

   Perhaps you're concerned that protocols that allow for carrying OCSP
   Responses don't provide a way for peers to indicate what their
   freshness requirements are?

 - A time after which the given OCSP Response is not to be considered
   valid (nextUpdate, which is OPTIONAL).

 - The certificate's status (certStatus, one of good, revoked, unknown;

How is responding "certStatus=good, thisUpdate=<now - a few minutes>"
not a "yes response to a query about the validity of a certificate"?

What am I missing?

> (For an online status protocol I want to be able to submit a cert and get back
> a straight valid/not valid response, exactly as I can for credit cards with
> their authorised/declined response.  Banks were doing this twenty years ago
> with creaky mainframes over X.25 and (quite probably) wet bits of string, but
> we still can't do this today with multicore CPUs and gigabit links if we're
> using OCSP).

OCSP gives you that.  Seriously.  In fact, an OCSP Responder either must
not respond or it must give you at least {certStatus, thisUpdate}
information about a cert.  Yes, certStatus can be "unknown", but a
Responder that regularly asserts certStatus=unknown would be a rather
useless responder.

> >Responder implementations may well be based on checking CRLs, but they aren't
> >required to be.
> They may be, or they may not be, but you as a relying party have no way of 
> telling.

And why would a relying party need to know internal details of the OCSP

> In any event though since OCSP can't say yes or no, it doesn't matter whether 
> the response is coming from a live database or a month-old CRL, since it's 
> still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
> manufactured-cert attack.

Manufactured cert attack?  If you can mint certs without having the CA's
private key then who cares about OCSP.  If you can do it only as a
result of hash collisions, well, switch hashes.  Let's not confuse hash
collision issues with whether OCSP does what it's advertised to do.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to