On Jul 28, 2010, at 10:23 AM, 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. > > (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.
It might not be hard to determine whose OCSP responders are CRL based and whose are database backed instead. > 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). Yes we can, and some actually do. >> 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. Even the most savvy of relying parties probably has no way of caring. They want to know when something is positively revoked, and having a definitive Yes is a nice distinction, but having a definitive Not-Revoked appears to be good enough for most. > 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. You're right: a manufactured-cert attack is going to really hurt that kind of an OCSP responder. Is a manufactured-cert a trivial thing to create? Paul Tiemann (DigiCert) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com