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

[Nikos Mavrogiannopoulos]

On Mon, Dec 4, 2017 at 10:34 PM, Thomas Klute
<thomas2.klute at uni-dortmund.de> wrote:
>>> I was referring to how I might use the new API, not the current
>>> implementation. The current mod_gnutls implementation keeps certificate
>>> chains as both gnutls_pcert_st and gnutls_x509_crt_t arrays, and the
>>> OCSP responses in a key/value cache.
>>
>> So is the existing information sufficient to figure the key, or is
>> there something else we should add in gnutls_cert_info_st?
>
> I think it's sufficient for any static chains case, and for the retrieve
> callback case as long as the right certificate chain is obvious (one per
> virtual host). Otherwise I'd have to implement some way to find the
> right chain based on the gnutls_pcert_st, but that might be a non-issue
> as far as mod_gnutls is concerned (see below).
>
> However, I think a gnutls_x509_crt_t* instead of (or in addition to) the
> gnutls_pcert_st* would make it more convenient to access needed
> certificate information (e.g. using
> gnutls_x509_crt_get_authority_info_access). Of course that only makes
> sense if that certificate structure already exists internally, not if
> it'd have to be created on each call.
>
>>> Another approach could be to add a certificate retrieve callback type
>>> that can return OCSP responses along with selected certificates, but
>>> that's also fairly complex.
>>
>> That could also be. I think the main reason a separate callback was
>> used for the multiple OCSP responses is because there was already such
>> a callback in place. Would that approach be simpler for mod_gnutls?
>
> I think that would be easier to implement, yes. The retrieve callback
> must find the right certificate chain anyway, and at that point it
> already has all the information needed to get the matching OCSP
> response(s) too.

I've made a 3rd attempt at (still in progress):
https://gitlab.com/gnutls/gnutls/merge_requests/566

which introduces an new callback for setting certificate + OCSP responses.


> On the other hand, after looking at the mod_gnutls code again I think I
> should be able to switch from a retrieve callback to static certificate
> chains as soon as I get around to removing all code for PGP
> authentication. That would also make it much easier to add support for
> multiple X.509 certificate chains per virtual host (e.g. to support both
> RSA and ECDSA authentication). Side question about that: Is it safe to
> assume that when adding multiple certificate chains to one
> gnutls_certificate_credentials_t their indices will be array indices in
> the order they are added?

Don't do that. You can get the indexes from the certificate set
functions. You only need to set the flag GNUTLS_CERTIFICATE_API_V2
with gnutls_certificate_set_flags.

> By the way, another thing that would be a simplification and performance
> optimization for mod_gnutls: Let applications configure GnuTLS to *not*
> call gnutls_free() on the returned buffer, e.g. with a flag for
> gnutls_certificate_set_ocsp_status_request_function3(). The APR cache
> retrieve functions allocate memory for OCSP responses from a memory pool
> bound to the connection lifetime, so having to return memory allocated
> with gnutls_malloc() requires an extra memory copy.

Good idea. The new callback set with
gnutls_certificate_set_retrieve_function3 allows that. I need to test
it more thoroughly though.

regards,
Nikos