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

[Ander Juaristi]

On 27/06/17 09:05, 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.
> 

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?

> Cheers,
> TJ
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>