Re: clarifications on TLS extension "Certificate Status Request"

2009-07-04 Thread Nelson Bolyard
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 wit

Re: clarifications on TLS extension "Certificate Status Request"

2009-07-01 Thread Nagendra Modadugu
On Thu, Jun 25, 2009 at 3:37 PM, Nelson B Bolyard 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 pres

Re: clarifications on TLS extension "Certificate Status Request"

2009-06-25 Thread Nelson B Bolyard
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

Re: clarifications on TLS extension "Certificate Status Request"

2009-06-25 Thread Kyle Hamilton
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

clarifications on TLS extension "Certificate Status Request"

2009-06-25 Thread Nagendra Modadugu
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-em