On Tue, Jun 30, 2026 at 01:57:09AM +0000, Wang Guilin wrote: > > So, as what I understand now, the ability of signing and/or verifying > is also a conern. Therefore, for a case like TLS client and server > communicate with each other using their cert, at least there levels > of capability should be taken into consideration: > > 1) It has classic or PQ key certified by a cert. > > 2) It's cert is signed by a CA using a classic or PQ key. > > 3) It can sign and/or verify PQ signatures, or not. > > As both sides are symmetric, there will be a number of combinations.
As note, TLS can signal RP signature capabilities. So the AP can know if the RP supports PQ keys / PQ certificates. The mechanism even supports things like RP allowing classical keys but requiring PQ certificates (phase 3 in the Google roadmap). However, correct certificate selection still likely requires AP to be updated to have PQ support. Hence the Google roadmap discussing nasty hacks. (Usually client is RP and server is AP, but in mTLS, both endpoints act as RP and AP.) With certificates, only three of above four combinations are sensible, but there is fourth sensible case: 1) Classical key, classical chain. 2) Classical key, PQ chain. 3) PQ key, PQ chain. 4) PQ key, MTC. ... With added fun of APs that are capable of 1-3, but not 4. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
