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

[Thomas Klute]

Am 29.11.2017 um 13:56 schrieb Nikos Mavrogiannopoulos:
> On Tue, Nov 28, 2017 at 7:53 AM, Thomas Klute
> <thomas2.klute at uni-dortmund.de> wrote:
>> Am 27.11.2017 um 14:35 schrieb Nikos Mavrogiannopoulos:
>>>> 2) The certificate is passed to the callback as a gnutls_pcert_st. I'd
>>>> need to call gnutls_pcert_export_x509 during each run of the callback to
>>>> get a gnutls_x509_crt_t and access things like fingerprint (used for the
>>>> cache key) or OCSP responder URL. I'm not sure if that might hurt
>>>> performance.
>>>
>>> If you are storing the certificate as a gnutls_pcert_st internally,
>>> I'd also store the OCSP response in the same structure. E.g.
>>> struct int_store_st {
>>>   gnutls_pcert_st *certs[];
>>>   gnutls_datum_t ocsp_responses[];
>>> }
>>>
>>> where each response corresponds to each cert. When the callback from
>>> gnutls_certificate_set_ocsp_status_request_function3 is set, you'll
>>> get a gnutls_cert_info_st which has an index indicating the positioni
>>> n the chain the OCSP is asked for. With such a setup no additional
>>> parsing will be required. If I misread what you were describing,
>>> please let me know.
>>
>> 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.

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?

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.

Best regards,
Thomas