<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<p style="color: #777777;">
<a href="https://gitlab.com/kmiller">Kenneth J. Miller</a>
commented on a
<a href="https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352577566">discussion</a>:
</p>
<div style="">
<blockquote dir="auto">
<p>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 <a href="https://tools.ietf.org/html/rfc5280#section-6.1" rel="nofollow noreferrer noopener" target="_blank">Basic Path Validation procedure</a> quite naively, meaning that it assumes that the <code>n</code>th certificate is signed by <code>n-1</code>th, and individual certificate validity is only checked at the <a href="https://tools.ietf.org/html/rfc5280#section-6.1.3" rel="nofollow noreferrer noopener" target="_blank">Basic Certificate Processing phase</a>.</p>
</blockquote>
<p dir="auto">It seems to be that the chain sent by a server is a single path as defined in <a href="https://tools.ietf.org/html/rfc5246#section-7.4.2" rel="nofollow noreferrer noopener" target="_blank">RFC5246</a> and <a href="https://tools.ietf.org/html/rfc4158#section-1" rel="nofollow noreferrer noopener" target="_blank">RFC4158</a>. This was my misunderstanding. The second chain order above also fails when tested in OpenSSL 1.1.1f, as it should according to this.</p>
<p dir="auto">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.</p>
<p dir="auto">While validation of a single path is the scope of section 6.1; section <a href="https://tools.ietf.org/html/rfc5280#section-6.2" rel="nofollow noreferrer noopener" target="_blank">6.2. Using the Path Validation Algorithm</a> states:</p>
<blockquote dir="auto">
<p>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.</p>
</blockquote>
<p dir="auto">While this is a bit vague, it opens up the possibility that a single path may have multiple trust anchors by not forbidding it.</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352577566">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/-/sent_notifications/a8b9ecb6e21bb49338d9418869a0dc1b/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352577566"}}</script>
</p>
</div>
</body>
</html>