Hi Usama, Yes, B.5.1 is intended to specifically exclude use cases like Attested TLS. The WG could of course decide to adopt this draft and expand its scope, but for an -00 we wanted to focus only on the PQC Migration use case.
Considering the use case of multiple identities would make the draft more complex in the following ways: 1. You need to allow the same algorithm on both cert chains, which the current draft forbids in order to keep the negotiation logic simpler. 2. You need to provide a mechanism to negotiate separate certificate_authorities lists for each chain. 3. A bunch of edge-cases pop up when you have one cert that does hostname as usual, and a second cert with a totally different type of identifier, such as OEM Hardware Serial, or some corporate machine ID. What does it mean for a TLS client to validate this? Does the client assume that the hostname type cert is in the first slot and the other cert in the second slot? Etc. In my opinion, a draft for "Multiple Identity Certificates in TLS" could be written that uses some of the the same wire structures as this draft, but would need normative language, and possibly new wire structures, to handle the things above. --- Mike Ounsworth -----Original Message----- From: Muhammad Usama Sardar <[email protected]> Sent: Thursday, June 19, 2025 5:04 PM To: Yaroslav Rosomakho <[email protected]>; [email protected] Cc: Hannes Tschofenig <[email protected]>; Mike Ounsworth <[email protected]> Subject: [EXTERNAL] Re: [TLS] Dual certificates in TLS proposal I may be missing something from PQ side but I wonder what exactly is meant in Appendix B.5. For example, I have some trouble in precisely parsing the last sentence in B.5.1. Moreover, what is the difference between "identities" and "identifiers"? These terms are not even mentioned elsewhere in the draft. More specifically, I was thinking about attested TLS. We proposed modification of CertificateVerify message as one of the potential solutions for attested TLS (slide 7/15 in [1]). In this case, one identifier is network identity and the other identifier is state of server (assuming server as Attester). Is Appendix B.5.1 meant to explicitly exclude such use cases of dual certificate in your design? If yes, why exactly? In order words, what design problem and/or extra work do you see in making it more generic for wider applications rather than limiting it to PQ/T? Usama [1] https://datatracker.ietf.org/meeting/122/materials/slides-122-tls-identity-crisis-00
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
