[gnutls-devel] GnuTLS | [RFE, low-priority] PKCS#12 / PKCS#8 policy controls (#1598)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Wed Oct 23 16:17:28 CEST 2024
Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1598
## Description of the feature:
GnuTLS currently does not limit the "strength" of the encryption it is willing to use through the PKCS#12 API,
so it will happily encrypt and decrypt a bag with, say, single DES.
While sane defaults for encryption would be solvable by just having sane defaults,
decryption is a harder problem in that the input data defines the algorithms used.
IMO, this is best solved by introducing configurables
for what is considered unacceptably weak for an app/system,
similarly to how it's done for TLS through the configuration file / allowlisting API / priority strings.
## Applications that this feature may be relevant to:
Good question, I'm not sure.
User-facing applications that use GnuTLS and import PKCS#12...
say, whichever ones let user supply a client cert?
Could be a GNOME-stack web browser, a hypothetical chat app or, say, a NetworkManager VPN plugin?
I haven't actually checked though.
## Is this feature implemented in other libraries (and which)
I am only somewhat familiar with two other libraries:
* NSS has this since its policy [gained purposes](https://phabricator.services.mozilla.com/D204145).
Note how NSS features a two-level trust value per algorithm:
forbidding, allowing to import but not export, allowing to export and import.
* OpenSSL does NOT provide proper configuration controls for that,
but it happens to dampen the problem of unsafe defaults by moving dated algorithms
to a so-called '[legacy provider](https://docs.openssl.org/master/man7/OSSL_PROVIDER-legacy)' which isn't loaded by default.
So, no accidental single DES importing there unless you've explicitly weakened your setup.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1598
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/20241023/0ebee526/attachment.html>
More information about the Gnutls-devel
mailing list