[gnutls-devel] support of stapled OCSP responses under TLS1.3

[Nikos Mavrogiannopoulos]

On Tue, Nov 21, 2017 at 11:03 AM, Stefan Bühler <stbuehler at lighttpd.net> wrote:
> Hi,
>
> On 11/20/2017 08:56 AM, Nikos Mavrogiannopoulos wrote:
>> On Fri, Oct 13, 2017 at 1:50 PM, Nikos Mavrogiannopoulos
>> <n.mavrogiannopoulos at gmail.com> wrote:
>>> Hi,
>>>  I'm going through the support of stapled OCSP responses under TLS1.3.
>>> The major change in TLS1.3 is that there can be an OCSP response for
>>> each certificate sent, rather than one response for the
>>> end-certificate, and such responses can be provided also for the
>>> client certificate.
>>> Supporting multiple responses when verifying the certificates seems
>>> straightforward as we were doing that transparently without the
>>> application intervening.
>> [...]
>>
>> Hi,
>>  The merge request introducing multiple OCSP staples under TLS1.3 is at:
>> https://gitlab.com/gnutls/gnutls/merge_requests/548
>>
>> It tries hard not to require new APIs by enhancing
>> gnutls_certificate_set_ocsp_status_request_file() to parse the
>> response file and associate it with a certificate. On the other hand,
>> a new callback could not be avoided to retrieve more than one
>> responses, hence
>> gnutls_certificate_set_ocsp_status_request_function3() is added, as
>> well as gnutls_ocsp_status_request_get2() for application to read the
>> responses.
>
> As far as I can see gnutls_certificate_set_ocsp_status_request_function3
> provides the necessary interface.
>
>> I'd appreciate a review on that new functionality if you are already
>> familiar with the previous OCSP handling code, or intend to use it.
>>
>> After a discussion with Hubert Kario, I've also opened [0] which is
>> about automating the retrieval of OCSP responses and association with
>> server credentials, to reduce complexity from servers. It's currently
>> a bit low priority in the tls1.3 plan [1], and up for grabs, but it
>> would make an application server's code much simpler.
>
> A first step to make usage simpler would be to add a function similar to
> gnutls_certificate_set_ocsp_status_request_file which accepts a
> gnutls_datum_t instead of a filename.

Thank you Stefan. If I remember well, my original intention for not
bringing that function was that I assumed that OCSP responses are
something volatile that will need to be updated now and then. As the
credentials structure is supposed to be accessed concurrently, do you
imply here having a set data buffer function which protects against
concurrent access, or an "unsafe" set function which is expected to be
used once, while later the credentials structure is recycled? (i.e.,
the server app, creates a new credentials structure for new sessions).

> And even simpler would be auto-loading these responses from "OCSP
> RESPONSE" pem blocks in certificate files (or separate "ocsp" files).
> (I made up the term "OCSP RESPONSE"; afaik there is no standard name for
> this).

Is the use of such a file format something that is being used? As the
OCSP response lifetime is much shorter than certificate lifecycle, I'd
expect that combo to cause an inconvenience.

regards,
Nikos