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.


_______________________________________________
Gnutls-devel mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
  • [gnutls-de... Read-only notification of GnuTLS library development activities
    • Re: [... Read-only notification of GnuTLS library development activities

Reply via email to