[gnutls-devel] GnuTLS | Interaction between enabled curves, key exchanges and signature algorithms (#1625)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Tue Jan 21 13:12:23 CET 2025
Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/issues/1625#note_2307586027
It sounds like having three controls is the cleanest way, primitive, TLS groups and cert.
>From the perspective of generating configs for gnutls as part of crypto-policies,
enabling any of the high-level usages will then also generate the line to trust the primitive.
1. higher-level controls should not be treating groups as composite algorithms:
enabling hybrid groups must be orthogonal to enabling pure algorithms, e.g for SECP256R1 and MLKEM768:
1. tls-enabled-group = SECP256R1-MLKEM768 must not enable neither SECP256R1 nor MLKEM768 in isolation
2. enabling SECP256R1 and MLKEM768 must not enable SECP256R1-MLKEM768
2. but it's fine for lower-level controls meant to disable entire primitives to disable all TLS groups using it
3. introducing some separate cert-enabled-curve for chain validation seems OK to me,
and it sounds like it should not auto-enable the primitive control curve-enabled,
while not having curve-enabled on should override it off.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1625#note_2307586027
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/20250121/85855e96/attachment-0001.html>
More information about the Gnutls-devel
mailing list