[gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

[Read-only notification of GnuTLS library development activities]

Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1172



This request is driven by the needs of crypto-policies, a tool to configure system-wide defaults of cryptographic software.

While the new configuration mechanism introduced in !1013 does achieve the [announced goal of hard-disabling algorithms](https://gitlab.com/gnutls/gnutls/-/issues/587#note_107211054), 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.

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:

1. [priority strings definition](https://gnutls.org/manual/html_node/Priority-Strings.html) limits them to TLS only, so priority strings don't cover the `insecure-sig`, `insecure-sig-for-cert` or `insecure-hash` controls range
2. priority strings don't possess the granularity available with the new format: there's `%VERIFY_ALLOW_SIGN_WITH_SHA1`, but, besides that, `insecure-sig-for-cert` doesn't seem to have a generic priority string counterpart.

Thus the request for feature-parity between soft-disabling and hard-disabling capabilities of gnutls configuration.

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.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1172
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/20210128/895cf334/attachment-0001.html>