> 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]
