Hi Stephen, I'm not quite sure, whether I've understood your remark correctly:
Am Mittwoch, dem 15.07.2026 um 20:22 +0100 schrieb Stephen Farrell: > > Hiya, > > The original comment may have been somewhat mis-directed but I > wanted to react to this nonetheless: > > On 15/07/2026 17:59, Erwin Hoffmann wrote: > > > > Thus, my argumentation is: In order to give a valid guidance, one > > has > > to consider generation, transport, and usage of those certificates. > > I would call this a 360 degree view. > > The above ignores (or at least doesn't call out) TLS server handling > of > private keys and certificates. I think that makes a difference for > the > dual vs composite situations. 100% correct: a) Dual case: It would be difficult to provide multiple certificates (+key files on the server side) in the TLS handshake. No doubt about. b) Composite keys: Here, we have one cert in flight with two different algs. Certs are used for auth only, thus some mechanism needs to be defined to allow (PKI) verification. > I also think we'd (the TLS WG) be wise to > pay attention to server package maintainers on that topic. (Which is > not > the same as paying attention to those who operate the most commonly > used > servers.) I'm not sure myself what, if any, preferences they might > have, > but many of them will have to make changes, if whatever PQ auth > solution > is to work for the vast majority of TLS servers. (Which I assume is a > goal.) The situation I've described in my post (RSA+Ed25519 for DKIM), is certainly easier and less security relevant, although it impacts downgrading. But again: All these aspects need to be addressed and are independent of the signing operation. Maybe it would helpful to digest 'dual signing' with DKIM as particular showcase and use this to find a good path for classical, SLH, and PQ signatures and how to solve the coexistance problem? c) One potential solution would be to enhance the 'Certificate chain' method to allow a tree-like chaining. Never mind. Regards. --eh. > > Cheers, > S. > -- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 36553F7F9C58D1CC PGP key-fingerprint: 950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
