Hi Ryan,
On 27/05/2024 16:39, Ryan Hurst wrote:
[...]
Moreover, there's the liability issue: a CA that cross-signs another
CA exposes its business to distrust based on the practices of the CA
it cross-signs.
[...]
As someone who has both provided said cross-signs and received them I
really don't see them as the silver bullet others seem to in this thread.
This thread is purely talking about cross-signs between two roots
operated by the same CA, which is the case when an existing CA with
classical root is generating a new PQ root.
This is completely standard practice, as exemplified by Let's Encrypt,
DigiCert and Sectigo's pages describing their cross signs between the
roots they operate [1,2,3]. There are no commercial relationships or
sensitivities involved because the same organization controls both the
signing and the cross-signed root.
I guess you assumed the alternative scenario where the roots belong to
two different CAs. The standard terminology of referring to both as a
cross-sign is regrettably vague.
Best,
Dennis
[1] Let's Encrypt X2 is cross signed by Let's Encrypt X1
https://letsencrypt.org/certificates/
[2] Digicert G5 by the Digicert Global Root CA
https://knowledge.digicert.com/tutorials/install-the-digicert-g5-cross-signed-root-ca-certificate
[3] Sectigo UserTrust is cross signed by Sectigo AAA
https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots
Ryan Hurst
On Mon, May 27, 2024 at 2:31 AM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote:
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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
