Thanks for the detailed reply. On the last point about downgrade, I need to think further.
> >> 1. Classical cert for legacy client. This will be a fully classical chain > >> that will never be accepted by a client supporting PQ. >> I am not quite agree on this: This depends. In transmission period (say now >> - 2030.12.31), a client supporting PQ may still accept a legacy client with >> fully classical chains. > 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. - 2028- 2029: B's security policy will be updated, so B cannot accept A's authentication only using classic signatures anymore. But A can autheticate itself to B by using A's classic signatures and PSK, OR PQ signatures. - From 2030: A must use PQ signatures to authenticate itself to B. === 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. Guilin 发件人：Bas Westerbaan <[email protected]<mailto:[email protected]>> 收件人：Wang Guilin <[email protected]<mailto:[email protected]>> 抄 送：Eric Rescorla <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>;Wang Guilin <[email protected]<mailto:[email protected]>> 时 间：2026-06-29 05:55:05 主 题：Re: [TLS] Re: Upleveling on PQ + T signatures for TLS When talking about certificates or certificate chains, there are at least two concepts very related: the user's public key certified by its cert, and the CA's public key/algorithm used to sign a cert. It seems naturally to think that a legacy client means a client whose cert is certified by a CA using a classical algorithm for the user's classical public key. I will assume this to understand your thoughts. Not quite: with legacy server/client I mean a server/client that have not (been able to) receive an update. Hence, for server authentication, a legacy client doesn't know how to verify a PQ signature and a legacy server doesn't know how to sign with a PQ key. [But if a CA signs a client's classic public key by a PQ or hydbrid signature, is such a client still called a legacy client? Given we're talking about server authentication I think your question would be "But if a CA signs a [server]'s classic public key by a PQ or hydbrid signature, is such a [server] still called a legacy [server]?" To which my answer is emphatically: yes! You can install a classical leaf with a PQ chain on a legacy server. There might be a problem if the server software tries to check the chain, but not all do. And if it turns out to be common, we could hide the PQ chain somewhere in an extension or the like. In any case, the point is that a PQ client can still gain a PQ secure signal that the server is indeed legacy. Also, is it just silly or must be technically prohibited to sign a client's PQ key by a CA using classic signtaure? ] I have not formed an opinion here. > 1. Classical cert for legacy client. This will be a fully classical chain > that will never be accepted by a client supporting PQ. I am not quite agree on this: This depends. In transmission period (say now - 2030.12.31), a client supporting PQ may still accept a legacy client with fully classical chains. I am confused. Perhaps there is a typo in your sentence. > 2. Classical cert for legacy server. This is to provision at servers that are > not able to sign with PQ. Its chain and CT-cosignatures will be PQ. The distinction between 1 and 2 is very important. A server operator that knows its server supports PQ has no need for 2, and thus would sound the alarm if it sees chain 2 appear in CT for its domain. Also thanks to the PQ chain, creating chain 2 when not requested requires misissuance by a CA. An interesting difference. But such a server is not a real legacy server, as its chain and CT-cosignatures are signed by PQ, though it still uses classic algorithm to sign. See above. > Certainly the upgraded server shouldn't combine 2 with anything, as that 2 > allows for downgrades. Did not see real downgrades. Hope I did not misunderstand your point here. If you do not make the distinction between a legacy certificate for a legacy client and one for a legacy server, then there is indeed a downgrade. This is because upgraded clients need to accept some classical certificate of a legacy server. If that is the same as the classical certificate for a legacy client, then its existence doesn't raise alarms as it should. Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
