I think it's good to think about the full chains* instead of just the leaf certificate. There are three to distinguish.
1. Classical cert for legacy client. This will be a fully classical chain that will never be accepted by a client supporting PQ. 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. 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. Certainly the upgraded server shouldn't combine 2 with anything, as that 2 allows for downgrades. 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. Then we still have the case of the legacy server. How do we recover the composite PQ signatures in the chain? I don't think that'll work as the server would need to be updated to support this, which seems implausible if it can't be updated to support PQ in the first place. Best, Bas On Thu, Apr 30, 2026 at 11:07 AM Stephen Farrell <[email protected]> wrote: > > Hiya, > > On 30/04/2026 07:52, Viktor Dukhovni wrote: > > And yes, the introspection API currently does not support returning > > multiple matching TLSA records and certificates (or RPKs) at the > > conclusion of the handshake, nor reporting multiple signature algorithms > > as having played a role... So reporting the resulting state gets rather > > hairy. > > Yep, I think I agree that David's point about APIs is > valid, but could be worked around. (I'm also not that > convinced by the same API argument as used in the plants > design, but that's another story;-) > > > So, while I'm not explicitly indicating which of composites or > > multi-certs I dislike more, there are definitely complications > > in both I'd strongly prefer to entirely avoid. > > That seems fair, though I do think composites are worse in > the longer term than multi-certs because web servers will > in all cases need to be configured with both trad certs and > pure PQ certs just to keep interop with all clients. (Or, > perhaps in future with multiple PQ sig alg certs as the > deployment of those algs evolves.) > > I'm also not sure how to evaluate the real risk of (a singular) > pure PQ sig versus a multi-cert approach, but if nobody really > wants to take the pain of a multi-cert thing, then I guess we > may just have to live with the situation that individual TLS > sessions are either authenticated via one trad alg or one pure > PQ one. > > Cheers, > S. > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
