<!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 class="details" style="font-style: italic; color: #666;">
<a href="https://gitlab.com/TheRealMichaelCatanzaro">Michael Catanzaro</a> created an issue: <a href="https://gitlab.com/gnutls/gnutls/-/issues/1286">#1286</a>
</p>
<div></div>
<h2 dir="auto">
<a id="user-content-description-of-the-feature" class="anchor" href="#description-of-the-feature" aria-hidden="true"></a>Description of the feature:</h2>
<p dir="auto">Over the past couple years, there have been a series of blog posts highlighting the need for improved certificate path building strategies in TLS libraries. Notably:</p>
<ul dir="auto">
<li>Ryan Sleevi (<a href="https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6" rel="nofollow noreferrer noopener" target="_blank">part one</a>, <a href="https://medium.com/@sleevi_/path-building-vs-path-verifying-implementation-showdown-39a9272b2820" rel="nofollow noreferrer noopener" target="_blank">part two</a>) describes a certificate path building strategy based on depth-first search, where path building is part of certificate verification and not a separate initial step in order to ensure the implementation can consider another path if verification of the first path fails.</li>
<li>
<a href="https://netflixtechblog.com/revisiting-bettertls-certificate-path-building-4c978b79843f" rel="nofollow noreferrer noopener" target="_blank">Ian Haken</a> introduces a bettertls test server that evaluates the robustness of TLS client path building, and shares the results for GnuTLS and other clients. Here he calls Ryan's strategy "branched" path building.</li>
<li>Scott Helme (<a href="https://scotthelme.co.uk/impending-doom-root-ca-expiring-legacy-clients/" rel="nofollow noreferrer noopener" target="_blank">part one</a>, <a href="https://scotthelme.co.uk/complexities-chain-building-ca-infrastructure/" rel="nofollow noreferrer noopener" target="_blank">part two</a>, and <a href="https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/" rel="nofollow noreferrer noopener" target="_blank">part three</a>, <a href="https://scotthelme.co.uk/building-certificate-chains/" rel="nofollow noreferrer noopener" target="_blank">part four</a>) provide additional background and motivation. (Most of this will already be familiar to TLS library developers.)</li>
</ul>
<p dir="auto">To the best of my knowledge, GnuTLS's current path building strategy is currently sufficient for compatibility with <em>today's</em> web. That said, it would be prudent to consider whether GnuTLS should adopt Ryan's suggested path building strategy, which would allow passing the bettertls tests. This might improve confidence that GnuTLS will be unaffected by <em>future</em> incidents where a large number of websites break after a particular root certificate expiration, similar to <a href="https://gitlab.com/gnutls/gnutls/-/issues/1008" data-original="#1008" data-link="false" data-link-reference="false" data-project="179611" data-issue="35220797" data-reference-type="issue" data-container="body" data-placement="top" title="Handle expiration of AddTrust root certificate (urgent)" class="gfm gfm-issue has-tooltip">#1008</a>.</p>
<h2 dir="auto">
<a id="user-content-applications-that-this-feature-may-be-relevant-to" class="anchor" href="#applications-that-this-feature-may-be-relevant-to" aria-hidden="true"></a>Applications that this feature may be relevant to:</h2>
<p dir="auto">All</p>
<h2 dir="auto">
<a id="user-content-is-this-feature-implemented-in-other-libraries-and-which" class="anchor" href="#is-this-feature-implemented-in-other-libraries-and-which" aria-hidden="true"></a>Is this feature implemented in other libraries (and which)</h2>
<p dir="auto">According to <a href="https://netflixtechblog.com/revisiting-bettertls-certificate-path-building-4c978b79843f" rel="nofollow noreferrer noopener" target="_blank">this blog post</a> this path building strategy is implemented by: Rusttls, Go, Java, LibreSSL, Firefox, Chromium</p>
<p dir="auto">Notably not implemented by: OpenSSL, BoringSSL</p>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #666;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1286">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/b7afad0c0b3e6fc4d13d25b4339e6212/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/1286"}}</script>
</p>
</div>
</body>
</html>