<!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/asosedkin">Alexander Sosedkin</a> created an issue <a href="https://gitlab.com/gnutls/gnutls/-/issues/1172">#1172</a>:
</p>
<div></div>
<p dir="auto">This request is driven by the needs of crypto-policies, a tool to configure system-wide defaults of cryptographic software.</p>
<p dir="auto">While the new configuration mechanism introduced in <a href="https://gitlab.com/gnutls/gnutls/-/merge_requests/1013" data-original="!1013" data-link="false" data-link-reference="false" data-project="179611" data-merge-request="30360961" data-project-path="gnutls/gnutls" data-iid="1013" data-mr-title="Enhance the configuration file capabilities" data-reference-type="merge_request" data-container="body" data-placement="top" title="" class="gfm gfm-merge_request">!1013</a> does achieve the <a href="https://gitlab.com/gnutls/gnutls/-/issues/587#note_107211054" data-original="announced goal of hard-disabling algorithms" data-link="true" data-link-reference="true" data-project="179611" data-issue="14760895" data-reference-type="issue" data-container="body" data-placement="top" title="Provide a configuration file" class="gfm gfm-issue has-tooltip">announced goal of hard-disabling algorithms</a>, it doesn't offer matching soft-disabling capabilities.
An operating system vendor should be allowed to disable contentious algorithms by default, but still allow applications to reenable them back on a case-by-case basis, without blanket-enabling the algorithm for all applications and usages.</p>
<p dir="auto">Priority strings are the established way to soft-disable algorithms, and are sometimes even exposed all the way to the configuration files.
But priority strings cannot readily satisfy this request, as they have two limitations in comparison with the new configuration format:</p>
<ol dir="auto">
<li>
<a href="https://gnutls.org/manual/html_node/Priority-Strings.html" rel="nofollow noreferrer noopener" target="_blank">priority strings definition</a> limits them to TLS only, so priority strings don't cover the <code>insecure-sig</code>, <code>insecure-sig-for-cert</code> or <code>insecure-hash</code> controls range</li>
<li>priority strings don't possess the granularity available with the new format: there's <code>%VERIFY_ALLOW_SIGN_WITH_SHA1</code>, but, besides that, <code>insecure-sig-for-cert</code> doesn't seem to have a generic priority string counterpart.</li>
</ol>
<p dir="auto">Thus the request for feature-parity between soft-disabling and hard-disabling capabilities of gnutls configuration.</p>
<p dir="auto">For that, I guess we should first clarify and establish whether it's OK to extend priority strings beyond TLS usage.
If it is ruled fine, then adding new keywords to priority strings seems to be the solution.
If it's not, I suppose extending the configuration format to allow soft-disabling is also an option, though there still remains a question of how exactly should applications relax the defaults tightened with those hypothetical new options.</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/1172">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/cd726a3d4df37a38fca8b2cef054ed4b/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/1172"}}</script>
</p>
</div>
</body>
</html>