[gnutls-devel] GnuTLS | Handle expiration of AddTrust root certificate (urgent) (#1008)

[Development of GNU's TLS library]

Kenneth J_ Miller commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352577566

> Though I am not following the discussion around this, my question is whether it is legitimate that the server sends such certificate chain. GnuTLS implements the [Basic Path Validation procedure](https://tools.ietf.org/html/rfc5280#section-6.1) quite naively, meaning that it assumes that the `n`th certificate is signed by `n-1`th, and individual certificate validity is only checked at the [Basic Certificate Processing phase](https://tools.ietf.org/html/rfc5280#section-6.1.3).

It seems to be that the chain sent by a server is a single path as defined in [RFC5246](https://tools.ietf.org/html/rfc5246#section-7.4.2) and [RFC4158](https://tools.ietf.org/html/rfc4158#section-1). This was my misunderstanding. The second chain order above also fails when tested in OpenSSL 1.1.1f, as it should according to this.

I've recreated a more accurate reproduction where the keys and DN from INTERMEDIATE 1 are used to create a self-signed certificate that is added the the trust anchor list. This example fails in GnuTLS 3.6.13, but succeeds in OpenSSL 1.1.1f.

While validation of a single path is the scope of section 6.1; section [6.2. Using the Path Validation Algorithm](https://tools.ietf.org/html/rfc5280#section-6.2) states:

> The path validation algorithm describes the process of validating a single certification path. While each certification path begins with a specific trust anchor, there is no requirement that all certification paths validated by a particular system share a single trust anchor. The selection of one or more trusted CAs is a local decision. A system may provide any one of its trusted CAs as the trust anchor for a particular path. The inputs to the path validation algorithm may be different for each path.

While this is a bit vague, it opens up the possibility that a single path may have multiple trust anchors by not forbidding it.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352577566
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/20200531/0e7a9948/attachment-0001.html>