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

[Stefan Bühler]

Hi,

On 06/27/2017 09:05 AM, TJ Saunders wrote:
> 
>> I'm not sure your conclusion to not staple the OCSP response is quite
>> correct, note RFC 6606 saying "In this case, the
>> functionality of these extensions negotiated during the original
>> session initiation is applied to the resumed session."
>>
>> The way I understand it, the server, even though replying with empty
>> extensions on server hello, must otherwise behave as if the extensions
>> were initially negotiated and thus the CertficateStatus handshake packet
>> should be sent.
> 
> 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.

cheers,
Stefan