[145481] in cryptography@c2.net mail archive
Re: A mighty fortress is our PKI, Part II
daemon@ATHENA.MIT.EDU (Paul Tiemann)
Wed Jul 28 18:55:54 2010
From: Paul Tiemann <paul.tiemann.usenet@gmail.com>
In-Reply-To: <E1Oe9Q8-0000Qw-Kw@wintermute02.cs.auckland.ac.nz>
Date: Wed, 28 Jul 2010 14:30:32 -0600
Cc: Nicolas Williams <Nicolas.Williams@oracle.com>,
Ben Laurie <ben@links.org>,
cryptography@metzdowd.com,
lynn@garlic.com,
"Perry E. Metzger" <perry@piermont.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
On Jul 28, 2010, at 10:23 AM, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> writes:
>=20
>> Sorry, but this is wrong. The OCSP protocol itself really is an =
online
>> certificate status protocol. =20
>=20
> 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.
>=20
> (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. =20
It might not be hard to determine whose OCSP responders are CRL based =
and whose are database backed instead. =20
> 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.
>=20
> They may be, or they may not be, but you as a relying party have no =
way of=20
> telling. =20
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. =20
> In any event though since OCSP can't say yes or no, it doesn't matter =
whether=20
> the response is coming from a live database or a month-old CRL, since =
it's=20
> still a fully CRL-bug-compatible blacklist I can trivially avoid it =
with a=20
> 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? =20
Paul Tiemann
(DigiCert)
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
