> > > I am confused. Perhaps there is a typo in your sentence. > > I mean a client/server B supporting PQ may still accept a legacy client A > with fully classical chains, in transmission period (say now - 2030.12.31). > Here is an imaginary example: > > - now - 2027: A just has a classical cert (i.e a classic key with a > classic chains). B has a > classical cert and a PQ cert. But accordingly to its security policy, B > still accepts A's authentication using classic signatures. >
Ah, ok! (So keeping this classical chain around without making a distinction whether the owner has upgraded allows for a downgrade. You want A's classical certificate to be different from B's classical certificate. A's can have PQ chain but classical leaf, whereas B's classical chain must be fully classical.) > 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. > Indeed. In my previous e-mails, to keep things simple, I've only discussed one-sided server->client authentiation. Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
