On Tue, Oct 28, 2025 at 10:34:27AM -0700, Jacob Champion wrote:
> On Tue, Oct 28, 2025 at 9:46 AM Nico Williams <nico@cryptonector.com> wrote:
>> RFC 5929 co-author here. We should take this to the IETF TLS WG mailing
>> list and update RFC 5929 and the tls-server-end-point registraion to fix
>> this.
Wow. Thanks Nico for the update!
>> Options in the case that the certificate's signature algorithm does not
>> have a digest associated with it include:
>
> Ah. (Filip, disregard my earlier question about the draft RFC and
> sigalgs; I think I understand now. I didn't look closely enough at the
> patch before sending.)
>
>> Maybe there are more options still. But we're not likely to solve this
>> problem here. This really belongs on the IETF TLS WG mailing list.
>
> +1. (Any immediate takers on the committer side?)
+1. Yes, I don't see how we can decide anything immediately without
making sure that our choice is compliant with the existing .
Assuming that OpenSSL provides an API that could help us here, do you
think that it could be possible to have access to it in 3.5 where
ML-DSA has been added? That's a matter to bring to OpenSSL upstream,
of course.
Btw, I don't think I would be that useful if we enter in these level
of details within the RFC, so perhaps it had better not be me who
follows up. :)
Among the options presented, I won't hide that being able to extract
an algorithm when we don't have an associated digest would be the most
interesting option when it comes to PG: that's a no-brainer in terms
of backpatching and would require no protocol changes while still
using the same name "tls-server-end-point" when exchanging the
SASL messages.
--
Michael
