Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

From: Rob Stradling <[email-masked]>
Date: Tue, 1 Nov 2011 11:41:10 +0000

On Monday 31 Oct 2011 17:35:48 Martin Rex wrote:
<snip>
> ...and the client can indicate whether it still has cached OCSP-responses
> available and for which server certificate chain, which would obviate the
> sending of the stapled OCSP responses with each and every handshake (such as
> abbreviated TLS handshakes, aka session resumes) and still work
> successfully/transparently for credentials updates on the server.

Do you think the best way to accomplish this would be to extend draft-ietf-
tls-cached-info ?

> -Martin

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Nov 2011 03:24:06 +0100 (MET)

> Do you think the best way to accomplish this would be to extend draft-ietf-

While in theory this could be done, I would not go down that road.

tls-cached-info is primarily to deal with data that is part of the
regular handshake.  While it is conceivable to apply it to TLS extension
payload as well, I would rather try to newly define a TLS extension
exactly with the desired properties (and accomodate serialized
DNSSEC records for DANE validation in that extension as an alternative).

I'm actually more appalled by the idea of the currently existing
OCSP-responses through TLS extension schemes/proposals that it
is built on the assumption that the server will perform an OCSP
request to an OCSP server specified by the clients and include
attributes supplied by the client in the request.  This might
require the server to perform multiple OCSP requests during
the handshake and result in several dozens of distinct
sets of OCSP responses per server certificate up to unique
sets of OCSP responses per each requests -- that's awfully
complex and extremely brittle.

If anything, I would be interested in a *SIMPLE* TLS extension
which results in _one_ single set of OCSP responses per server
certificate that the server can cache for several hours and
refresh truely asynchronous.  And that is something where
monitoring the OCSP retrieval on the server side would
make sense without having to define filters on which kind
of client-specified OCSP requests ought to be ignored for sanity.

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Nov 2011 10:44:40 +0000

On Thursday 03 Nov 2011 02:24:06 Martin Rex wrote:
<snip>
> complex and extremely brittle.

Agreed.  However, it looks like the TLS Server is free to ignore the 
"attributes supplied by the client" and staple a cached OCSP Response.

http://tools.ietf.org/html/rfc6066#section-8 says...
"Servers that receive a client hello containing the "status_request" extension 
MAY return a suitable certificate status response to the client along with 
their certificate.  If OCSP is requested, they (Servers) SHOULD use the 
information contained in the extension when selecting an OCSP responder and 
SHOULD include request_extensions in the OCSP request".

(Note: 1 MAY and 2 SHOULDs, rather than 3 MUST/REQUIRED/SHALLs)

<snip>

Rob Stradling