On 4/13/13 6:51 PM, "Piyush Jain" <piyush@xxxxxxxxxxxx> wrote: > >> An extension may differentiate which serial number that results in a >> "revoked" response, that is actually issued and revoked, or if there is >any >> other particular reason for responding "revoked". >> In my universe a syntactically valid serial number can only be good, >revoked >> or non-issued. But expressing this in general terms anyway. > >[Piyush] From an RP's perspective finding status of serial numbers serves >no purpose unless they can associate that serial number with a >certificate. Absolutely, that is the client's perspective of this. >When an OCSP client extracts the serial number from a certificate and >sends >it the responder to determine the status, it is acting under a very >important assumption - the CA has issued that certificate and that it has >issued only one certificate with that serial. Absolutely >If you say that this assumption is invalid, your trichotomy of serial >status >is not mutually exclusive any more. Same serial can now be associated >with a >good, revoked and non-issued status. I didn't say that. I said it can "only be good, revoked or non-issued" Notice the difference? My sentence contains the word "or", yours the word "and". These are the three possible states of a serial number. It must always be in ONE of these states. >And also the client cannot be sure if >the CA delegated responder's certificate is good or non-issued. This >renders >OCSP completely useless. I did not talk about responder certificates. > >> >> So with the help of extensions, a responder can provide both white and >black >> list data. > >[Piyush] May be you are right. But I doubt that you want a discussion on >feasibility/security implications of this, otherwise it would've been a >stated goal of 2560bis and would have been captured in the abstract. If new extensions are defined, then the RFC defining these extensions will discuss relevant security implications related to those extensions. >I tried to think ahead but I cannot figure out a way to communicate the >white listed status of a CA delegated responder to the client without >avoiding circular logic. I can. The "good" response provides by default a minimum level of positive confirmation. But it is also make clear that an extensions allows "good" to say more, as long as it fits within that default statement of "good". A white list falls within that basic statement. That is, the serial numbers that will return "good" in a "white-list" scenario would also return "good" if the responder provided default OCSP status information. White listing will simply reduce the number of "good" status to occasions where it represent a known existing certificate. > >I completely fail to see why revoked for non-issued is a pre-requisite for >future extensions that can be used to provide white-list data (if it is >even >possible under CA delegated responder trust model). I'll try again. It is only possible to reduce the "good" status responses to white listed certificates if another suitable status can be return for any other requested serial number. That is, the combined set of revoked and non-issued serial numbers that does not belong in the while list. Responding "unknown" may not be desirable, as it is likely to cause the client to try another source. With the update of RFC2560bis it is now being made clear (in the definition of "revoked"), that it is conformant to respond "revoked" to both revoked and "non-issued" certificates, while before, that could be questioned as a stretch of semantics. So yes indeed, the updates makes it easy to take the next step into a white-list OCSP responder by adding a suitable extension. Of course, only those understanding the new extension will know that it is a "white list" response. /Stefan