i.e., you're implementing so-called "OCSP Stapling". Thank you. :)
If the client requires a specific responderID, and the server knows nothing about it (it's not in its listed stores, either as hash or subjectName), I would think that it normally should return a response indicating failure (OCSP status internalError). However, this is a bit of a problem as OCSP (in RFC 2560) requires a signature either by the Trusted Responder (the one that it requested), the CA (which issued the certificate being checked), or a specially-designated-by-CA OCSP responder (marked by the CA which issued the certificate being checked). There is no provision for a server key signing an internalError response itself. So, would it be better for the server, in this case, to not respond to the OCSP stapling request at all? (RFC 4366, section 1, page 4: "For the specific extensions described here, no mandatory server response is required when clients request extended functionality.") The responderID from the client's status_request is either the hash of the responder public key (meaning the server has to be preconfigured with a certificate containing that key in order to know where to look for it), or it's the trustedResponder's subjectName (which does not necessarily include a CN=ocsp.responder.domain.name at the end). Most notably, it doesn't include the rest of the OCSP responder's certificate extensions, which would otherwise likely include the AIA location for that responder's subjectName. Thus, there's no way to guarantee that the subjectName can be resolved in any case. This means that there needs to be a sensible fallback, and the only one allowed by the protocol is for the server to not send a status_request extension in response to the client's status_request. (When the client connects to the server, the server waits for a ClientHello or extendedClientHello, or sends out a HelloRequest. Either way, the client sends ClientHello with the list of responders it wants to receive from. If the server doesn't know the responder, and doesn't know how to reach the responder, the server shouldn't add the 'status_request' extension to its ServerHello. This is the same behavior expected from servers which don't implement the extension, so it shouldn't be a problem.) It's going to make administrative debugging *REALLY HARD*, though, if appropriate logging and documentation measures are not taken. :) Just some thoughts, how I read the specs. -Kyle H On Wed, Jun 24, 2009 at 11:10 AM, Nagendra Modadugu<n...@google.com> 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? > > nagendra > -- > 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
