[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