On 2009-07-01 15:48 PDT, Nagendra Modadugu wrote: > I'm asking for implementation requirements :-) Client behavior is > straightforward, here are the outstanding questions about server behavior:
Ah, OK, thanks for clarifying that. > Should it be possible to statically configure an NSS server with > responder_id -> URI map? I'd say the design should not preclude it, but it is not necessary to implement that in the first version. (anyone disagree?) > Also, should it be possible for an NSS server to fetch an OCSP response > in real-time? I think the question here is really: how should the server expect to find/ obtain the requisite OCSP responses? > (as opposed to OCSP responses being loaded off the server's file-system > ... how the responses are retrieved/refreshed is a separate matter). NSS has built-in code to fetch OCSP responses. I think it is reasonable to expect that that code would be used as needed. NSS also has a cache of OCSP responses. I think it is reasonable to expect that the server would get the OCSP responses it sends to TLS clients from that cache. One way to look at it is that the server does an OCSP query on its own cert when the client asks for stapling, and most of the time, that query is answered from the local cache, but sometimes it is answered with a fresh fetch from the remote OCSP responder. I hope Julien Pierre will join this discussion. He's our revocation expert. > 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. Yes. If a server gets a request that includes only unknown responder IDs, its choices are (obviously) a) ignore the responder IDs and send whatever response you have handy, or b) behave as if you don't support the OCSP stapling extension. > 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). That's a good question. (You always ask such good questions! :) I think we don't yet have enough experience to know for certain, but this is my best guess. I think the best bet is to ignore the whole extension, and behave as if CertificateStatus extension is unsupported. The reason is that I expect that, if a TLS client receives an OCSP response signed by an unknown or unexpected responder, it may declare a fatal error, whereas, if it gets NO response, then I imagine is is more likely to initiate an OCSP inquiry of its own, which (I imagine) is more likely to succeed. I invite discussion of these views. :) > nagendra /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
