[gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders tj at castaglia.org
Tue Jun 27 17:19:10 CEST 2017

> > To me, this means that if the session is resumed, then the extensions
> > _in the ClientHello_ (including the status_request extension) are to be
> > ignored.  And if that client-sent extension is ignored, then this text,
> > from Section 8, becomes relevant, I think:
> > 
> >   "Note in addition that a server MUST NOT send the "CertificateStatus"
> >    message unless it received a "status_request" extension in the client
> >    hello message and sent a "status_request" extension in the server
> >    hello message.
> > 
> > If the "status_request" extension in the ClientHello is to be ignored
> > for resumed sessions, and we should send a ServerHello with none of the
> > extensions, then we cannot send a stapled OCSP response.
> > 
> If things are this way then (and I understand this might not be a
> GnuTLS-specific issue, but just popped out from my head), what happens if
> the certificate has been revoked in the time span between the initial session
> establishment and the later resumption?
> The client can check that by sending a "normal" OCSP status request, but
> would lose the benefit of stapled OCSP?

Or, if the client was wary of such an occurrence, it would simply not
offer the session ID (or session ticket) in its ClientHello, thus
preventing the possibly of a resumed session and forcing a full
handshake, with its stapled OCSP response.  Another refinement would be
for that client, if it sees a session resumed "too many times"
(determined by that client implementation/configuration), to then
connect to the server without session ID or ticket, requesting the
stapled OCSP response -- this way the client would get most of the
benefit of session resumption, and the benefit of OCSP stapling, with a
way to "double check" that certificate validation in the face of resumed

Since the session resumption timing is ultimately left up to the server,
and that timing is not conveyed back to the client, it is something of a
question of trust.  Does the client trust the server to implement an
"acceptable" (for whatever that means) policy of session caching?  If
so, then it should trust the resumed session without its stapled OCSP
response.  If not, then perhaps that client should not be connecting to
the server at all.


More information about the Gnutls-devel mailing list