> 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. 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. 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. And also the client cannot be sure if the CA delegated responder's certificate is good or non-issued. This renders OCSP completely useless. > > 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. 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 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).
