[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