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

[Nikos Mavrogiannopoulos]

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.

On the server side, the APIs we provide at the moment to set responses are:
int
gnutls_certificate_set_ocsp_status_request_function2
(gnutls_certificate_credentials_t res, unsigned idx,
gnutls_status_request_ocsp_func ocsp_func, void *ptr);
int
gnutls_certificate_set_ocsp_status_request_file
(gnutls_certificate_credentials_t res, const char *response_file,
 unsigned idx);

That is, a function to set a callback, and another to set a response
from file. The index (idx) in both cases is the index of the
certificate chain for servers with multiple end-certificates (e.g., an
rsa and an ecdsa one).

Now, the question is how can we handle the multiple responses per
chain? The functions above can be used to obtain a single item per
session. I think that the current interfaces are beyond saving. So I'm
considering the following:

 1. Provide another certificate retrieval callback, replacing
gnutls_certificate_retrieve_function2() with
gnutls_certificate_retrieve_function3(), which will retrieve the
certificate and key in addition to certificate status request.

 2. Enhance gnutls_certificate_set_ocsp_status_request_file to read
the OCSP response and associate with the appropriate certificate in
the chain. That would allow applications which first loaded the
certificates, to call the set_status_request_file() multiple times, to
set the files which correspond to certificates in the chain.

What do you think? Would that leave any applications using gnutls
unable to take advantage of OCSP status responses? Any other
suggestions?

regards,
Nikos