On Apr 11, 2013, at 10:37 PM, Stefan Santesson <stefan@xxxxxxxxxxx> 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.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx