On Thu, Jun 25, 2009 at 3:37 PM, Nelson B Bolyard <nel...@bolyard.me> wrote:
> 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. > Sorry, I had poorly worded my question. I agree with your assessment below. > > 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. > I'm asking for implementation requirements :-) Client behavior is straightforward, here are the outstanding questions about server behavior: Should it be possible to statically configure an NSS server with responder_id -> URI map? Also, should it be possible for an NSS server to fetch an OCSP response in real-time? (as opposed to OCSP responses being loaded off the server's file-system ... how the responses are retrieved/refreshed is a separate matter). RFC4366 allows an SSL server to disregard the responder_id_list entirely and respond with a CertificateStatus message issued by a responder of its choosing. What is the recommended behavior in the case where a client specifies a non-empty responder_id_list and the server does not recognize any of the responder_id's? (the server could ignore the SSL extension altogether, or send a default "CertificateStatus" message). nagendra > 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 >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
