One of the key use cases proposed for Trust Expressions is enabling a
speedy deployment of PQC Certificates. I agree this is an important use
case to address, but I think a closer inspection of the existing
deployment options shows that Trust Expressions does not provide any
improvement or new functionality over existing, already widely deployed
solutions.
In particular, having each CA cross-sign their new PQC root with their
existing classical root. This does not require any new functionalities
or code changes in TLS clients or servers, does not require coordination
between CAs / Root Programs / Clients and does not impose any
performance impact on the connection (perhaps surprisingly).
The rest of this message details the Trust Expressions proposal for a
PQC transition and compares the security and performance to existing
solutions.
*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various Root
Programs will include various PQC Roots and start distributing them to
their clients. They will also configure their clients to start
advertising the relevant PQC / hybrid signature algorithms in their
signature_algorithms_cert TLS Extensions. TLS Servers will decide
whether to send their classical chain or their PQC chain according to
this extension.
The Trust Expressions authors plus quite a few folks on the list have
stated that this approach will require us to wait for all major root
programs to accept a given PQC Root and then for that PQC root to be
ubiquitously supported by all clients which also advertise PQC Signature
Support. Otherwise, we might send our new PQ Chain to a client who only
has an older set of PQ Roots, which would cause a connection failure.
This wait could take a long time, even a year or more.
Trust Expressions proposes that by having clients indicate their trust
store label and version, we can mostly skip waiting for ubiquity.
Through the Trust Expression's negotiation, we can be sure that we only
send the PQC Root Certificate Chain to clients that have already updated
to trust it. Meanwhile, clients that don't have PQC Signature support or
do support the signatures but don't have the new PQC root will continue
to receive the old classical chain and not enjoy any PQ Authentication.
*The Existing Alternative
*I believe this argument for the use of Trust Expressions overlooks
existing widely available deployment options for PQC Certificates, which
mean that we do not need to wait for multiple root stores to include new
PQC certs or for them to become ubiquitous in clients. We will see how
we can achieve the exact same properties as Trust Expressions (no
waiting for ubiquity, no connection failures and PQ-Auth for all clients
with the PQ Root) without the need for any new designs or deployments.
When CAs create roots with new signature algorithms (e.g. ECDSA Roots),
it is common practice to cross-sign the new root with the existing root
(e.g. an RSA Root). This is the approach taken by Let's Encrypt today,
who have an older RSA Root (ISRG X1) and a newer ECDSA Root (ISRG X2).
X2 is cross signed by X1, and each of the new ECDSA Intermediates are
also cross-signed by X1 [1]. In the context of RSA vs ECDSA, this isn't
especially interesting because there's a purely a tradeoff between a
smaller chain (ECDSA/X2) vs a more ubiquity (RSA/X1). However, we'll see
this approach has much more substantial benefits with PQC Signatures.
When the time comes to ship a PQC Root (which we'll call X3 for
convenience), we'll make some PQC Intermediates (F1, F2, F3). We will
also cross sign these intermediates with our X2 (ECDSA) Root which we'll
call H1, H2, H3. So both F1 and H1 are certificates on the same
intermediate PQC Public Key, with F1 having a PQC signature and H1 a
ECDSA signature from their respective roots.
When we provision servers with their certificate chains, we'll provision
the PQC Chain as their leaf (PQC Public Key + PQC Signature), plus both
F1 and H1. Clients that don't indicate support PQC Signatures in their
signature_algorithms_cert extension will receive the usual classical
chain. Clients that support PQC and have the new root will verify the
leaf + F1 and so enjoy PQ-Auth. Clients that support PQC and don't have
the new root will verify the leaf and H1 and not receive PQ-Auth.
This achieves identical properties to Trust Expressions in terms of
client security and doesn't involve any waiting for PQC Root Ubiquity or
Root Store Approval. The only impact is the extra certificate in the
chain. Happily, we can cut the overhead of H1 to be a mere 32 bytes with
existing TLS Certificate Compression Algorithms like zlib / zstd /
brotli (since H1 and F1 encode the same PQC Public Key). This is tiny
compared to the necessary PQC Public Key and Signature already in the
chain. With new schemes like Abridged Certs, we can go even further and
replace all but the leaf certificate with two-byte identifiers.
There are several alternatives available as well depending on the exact
use case. For example, we could send only F1 (PQC Intermediate chaining
to X3) and an X3 Root signed by X2 - ensuring there's only a single
chain and no path building support required. Clients with the X3 PQC
Root will not need to check the final ECDSA signatures, others will.
With existing TLS Certificate Compression algorithms, this compresses
slightly worse than the dual-intermediates chain, but Abridged Certs
works just as effectively. AIA Chasing is also deployed in Chrome and
could be used to fetch this final cross-sign certificate if desired,
although I think stateless mechanisms like Certificate Compression with
zlib are preferable.
In the event we'd like to make a second future transition, e.g. from a
hybrid PQC signature scheme to a solely PQC scheme, or between PQC
schemes, the same approach as above works just as well. I would fully
expect by time we'd be considering a second transition, we'd either have
mature deployment of solutions like intermediate suppression or abridged
certs, or we'd be considering a move away from X.509 entirely to a
newer, slimmer, PKI system.
Overall, I hope this is convincing that the Trust Expressions design
does not achieve any improvements over existing technology for
transitioning to PQC Certs and so I think we can set this proposed use
case aside from the wider discussion.
*Wider Thoughts on the PQC Transition
*
In isolation, drafts like Abridged Certs and Trust Expressions can each
deliver roughly the same size PQC Certificate Chains, able to compress
down everything but the leaf certificate to just a couple of bytes.
Depending on whether you expect PQC Signatures for SCTs, this gives an
overall size of either ~4 KB - similar to RSA Chains today - or a rather
unpalatable ~9 KB.
Although recent work on improved CT log implementations like Sunlight is
vital for the ecosystem and fantastic to see, I'm still quite concerned
about the long term story for a Post Quantum PKI with strong
transparency guarantees. There are existing proposals like Merkle Tree
Certificates which look to eliminate X.509 entirely and replace
signatures with proofs of inclusions. I think these ideas are pretty
exciting and with refinement could be a promising way forwards, but do
have a few open problems that we still need to solve (especially on the
transparency and availability aspects).
However, we do not need Trust Expressions to do Merkle Tree Certs or any
alternative design, these features would necessarily need their own
negotiation mechanism and so we should not confuse the two proposals.
Best,
Dennis
[1] https://letsencrypt.org/certificates/ *
*
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
