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

TJ Saunders tj at castaglia.org
Tue Jun 27 17:22:04 CEST 2017


> > My understanding is based on this sentence in that section 1.1 portion
> > of RFC 6066:
> > 
> >   "If, on the other hand, the older session is resumed, then the server
> >    MUST ignore the extensions and send a server hello containing none of
> >    the extension types."
> > 
> > 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.
> 
> I think "negotiated extensions" includes the extensions sent in the
> ServerHello in the original session initiation.  If you sent a
> status_request extension back then, the functionality applies to the
> current session, which allows sending a stapled OCSP response.

If we are to ignore the ClientHello extensions for a resumed session,
then we would not send the stapled OCSP response.  The RFC 6066 Section
1.1 text, in my reading, says that the ServerHello emitted by the TLS
server, for a resumed session, MUST NOT contain any of the TLS
extensions -- and this would include the stapled OCSP response.  That
is, the ServerHello of the resumed session must be different; it is not
described as being a "replay" of the original ServerHello.

Cheers,
TJ



More information about the Gnutls-devel mailing list