On Apr 11, 2013, at 10:37 PM, Stefan Santesson <stefan(_at_)aaa-sec(_dot_)com>
wrote:
To put it simply. Given how OCSP is designed, the only way to allow "good"
to represent a white-list, is if "revoked" can be returned for everything
else.
I realize it's unfair of me to take this quote out of context. Apologies, but
I want to focus on it.
You've just said that there are only two valid responses from an OCSP server
which has access to a white list. In other words such a server inherently
cannot provide any information about the actual revocation status of a cert,
and its responses cannot distinguish between a lost/forged/whatever cert and a
known-bad (actually revoked) cert.
The actual information which an OCSP responder might (should?) have would
include both a white list and a black list. An RP using OCSP to determine "the
current status of a digital certificate without requiring CRLs" (as it says in
the abstract) would hope to receive the available information about a subject
cert. In other words, after a successful query, it would hope to know if the
subject cert was known-good, known-bad, or neither.
By combining the known-bad and neither responses, the RP must now use CRLs in
order to distinguish those two cases.
This situation would appear to contradict the first sentence in the abstract of
the document. Doesn't a change which requires a change in the abstract exceed
the authorized scope of this revision to 2560? If it doesn't then I think the
abstract needs to be updated.
I don't understand why we're trying so hard to avoid providing both the
white-list and the black-list information at the same time in OCSP responses.
(Nit: Since the Introduction repeats the Abstract, the reference to 5912 added
to the Abstract should also be added to the Introduction.)
------------------------------------------------------
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