Subject: [pkix] OCSP stapling extension?

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Apr 2011 08:44:46 +0200

Dear List,

This is not a suggestion but an open question.

OCSP stapling is a nice idea but it is not universally applicable
since PKIs run by banks typically do not allow arbitrary access
to OCSP responders.  This complicates the design of client SW.

Would a certificate extension that in some way signals the "openness"
of the OCSP responder be of any utility or is the "right" way to try
to get a response and possibly fail?  Unless the SW also "learns" the
behavior of different PKIs, the latter IMO could lead to a somewhat
erratic operation.

I'm considering adding OCSP stapling to WebAUTH and WASP that
are "companion" specifications to SKS/KeyGen2.

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 25 Apr 2011 08:08:39 -0400

> to OCSP responders.  This complicates the design of client SW.

Functionally I think it's simpler (in a protocol with stapling defined) to look for the stapled response first, before chasing id-ad-ocsp URIs.  Once I'm at the point of chasing AIA, either I can get a DNS response for the host named or not.  

While yes it's simpler to "always chase AIA" but really, is it that big of a deal?

> Would a certificate extension that in some way signals the "openness"

So you'd take the complexity *out* of the specific client supporting your protocol and put it in *every PKI library* instead?  How does this make anyone's life easier?

-- T