Thanks for sharing your thoughts: https://mailarchive.ietf.org/arch/msg/tls/Rn7GHZGXnWv_TRxBpMkRXAYQ-wk/
> I think it's good to think about the full chains* instead of just the leaf > certificate. There are three to distinguish. Yes, it seems a good idea think about the full chains, not just leaf certificate. 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. [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? Also, is it just silly or must be technically prohibited to sign a client's PQ key by a CA using classic signtaure? ] > 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. This may be just the policy of the organization to which the client supporting PQ belongs (under the regulatory requirenents, etc). Or, are there any technical reasons so that IETF should have RFCs to probihit such potential practice? > 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. > 3. Post-quantum cert. > A legacy server installs 2. An upgraded server installs 1 and 3. > How can we use Stephen's proposal to get the same properties as if all > PQ-sigs in 2 & 3 were composite? > The upgraded server has two chains (1, 3) so let's verify with both. But > there is a footgun here: an upgraded client should never accept chain 1 on > its own. Again, this may be a policy issue. Why should never accept? > 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. > So I think we would need to create a new chain: 3b, a fully classical chain > that's only accepted by an upgraded client in combination with a fully PQ > chain. 3b also seems interesting. More comparisons may be helpful to see which is better or even the best. Guilin 发件人：Bas Westerbaan <[email protected]<mailto:[email protected]>> 收件人：Eric Rescorla <[email protected]<mailto:[email protected]>> 抄 送： <[email protected]<mailto:[email protected]>> 时 间：2026-06-26 16:29:06 主 题：[TLS] Re: Upleveling on PQ + T signatures for TLS On Thu, Jun 25, 2026 at 8:19 PM Eric Rescorla <[email protected]<mailto:[email protected]>> wrote: Hi folks, We now have a number of proposals for somehow using both PQ + T signatures simultaneously for TLS. These include: - Dual Certificates: draft-yusef-tls-pqt-dual-certs - Composite Certificates: draft-reddy-tls-composite-mldsa - Multiple Certificate/CertificateVerify: https://mailarchive.ietf.org/arch/msg/tls/dVj5I_s8Hj5s4Fzmbv73qac_Ftk/ It seems to me that all of these share the same basic intuition, namely that it's more secure to use both PQ + T algorithms together instead of individually. It's not clear to me whether all of these approaches have the same security properties, but it seems likely that with enough work they can be made to the deliver on the basic value proposition of robust authentication as long as one of the algorithms is strong [0]. I don't see how dual certificates could be adjusted to be used in the case of a classical certificate for a legacy server where you'd want a classical leaf signature and a PQ CA signature. The obvious thing looses the distinction between that certificate and the legacy certificate meant for a legacy client, which leads to a downgrade. This is the same problem as with multiple certificate(verify) messages, where I discussed it in a bit more detail: https://mailarchive.ietf.org/arch/msg/tls/Rn7GHZGXnWv_TRxBpMkRXAYQ-wk/
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
