On Apr 10, 2013, at 3:02 AM, Stefan Santesson <stefan(_at_)aaa-sec(_dot_)com>
wrote:
Nothing has changed in this regard.
The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that extensions may be used to expand this
default information about the status.
This is how it always have been, and still is in RFC 256bis.
So a non-issued cert may be "good".
The revoked response simply means that the certificate is revoked.
Combined with the new extension, it MAY also be used for non-issued certs.
So a non-issued cert may be "revoked".
It's really as simple as that.
I would have thought that what was simple was to say a non-issued cert was
"unknown", since it's neither known-good, nor known-revoked. Is there any
collection of extensions which will allow an RP to know, for sure, what value
will be returned for a never-issued cert?
It is only the discussion on this list that is confusing and that has
managed turn something really simple into a complicated debate.
What *I* find confusing is the apparent degree of belief that it is possible to
improve 2560 and simultaneously to maintain backward compatibility. That
should only be possible if there are some previously-ignored extensions which
alter the semantics of the information --- effectively creating a version 2
protocol.
I don't find the claim that nothing has changed helpful.
What I would find helpful, and what I think some people really would like, is
for OCSP to be able to provide white-list information in addition to the
previous black-list information. When I read through 2560bis, I could not tell
if there was an extension which would allow an RP to tell if "good" actually
meant a cert was on the white list (and to know the responder has the white
list), or merely not on the black list. (Yes, I'm repeating myself. Am I
making more sense, or just wasting everyone's time?)
/Stefan
On 4/8/13 9:35 PM, "Henry B. Hotz" <hotz(_at_)jpl(_dot_)nasa(_dot_)gov> wrote:
Actually, what I get from this and all the other discussions is that it's
unclear if the updated OCSP satisfies the "suitability for the intended
purpose" test. Or at least it fails the KISS principle w.r.t. that.
Rephrasing: an OCSP client should be able to tell from an OCSP response
if: a) the subject cert is on the CAs white list, b) the subject cert is
on the CAs black list, c) the subject cert is not on either list, or
finally d) the OCSP server is obsolete, and doesn't support making those
distinctions. It's not trivial to see how to parse 2560bis responses
w.r.t. those cases, therefore it's highly likely that computational
complexity will prevent us from doing so. Even if that's not actually
the case, then implementor misunderstandings will prevent us from doing
so in practice.
Therefore I vote against moving this draft forward. I just don't see the
point.
If someone were to write an informational RFC which explained how to
determine which of the 4 cases an OCSP response fell into, AND if said
RFC also convinced me that the decision process was easy to understand,
THEN I would change my vote. Obviously an appendix in 2560bis would
serve just as well.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(_dot_)B(_dot_)Hotz(_at_)jpl(_dot_)nasa(_dot_)gov, or
hbhotz(_at_)oxy(_dot_)edu