My comment was intended to address the larger conversation in the thread regarding cross-signs. That said, as you point out, there is absolutely nothing preventing a single entity from cross-signing itself. However, doing so with a hybrid chain weakens the security of the chain to the security properties of the certificate and keys being used for the cross-signing.
On Mon, May 27, 2024 at 9:51 AM Dennis Jackson <i...@dennis-jackson.uk> wrote: > 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
