[gnutls-devel] GnuTLS | gnutls_ocsp_resp_verify() requires signer in trust list to have id-kp-OCSPSigning (#1254)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Tue Jul 13 22:53:49 CEST 2021



Airtower created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1254



## Description of problem:

While [debugging issues when using mod_gnutls with Let's Encrypt certificates](https://github.com/airtower-luna/mod_gnutls/pull/4) I noticed that `gnutls_ocsp_resp_verify()` considers OCSP responses invalid if they're signed directly by a CA on the trust list (as Let's Encrypt does) instead of using a delegated signer. This is because `gnutls_ocsp_resp_verify()` requires the id-kp-OCSPSigning key purpose unconditionally. According to [RFC 6960, Section 4.2.2.2](https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2) the id-kp-OCSPSigning key purpose is only needed for a delegated signer, not the CA certificate that issued the certificate being checked, or a signer explicitly declared as trusted.

## Version of gnutls used:

* 3.7.1 (from Ubuntu)
* GnuTLS `master` as of c70941cea73cb38e0d27395e63aafca12dac9a72

## How reproducible:

The attached files contain a trust list (root and intermediate CA, [trust.pem](/uploads/d544e60c477309f3fe3e6647ede1476e/trust.pem)), an OCSP response signed directly by the intermediate CA ([response-ca.der](/uploads/f6d145b7380a647689fda4e42e964f45/response-ca.der)), and an OCSP response signed by a delegated signer signed by the intermediate CA ([response-delegated.der](/uploads/31b7ef44312c611a6a77d97947735f11/response-delegated.der)). Both responses are for a certificate issued by the intermediate CA.

Steps to Reproduce:

 * datefudge --static "2021-07-14 00:00" ocsptool --infile=response-ca.der --verify-response --load-trust=trust.pem
 * datefudge --static "2021-07-14 00:00" ocsptool --infile=response-delegated.der --verify-response --load-trust=trust.pem

## Actual results:

The first verification fails with "Signer cert keyusage error", the second succeeds.

## Expected results:

Both responses should be considered valid.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1254
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210713/a7839620/attachment.html>


More information about the Gnutls-devel mailing list