A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams at 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
this.

OCSP Responses allow the Responder to assert:

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

   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;
   REQUIRED).

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
Responder?

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

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com