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 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 majord...@metzdowd.com