On 2009-06-22 12:05 PDT, Nagendra Modadugu wrote: > I am currently implementing the "Certificate Status Request" extension > (RFC4366) for NSS. The primary use of this implementation will be > OCSP verification of certificates presented by SSL websites. > > For the general Internet context, I am unable to find a case where a > client should specify a non-empty responder_id_list. But in any case, > say that the client does specify a responderID (to a general SSL > webserver), what is the server supposed to do? The responderID is > supposed to be either 1) the hash of the responder public key, or 2) a > name (convention appears to be SubjectName of the responder). > > Unless convention for a responderID "name" is a AIA URL (and clients > use a URL over a hash), the webserver will have to be pre-configured > to determine appropriate end-points for each possible responder. What > is the recommended way to specify responderIDs? > > Also, for the next revision of this RFC, it would useful to allow > servers to return multiple OCSP responses, as EV certificates tend to > be chained. > > nagendra
Hi Nagendra, I'm glad to see you here in this list. My understanding of this is quite different from yours, and is based on my understanding of the underlying OCSP protocol, which (as you know) is in RFC 2560. As you know, an OCSP client (typically a relying party) generally has only two choices (or perhaps two classes of choices) for where to send its OCSP request. They are: 1) to one of the AIA OCSP URLs found in the certificate itself. The signatures on responses from those URLs will (must) be verifiable using the public key from either (a) the cert for the issuer of the cert whose revocation is in question, or (b) another cert, also issued by the issuer of the cert whose revocation is in question, that bears a special Extended Key Usage extension designating it as a delegated OCSP responder for that issuer. OR 2) to a "locally configured" OCSP responder that is explicitly trusted by the relying party, and which (typically) acts as a sort of proxy OCSP responder for all that relying party's requests. In this case, the OCSP request will typically contain a ServiceLocator extension which bears the issuer name and the AIA OCSP extension URIs from the cert whose revocation is in question. The ServiceLocator provides a major clue to the locally configured proxy OCSP responder about where to get the desired info. Now, in the case of the TLS "Certificate Status Request" hello extension, the client does not yet possess the server's cert at the time that it sends the extension, so it cannot provide any info from the server cert itself, such as the cert's issuer name or the AIA OCSP URI(s). So, for the content of the responderID, its only choices are (a) send the list of responderIDs for its locally configured proxy OCSP responder(s), or (b) send an empty responder ID, indicating that the server should get its OCSP response from the responders represented by the AIA OCSP URIs in the server's cert. I know that the description of a zero-length responder_id_list doesn't seem to suggest that it means to get the response from the AIA OCSP URIs, but really, what else can the TLS server do? Perhaps RFC 4266 should be clarified about that. So, IMO, for the "general Internet context", I expect that the responder_id_list will be zero length. I expect it will only be non-zero length in the case where the TLS client (relying party) would use a locally configured proxy OCSP responder, and in that case, the responderID of that responder will be sent to the TLS server. I expect that will only be used in cases where the server is in the same corporate "intranet" as the client. Feel free to test this theory on the ietf-tls list. If you would like, I can send a copy of this reply to that list, and let people shoot at it there. :) /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
