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

Tim Kosse tim.kosse at filezilla-project.org
Wed Jun 28 09:11:00 CEST 2017


On 2017-06-28 01:43, TJ Saunders wrote:

> True, but if we are not to include the "status_request" extension in the
> ServerHello (because we are ignoring the "status_request" extension in
> the ClientHello, because it's a resumed session), 

Correct so far.

> then we should not
> send the CertificateStatus message; the client would not know to look
> for a CertificateStatus message unless there is also the
> "status_request" extension in the ServerHello.

The server must use the ServerHello (and thus the ClientHello) of the
original handshake as reference for the extensions:

"In this case, the functionality of these extensions negotiated during
the original session initiation is applied to the resumed session."

During the initial handshake, both ClientHello and ServerHello contained
the status_request extension, so the client is prepared to receive a

There is an example for a different extension in RFC 6066, see the
description of the "truncated_hmac" extension in chapter 7, at the end
it says "The negotiated HMAC truncation size applies for the duration of
the session including session resumptions".

Even though the ServerHello of a resumed session does not include
"truncated_hmac" the HMACs would still be truncated if they originally were.

It's not stated explicitly in the RFC, but it follows for the client
that the contents of the extensions list in the ServerHello of the
resumed handshake are to be ignored, with the client having to use the
extensions negotiated with the original ServerHello.


More information about the Gnutls-devel mailing list