Document: draft-yusef-tls-pqt-dual-certs-02.txt
Overall, if we are to support the simultaneous use of PQ and
traditional signatures in TLS, I think that composites are a superior
approach. As far as I can tell, the only real benefit of this design
is that it allows you to perform a transition of the form traditional
-> simultaneous PQ/T -> pure PQ while avoiding the need to issue
separate composite certificates.
The cost of this savings is quite a bit of additional complexity in
TLS. I'd like to see some analysis that shows that cost is worth
paying. Given modern automation (ACME) and shortened certificate
lifetimes, it's hard to believe just issuing the certificates is a big
deal, though perhaps technically being able to make the composites is?
In any case, I'd like to see much stronger arguments than have been
advanced here before we absorb this complexity.
With that said, even on its own terms I think this draft is trying
to get too clever. Specifically by:
- Overloading the signature scheme code points to indicate that
you are sending multiple certificate chains.
- Only signing a partial transcript.
At a high level, it's not clear to me that this encodes the right
semantics. As covered in quite a bit of detail in Chrome's roadmap
[0], we have to distinguish between the algorithm encoded in the EE's
certificate and the algorithms used to sign that certificate and other
certificates in the chain, and there are benefits to requiring a PQ
PKI even if you don't have PQ keys (stage 3 in Google's roadmap).
# Signature schemes
You state in S 4.1.
Dual code points are advertised and negotiated using the existing
signature_algorithms extension defined in Section 4.2.3 of [TLS],
exactly as for any other SignatureScheme. A client that supports
dual authentication includes the relevant dual code points in its
signature_algorithms list. The server selects one code point from
the client's list, just as in standard TLS 1.3 negotiation.
The message in which the server's choice is conveyed is in
CertificateVerify, but the client needs to parse the Certificate prior
to seeing CertificateVerify, which means that it doesn't know whether
a dual code point is in in use or not at the time it processes the
Certificate. Instead, it must parse either version and then fail if
(for instance) the server sent two certificate chains but then signs
with a single algorithm. This is possible but kind of unfortunate,
especially because of the way you handle the transcript.
Second, these code points have narrower semantics than ordinary
signature schemes, because (for instance) you cannot use them to sign
the certificate. The result of both of these design choices is a
bunch of special case state keeping associated with these special
signature schemes.
Finally, it's not clear to me what the semantics of this extension
actually are. Suppose that I advertise the following signature
algorithms:
[
ecdsa_secp256r1,
sha256_mldsa44
]
This allows the server to supply me with a P-256 certificate signed
with an MLDSA key (or vice versa). Now if I add
ecdsa_secp256r1_sha256_mldsa44, what does this say about the
certificate in the PQ chain. Can it be signed by a P-256 key? If not,
what text forbids this and what is the general rule?
I recognize that it's tricky to actually design something with the
right semantics here, but I don't think this is quite there and
overloading this extension seems to make the problem harder.
# Only Signing a Partial Transcript
Instead of signing the whole transcript, as everything else in
TLS does, each algorithm just signs the transcript corresponding
to its own certificates. As I understand it, you are doing this
for domain separation reasons, but the consequence is that we
are in uncharted territory about the security of TLS, and in
particular that neither signature is endorsing the other's
certificates. Do you have any analysis for what this does
to the security of TLS?
In addition, it's an implementation problem because it means that the
RP needs to maintain two transcripts rather than just hashing in the
Certificate message as received. Incidentally, the way you have
specified this seems to remove the Certificate message's headers,
which would otherwise be in the transcript, as per S 4.4.1 of RFC
8446.
It seems like there ought to be some other way to provide
domain separation.
-Ekr
[0]
https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/
On Wed, Jun 24, 2026 at 11:24 PM tirumal reddy <[email protected]> wrote:
> Hi all,
>
> The draft https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/
> has been revised to address the comments received from the WG during the
> presentation at IETF-123.
>
> The draft no longer defines any new TLS extension. Dual authentication is
> signaled entirely through new SignatureScheme code points, negotiated with
> the existing signature_algorithms extension; the negotiated code point
> determines how the existing Certificate and CertificateVerify messages
> carry the two chains and two signatures.
>
> Further comments and suggestions are welcome.
>
> Regards,
> -Tiru
>
> ---------- Forwarded message ---------
> From: <[email protected]>
> Date: Wed, 24 Jun 2026 at 13:59
> Subject: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt
> To: Tirumaleswar Reddy.K <[email protected]>, Hannes Tschofenig <
> [email protected]>, Hannes Tschofenig <[email protected]>,
> Mike Ounsworth <[email protected]>, Rifaat Shekh-Yusef <
> [email protected]>, Yaroslav Rosomakho <[email protected]>
>
>
> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-02.txt has
> been
> successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name: draft-yusef-tls-pqt-dual-certs
> Revision: 02
> Title: Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual
> Certificates in TLS 1.3
> Date: 2026-06-24
> Group: Individual Submission
> Pages: 20
> URL:
> https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.txt
> Status: https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/
> HTML:
> https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-yusef-tls-pqt-dual-certs-02
>
> Abstract:
>
> The anticipated emergence of cryptographically relevant quantum
> computers (CRQCs) poses a threat to the authentication mechanisms
> used in TLS 1.3. This document defines a hybrid authentication
> mechanism that uses two independent certificates, one traditional and
> one post-quantum, ensuring that an attacker must break both
> algorithms to compromise a TLS connection. The two certificate
> chains are carried in a single Certificate message and two
> independent signatures are encoded in the CertificateVerify message.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> 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]
