[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
I've seen the topic of cross-signs mentioned multiple times in this thread, often with the assumption that they are simple and easy to secure. However, in practice, this is not the case. There are significant commercial challenges that often prevent cross-signing from being straightforward. For example, a non-profit CA, faces difficulty in finding commercial CAs willing to provide cross-signs due to commercial conflicts. Broadly, commercial CAs are not big fans of non-profit CAs for obvious reasons. 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. This means that if the cross-signed CA engages in practices that undermine trust, the cross-signing CA could also face reputational damage and loss of trust. Therefore, the complexities and risks associated with cross-signing are significant and often underappreciated in these discussions. This is reality is why new CAs are often forced to offer weaker ubiquity than the older CAs. 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. Ryan Hurst On Mon, May 27, 2024 at 2:31 AM Dennis Jackson 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
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
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 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,
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
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 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 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 >>
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
Hi Ryan, I wonder if the IETF mail servers are having a bad day again. I only see your reply to me, no other messages and currently the archives are only showing my initial email [1] with no replies. [1] https://mailarchive.ietf.org/arch/browse/tls/ On 27/05/2024 18:51, Ryan Hurst wrote: 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. I don't think there's any such thing as the security of the chain. Only the security of the *verifier* of the chain. If they trust a classical root, they can't do better than classical security. If they trust only PQ roots, it doesn't matter how many extraneous classical certs are in the chain if there's a valid PQ path from leaf to a known PQ root or intermediate. In both cases, the having a classical signature on a PQ root or intermediate doesn't change security for anybody, it only improves availability. Best, Dennis On Mon, May 27, 2024 at 9:51 AM Dennis Jackson 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 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 tha
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
Hi Ryan, On 27/05/2024 19:23, Ryan Hurst wrote: I don't understand your position on the verifier, the faith one can put in the chain of signatures is only the faith appropriate for the weakest signature. As such if a classical key is used to sign a PQ chain, an attacker would go after the classical signature ignoring the others. That's not quite right. Let's imagine we have a leaf public key L1, a PQ Public Key M1 and a Classical Public Key N1 and use <- to indicate 'signed by'. Consider the certificate chains: (1) L1 <- M1 (2) N1 -> L1 <- M1 (N1 and M1 are both intermediates signing the same leaf) (3) L1 <- M1 <- N1 (N1 cross-signs M1). Have we made things worse in (2) by adding a classical signature? No. Any verifier that would output accept on (1), will also output accept on (2) without even checking N1. So we cannot have made security worse for anyone that would accept (1). The opposite is also true, anyone that would trust N1 will not need to verify M1. So (2) strictly improves availability without reducing security for anyone. (This was my proposed design in the initial mail). For (3), we still have the property that anyone that would output accept on (1) would output accept on (3) without checking N1, so security for PQ users has not been reduced at all. The reverse direction for whether we hurt classical users requires us to trust that M1 is at least as secure as N1 - otherwise we're hurting security for the folks that trust N1 but not M1. In the context where M1 is a PQ-Hybrid and N1 is classical and both are operated by the same CA, this is perfectly fine. (This was my alternate design in the initial mail). The important nuance is this: we can *add* as many certificates / signatures as we like to the leaf node of a chain in order to improve availability without hurting security. We can also extend PQ chains with classical roots, without degrading the security of PQ users in any way. As a further thought experiment. Imagine we had a fully PQ PKI setup and established, then some attacker used their quantum computer to break a classical root and start adding a classical signature to all our secure PQ chains. This action would not impact security for any client which only trusted PQ signatures. They simply don't care about the classical signature and the attacker can't produce any new chains. For clients which did trust the classical signing algorithm, they're doomed no matter what, because the attacker can just make valid chains of their choice. Security all comes down to roots and signatures the verifiers accepts, not the chains we make :-). Best, Dennis Ryan On Mon, May 27, 2024 at 11:15 AM Dennis Jackson wrote: Hi Ryan, I wonder if the IETF mail servers are having a bad day again. I only see your reply to me, no other messages and currently the archives are only showing my initial email [1] with no replies. [1] https://mailarchive.ietf.org/arch/browse/tls/ On 27/05/2024 18:51, Ryan Hurst wrote: 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. I don't think there's any such thing as the security of the chain. Only the security of the *verifier* of the chain. If they trust a classical root, they can't do better than classical security. If they trust only PQ roots, it doesn't matter how many extraneous classical certs are in the chain if there's a valid PQ path from leaf to a known PQ root or intermediate. In both cases, the having a classical signature on a PQ root or intermediate doesn't change security for anybody, it only improves availability. Best, Dennis On Mon, May 27, 2024 at 9:51 AM Dennis Jackson 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 stan
[TLS]Re: I-D Action: draft-ietf-tls-tls13-pkcs1-01.txt
Hi! I asked the authors to spin a new version because the I-D would have expired during the WGLC. No substantive changes were introduced in this the -01 version. spt > On May 23, 2024, at 16:44, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-tls13-pkcs1-01.txt is now available. It is a > work item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 > Authors: David Benjamin >Andrei Popov > Name:draft-ietf-tls-tls13-pkcs1-01.txt > Pages: 7 > Dates: 2024-05-23 > > Abstract: > > This document allocates code points for the use of RSASSA-PKCS1-v1_5 > with client certificates in TLS 1.3. This removes an obstacle for > some deployments to migrate to TLS 1.3. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-tls13-pkcs1-01.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls13-pkcs1-01 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > 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
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
Just a reminder that this WGLC is still ongoing. spt > On May 22, 2024, at 10:14, Sean Turner wrote: > > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 > codepoints for TLS 1.3” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ > > The WG Last Call will end 5 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/tls13-pkcs1 > > Alternatively, you can also send your comments to tls@ietf.org. > > Thanks, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Transitioning to PQC Certificates & Trust Expressions
On Mon, May 27, 2024 at 10:39:27PM +0200, Dennis Jackson wrote: > Hi Ryan, > > On 27/05/2024 19:23, Ryan Hurst wrote: > > I don't understand your position on the verifier, the faith one can put > > in the chain of signatures is only the faith appropriate for the weakest > > signature. As such if a classical key is used to sign a PQ chain, an > > attacker would go after the classical signature ignoring the others. > > That's not quite right. > > Let's imagine we have a leaf public key L1, a PQ Public Key M1 and a > Classical Public Key N1 and use <- to indicate 'signed by'. Consider the > certificate chains: > > (1) L1 <- M1 > > (2) N1 -> L1 <- M1 (N1 and M1 are both intermediates signing the same > leaf) > > (3) L1 <- M1 <- N1 (N1 cross-signs M1). > > Have we made things worse in (2) by adding a classical signature? No. Any > verifier that would output accept on (1), will also output accept on (2) > without even checking N1. So we cannot have made security worse for anyone > that would accept (1). The opposite is also true, anyone that would trust N1 > will not need to verify M1. So (2) strictly improves availability without > reducing security for anyone. (This was my proposed design in the initial > mail). Except handling (2) is only SHOULD in TLS 1.3, and there are clients that don't implement that and blow up if presented with such "chain". Implementing such support is risky, because it makes certificate verification code much more complex, increasing probability of nasty security bugs (beyond just memory safety). Also, it makes the server Certificate message bigger, and that message is in the best place to hurt performance. Also, the incentives look to be very wicked. As long as clients keep accepting classical certificates, there is incentive to keep using those. And until CRQC exists, that does not even hurt security. That is worse than SHA-1 to SHA-2 transition, where there was really no difference beyond client support (and that could be negotiated, but server support was poor). And yet that transition took over a decade, really ending only because browsers stopped accepting SHA-1 certificates. -Ilari ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 3:46 PM Watson Ladd wrote: > To be clear, in Denis's scenario Ebonia requires all servers to obtain > a cert from Honest Ahmed's > (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure > CA. Server operators who complain that this will break clients are > told that it will have a trust expression that currently isn't used, > but government inspectors will use it to see if the cert is installed. > Then in step 2 they use the number of certs issued to bolster the > argument for inclusion. I don't see how Trust Expressions isn't making > this scenario easier. > > Furthermore the decision to add a CA is multifacited and balances the > utility to subscribers against the security costs. I am on the record > as an advocate for aggressively swinging towards quantifying the > utility here: no one is entitled to get trusted just because they can > comply with the CA/B forum rules. The number of certs issued (and > hence servers covered) is part of the utility calculation. > Step 2 in this scenario is not actually a compelling argument for the root program, precisely because of certification negotiation. To expand on this a bit: Adding a CA means trusting their (unpredictable) future actions. So, yes, each trusted CA carries some risk. The role of a root program is to make subjective judgments about this risk. And, yes, that means folks discuss things like "utility" to try to capture benefit vs risk tradeoffs of adding a CA. Users directly see compatibility issues, so it’s natural that folks talk about compatibility when thinking about this. It's then natural to think about these compatibility judgements being gamed or misrepresented, but this game-ability is why compatibility judgements are inherently problematic. They dilute the security-critical judgment (trustworthiness) with an unrelated one (popularity among sites, whose first-order incentives are availability, not CA trustworthiness). And yet these pressures are real *today*. Root programs are pressured *today* to trust widely-used CAs so that sites using them can work. Sure, the site could use a different CA, but every site operator will tell you CA changes are extremely difficult and risky. Convincing them to move is a difficult proposition. In contrast, the root program trusting a CA has zero compatibility risk, only security risk. It takes an egregious indication of untrustworthiness to offset those pressures, so the default is that users end up taking on security risk. Trust expressions fix the root problem here. There is a zero-compatibility-risk action available to the site operator: keep serving the old cert while adding a new one. Use by many servers, in a multi-certificate world, is no longer as compelling an argument to trust a root. By releasing this pressure valve, we give root programs more room to manage user security risk. This is even clearer in the above Ebonia scenario, the reason the server operators were willing to add that root by trust expressions was *because they could keep their existing certificate working*. Those servers then contribute *zero* compatibility pressure on the root program because their existing certificates work. A server would have to *only* serve the Ebonia root to contribute pressure. That's something they can already do today without trust expressions. (And are strongly incentivized against doing so for all usual compatibility reasons.) There isn't a step 2 here. We recently pushed a draft-03 with some text to capture this. The first addition discusses the above: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html#section-11.1-3 The second discusses the implications of serving a cert more generally, and is intended as a reference both for this discussion, and whenever anyone tries to convince a root program to trust an untrustworthy CA by virtue of an unrelated popularity contest. https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html#name-serving-multiple-certificat David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
