Re: [TLS] Status of X.509v3 TLS Feature Extension?

[Viktor Dukhovni <[e-mail]>]

On Mon, Apr 28, 2014 at 12:04:19PM -0400, Salz, Rich wrote:

> > What's the point if it does not fail-closed?  The client insists
> > that the server provide an OCSP response, but then does not validate
> > it (some notion of freshness is surely part of validation, but no
> > freshness algorithm is indicated).
> 
> A client can always ask for an OCSP response, but it is up to
> that client to decide whether or not the response is satisfactory.
> If there's a hurricane bearing down on me, I might be willing to
> accept a stale status response from my local Red Cross chapter,
> for example.

That's nice for an informed, security-literate user operating a
browser, but completely impractical for, say, an SMTP server.  A
reasonably interoperable algorithm is required for deciding which
responses are required and how fresh they need to be before failing
closed.

> > Does the server have to provide OCSP responses for every
> > intermediate CA in the chain?  Or just for the leaf certificate?
> > Or only for the leaf certificate and those intermediate CAs whose
> > certificates happen to include the proposed TLS feature extension?
> 
> Well RFC 6066 says "only one OCSP response may be sent" and while
> RFC 2560 allows multiple answers, it says that they are a "response
> for each of the certificates in the request."  Since the server's
> SSL cert is implied by 6066, and since there is no other way to
> specify additional certs, then the answer to your questions would
> be "just the leaf."

Which leaves the intermediate CAs out of scope...  I plan to continue
to treat CRLs, OCSP and OCSP stapling as variants of the emperor's
new clothes.

-- 
	Viktor.