Hi TLS, I can say that we at Entrust are definitely planning to use composites in TLS for client authentication. So, at the bare minimum we would require code points. We think having a draft that discusses the nuances of using Composite in TLS is useful, and choosing a small subset will help with interoperability.
In regard to implementation, I know of at least 10 implementations of composite signatures that have been willing to publicly submit artifacts into the IETF PQ Certificates interoperability project: See test results here: https://ietf-hackathon.github.io/pqc-certificates/pqc_hackathon_results_certs_r5.html I also know of a handful of others that haven't contributed yet. So, it appears there are quite a few parties that have invested capital in implementing composite signatures because they want to use them. In regards to lessons learning during the interoperability testing, the most difficult part has been dealing with the nuances of the classical encodings (like RSA parameters, EC private key encodings) and those kinds of things. However, with the ability to collaborate together and having the artifact repository available for testing, these minor issues were easily resolved. Composite Signatures (and Composite KEM) were designed with "protocol backwards compatibility" in mind. That is achieved because they simply implement the standard keygen(), sign(), verify() methods (or keygen(), encapsulate(), decapsulate()). So anything that works as a signature algorithm (or KEM) just slot into existing protocols. Our hackathon team has tested composites with X509Certificates, CRL signing, CSR Signing, CMS Signatures, TLS and other things. At our January interim hackathon, Nikola Tuveri showed us a demo of composite TLS authentication in firefox. (See https://github.com/IETF-Hackathon/pqc-certificates/discussions/262 for a summary). Other than having to register the new Composite IANA OIDs (which were official in October 2025), no other code needed to be touched. We get hybrid security for a small effort (essentially the same amount of work as adding pure ML-DSA). So I would like to ask the TLS working group to keep moving forward with this draft. Cheers, John Gray Entrust Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
