[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: > > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > wrote: >> >> Hi David, >> >> The certification chains issued to the server by the CA comes tagged with a >> list of trust stores its included in. The named trust stores are completely >> opaque to the server. These chains and names may not be trusted by any >> client nor approved by any server, they are issued solely by the CA as >> opaque labels. These chains sit on the server and will not be used unless a >> client connects with the right trust store label but obviously can easily be >> scanned for by anyone looking to check how pervasively deployed the >> alternate trust store is. >> >> Do you dispute any part of that? Most of what you wrote went off on a >> completely different tangent. >> >> Of course, whether this property (whether servers can usefully pre-deploy >> not-yet-added trust anchors), which trust expressions does not have, even >> matters boils to whether a root program would misinterpret availability in >> servers as a sign of CA trustworthiness, when those two are clearly >> unrelated to each other. >> >> Again, my primary concern here is not around the behavior of individual root >> stores, this is not relevant to the concern I'm trying to communicate to >> you. I know folks from all of the major root stores have great faith in >> their judgement and technical acumen. >> >> My concern is that Trust Expressions upsets a fragile power balance which >> exists outside of the individual root stores. There is an eternal war >> between governments pushing to take control of root stores and the security >> community pushing back. This battle happens in parliaments and governments, >> between lawmakers and officials, not within root stores and their individual >> judgement largely does not matter to this war. The major advantages we as >> the security community have today are that: >> >> a) These attempts to take control for surveillance are nakedly obvious >> to the local electorate because crappy domestic roots have no legitimate >> purpose because they can never achieve any real adoption. >> >> b) If a root store were to bow to pressure and let in a root CA used for >> interception, every other country has an interest in preventing that. An >> international WebPKI means that we are either all secure, or all insecure, >> together. >> >> Trust Expressions, though intended to solve completely different problems, >> will accidentally eradicate both of these advantages. Firstly, it provides a >> nice on ramp for a new domestic trust store, mostly through the negotiation >> aspect but also through the CA pre-distribution. Secondly, by enabling >> fragmentation along geographic boundaries whilst maintaining availability of >> websites. Without Trust Expressions, we cannot balkanize TLS. With Trust >> Expressions, we can and we know people who want to (not anyone in this >> thread). >> >> If you still do not understand this wider context within which all of our >> work sits, I do not think further discussion between you and I is going to >> help matters. >> >> I would suggest we focus our discussion on the use cases of Trust >> Expressions and how exactly it would work in practice - these concerns I >> shared earlier in the thread are solely technical and operational and you >> and I might be able to make better progress towards a common understanding. >> >> Best, >> Dennis > > > Hi Dennis, > > I’m replying in this separate thread to respond to some of your comments and > responses around the risks related to Trust Expressions so that we can keep > the primary thread focused on the technical matters. First, let’s agree on > the facts of what Trust Expressions does. Trust Expressions makes it easier > to deploy new CAs. Specifically, it makes it easier for servers to use > certificate chains issued by new CAs. By trust expressions do we mean the extension, or the envisioned world where cert automation results in the CA provisioning multiple certificates to the server via ACME extensions? I don't see why a CA would send a cert from a competitor along with its own. This confusion is I think contributing to the rising temperatures, coming close to that of autoignition of IETF emails. > > Trust Expressions does not enable the use/adoption/deployment of new CAs > regardless of trust. It only does so for trusted CAs, whereby trusted I mean > the CA is in a client’s root store. David Benjamin explains [1] this in > detail in his latest reply. If you permit me to summarize what’s already been > said on the thread: At the time of certificate issuance, the CA provides the > web server with metadata (in the form of a TrustStoreInclusionList, section > 5.1 [2]) indicating which trust stores contain the root for that certificate > chain. When responding to a ClientHello that contains the trust_expressions > TLS extension, the server will only use T
[TLS]Re: TLS Trust Expressions risks
> > What point in this process depends on Trust Expressions - that is to say, > at what point does a browser decide that the government CA is acting > differently enough from the other CAs in its root store that it’s willing > to fragment or bifurcate its trust store, and after that point, how does > the politics play out that mandating this CA’s trust is still somehow > legitimate? I'll assert that many people consider eavesdropping by their own government to be legitimate, and eavesdropping by foreign governments to be illegitimate. The point at which a browser would need to make a decision about bifurcating its trust store or pulling out of a country, is the moment a government-controlled CA starts mis-issuing certificates. Without TE, browsers have no ability to bifurcate their trust store, and servers have no ability to support a bifurcated client base. So without TE, the decision must be to pull out of the country, as this is the only technically expedient solution which is acceptable to most people. With TE, browsers /can/ bifurcate their trust store, and servers /can/ support a bifurcated client base. So a decision to pull out of the country, rather than bifurcate, is simply malicious. It's also worth pointing out that the security benefits of TE (i.e., allowing rapid distrust of roots) come from gracefully handling client fragmentation that's the result of time-since-last-update, not fragmentation that's a result of different codebases. It may be worth thinking about how to rework the proposal to reflect that On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: > > > > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson 40dennis-jackson...@dmarc.ietf.org> wrote: > >> > >> Hi David, > >> > >> The certification chains issued to the server by the CA comes tagged > with a list of trust stores its included in. The named trust stores are > completely opaque to the server. These chains and names may not be trusted > by any client nor approved by any server, they are issued solely by the CA > as opaque labels. These chains sit on the server and will not be used > unless a client connects with the right trust store label but obviously can > easily be scanned for by anyone looking to check how pervasively deployed > the alternate trust store is. > >> > >> Do you dispute any part of that? Most of what you wrote went off on a > completely different tangent. > >> > >> Of course, whether this property (whether servers can usefully > pre-deploy not-yet-added trust anchors), which trust expressions does not > have, even matters boils to whether a root program would misinterpret > availability in servers as a sign of CA trustworthiness, when those two are > clearly unrelated to each other. > >> > >> Again, my primary concern here is not around the behavior of individual > root stores, this is not relevant to the concern I'm trying to communicate > to you. I know folks from all of the major root stores have great faith in > their judgement and technical acumen. > >> > >> My concern is that Trust Expressions upsets a fragile power balance > which exists outside of the individual root stores. There is an eternal war > between governments pushing to take control of root stores and the security > community pushing back. This battle happens in parliaments and governments, > between lawmakers and officials, not within root stores and their > individual judgement largely does not matter to this war. The major > advantages we as the security community have today are that: > >> > >> a) These attempts to take control for surveillance are nakedly > obvious to the local electorate because crappy domestic roots have no > legitimate purpose because they can never achieve any real adoption. > >> > >> b) If a root store were to bow to pressure and let in a root CA > used for interception, every other country has an interest in preventing > that. An international WebPKI means that we are either all secure, or all > insecure, together. > >> > >> Trust Expressions, though intended to solve completely different > problems, will accidentally eradicate both of these advantages. Firstly, it > provides a nice on ramp for a new domestic trust store, mostly through the > negotiation aspect but also through the CA pre-distribution. Secondly, by > enabling fragmentation along geographic boundaries whilst maintaining > availability of websites. Without Trust Expressions, we cannot balkanize > TLS. With Trust Expressions, we can and we know people who want to (not > anyone in this thread). > >> > >> If you still do not understand this wider context within which all of > our work sits, I do not think further discussion between you and I is going > to help matters. > >> > >> I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and
[TLS]Re: TLS Trust Expressions risks
> > In your latest message [5], I understand the context of governments > pushing for inclusion of certain roots with varying degrees of legitimacy. > I don’t see the on-ramp for CA pre-distribution being meaningfully > different with Trust Expressions compared to certificate_authorities. > Sorry, I meant to address this point as well. The difference between TE and the certificate_authorities extension, is that there's less widespread server support for the latter. You might compel a browser to bifurcate and advertise the certificate_authorities extension, but pushing out server-side support would be a substantial challenge. Not speaking for Google, but I believe their intention /is/ to put in the substantial work to make server-side TE support ubiquitous, such that it would be a minor ACME config change On Fri, May 24, 2024 at 4:00 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > What point in this process depends on Trust Expressions - that is to say, >> at what point does a browser decide that the government CA is acting >> differently enough from the other CAs in its root store that it’s willing >> to fragment or bifurcate its trust store, and after that point, how does >> the politics play out that mandating this CA’s trust is still somehow >> legitimate? > > > I'll assert that many people consider eavesdropping by their own > government to be legitimate, and eavesdropping by foreign governments to be > illegitimate. The point at which a browser would need to make a decision > about bifurcating its trust store or pulling out of a country, is the > moment a government-controlled CA starts mis-issuing certificates. Without > TE, browsers have no ability to bifurcate their trust store, and servers > have no ability to support a bifurcated client base. So without TE, the > decision must be to pull out of the country, as this is the only > technically expedient solution which is acceptable to most people. With TE, > browsers /can/ bifurcate their trust store, and servers /can/ support a > bifurcated client base. So a decision to pull out of the country, rather > than bifurcate, is simply malicious. > > It's also worth pointing out that the security benefits of TE (i.e., > allowing rapid distrust of roots) come from gracefully handling client > fragmentation that's the result of time-since-last-update, not > fragmentation that's a result of different codebases. It may be worth > thinking about how to rework the proposal to reflect that > > > On Fri, May 24, 2024 at 2:46 PM Watson Ladd wrote: > >> On Fri, May 24, 2024 at 2:16 PM Nick Harper wrote: >> > >> > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >> >> >> Hi David, >> >> >> >> The certification chains issued to the server by the CA comes tagged >> with a list of trust stores its included in. The named trust stores are >> completely opaque to the server. These chains and names may not be trusted >> by any client nor approved by any server, they are issued solely by the CA >> as opaque labels. These chains sit on the server and will not be used >> unless a client connects with the right trust store label but obviously can >> easily be scanned for by anyone looking to check how pervasively deployed >> the alternate trust store is. >> >> >> >> Do you dispute any part of that? Most of what you wrote went off on a >> completely different tangent. >> >> >> >> Of course, whether this property (whether servers can usefully >> pre-deploy not-yet-added trust anchors), which trust expressions does not >> have, even matters boils to whether a root program would misinterpret >> availability in servers as a sign of CA trustworthiness, when those two are >> clearly unrelated to each other. >> >> >> >> Again, my primary concern here is not around the behavior of >> individual root stores, this is not relevant to the concern I'm trying to >> communicate to you. I know folks from all of the major root stores have >> great faith in their judgement and technical acumen. >> >> >> >> My concern is that Trust Expressions upsets a fragile power balance >> which exists outside of the individual root stores. There is an eternal war >> between governments pushing to take control of root stores and the security >> community pushing back. This battle happens in parliaments and governments, >> between lawmakers and officials, not within root stores and their >> individual judgement largely does not matter to this war. The major >> advantages we as the security community have today are that: >> >> >> >> a) These attempts to take control for surveillance are nakedly >> obvious to the local electorate because crappy domestic roots have no >> legitimate purpose because they can never achieve any real adoption. >> >> >> >> b) If a root store were to bow to pressure and let in a root CA >> used for interception, every other country has an interest in preventing >> that. An international WebPKI means that we are eith
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 2:27 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > In your latest message [5], I understand the context of governments >> pushing for inclusion of certain roots with varying degrees of legitimacy. >> I don’t see the on-ramp for CA pre-distribution being meaningfully >> different with Trust Expressions compared to certificate_authorities. >> > > Sorry, I meant to address this point as well. The difference between TE > and the certificate_authorities extension, is that there's less widespread > server support for the latter. You might compel a browser to bifurcate and > advertise the certificate_authorities extension, but pushing out > server-side support would be a substantial challenge. Not speaking for > Google, but I believe their intention /is/ to put in the substantial work > to make server-side TE support ubiquitous, such that it would be a minor > ACME config change > The degree of server support is an important consideration. Even with ubiquitous server-side TE support and servers configured with both a ubiquitous chain and a government-issued chain, it seems to me this government push for use of their CA requires a change to server TLS stacks to prefer the government CA chain since both will match the client's advertised trust stores. Mandating this server behavior change seems to me like a heavier lift than just a minor config change. I don't have a good sense of how it compares to the difficulty of configuring a server stack to use the certificate_authorities extension. It appears that at least OpenSSL has support for the certificate_authorities extension ( https://github.com/openssl/openssl/issues/13453), though the application using OpenSSL needs to implement the certificate selection. With TE, I imagine that certificate selection will happen inside the TLS stack or a TE library closely tied to the TLS stack. I wonder if there are ways to make it harder for a server to choose the "bad" cert and easier to choose the "good" cert, but this seems like a social/political problem rather than a technical one. On Fri, May 24, 2024 at 2: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. > Sure, the Ebonian government could mandate that all servers get a cert from Honest Achmed, and provide a specific Ebonia trust store label for the servers to match against. However, the only time the server would use that cert chain is when the government inspectors send the Ebonian trust store label to check if the cert is installed. In step 2 when Ebonia uses the number of certs from Honest Achmed as part of their argument, it matters what that count is. Is it the number of certs issued, number of certs servers are "willing to use" (that's not very well defined), number of certs that servers are actually using? Of course Ebonia will choose whatever suits them best, but it also depends where that number came from and how it was obtained. For example, Ebonia can get a large number of certs issued by Honest Achmed without Trust Expressions by having Honest Achmed generate a cert for every cert it sees in CT logs (with the Honest Achmed leaf using the same public key as in the logged leaf certs so that they're technically usable by the server). I imagine if Ebonia tried to use that count of certificates issued as part of their argument for adoption, there would be outcry about how that volume of cert issuance is manufactured and meaningless. In the scenario where certs are issued and delivered to servers, but they only use them in response to the government inspectors (because those are the only clients that match, this volume of cert issuance to me seems similarly manufactured and meaningless. Maybe Trust Expressions makes that scenario ever so slightly easier, but it seems like this step requires manufacturing false demand/use that would be fairly clear to see is occurring and discount it when arguing against that claim. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
> > Even with ubiquitous server-side TE support and servers configured with > both a ubiquitous chain and a government-issued chain, it seems to me this > government push for use of their CA requires a change to server TLS stacks > to prefer the government CA chain since both will match the client's > advertised trust stores. Mandating this server behavior change seems to me > like a heavier lift than just a minor config change. > The part of the spec you quoted says: if multiple certs match, choose any. When TE is rendered in actual code, why do you assume that there will be no configurable or easily-gameable way to make sure the government CA always wins? On Fri, May 24, 2024 at 5:15 PM Nick Harper wrote: > > > On Fri, May 24, 2024 at 2:27 PM Brendan McMillion < > brendanmcmill...@gmail.com> wrote: > >> In your latest message [5], I understand the context of governments >>> pushing for inclusion of certain roots with varying degrees of legitimacy. >>> I don’t see the on-ramp for CA pre-distribution being meaningfully >>> different with Trust Expressions compared to certificate_authorities. >>> >> >> Sorry, I meant to address this point as well. The difference between TE >> and the certificate_authorities extension, is that there's less widespread >> server support for the latter. You might compel a browser to bifurcate and >> advertise the certificate_authorities extension, but pushing out >> server-side support would be a substantial challenge. Not speaking for >> Google, but I believe their intention /is/ to put in the substantial work >> to make server-side TE support ubiquitous, such that it would be a minor >> ACME config change >> > > The degree of server support is an important consideration. Even with > ubiquitous server-side TE support and servers configured with both a > ubiquitous chain and a government-issued chain, it seems to me this > government push for use of their CA requires a change to server TLS stacks > to prefer the government CA chain since both will match the client's > advertised trust stores. Mandating this server behavior change seems to me > like a heavier lift than just a minor config change. I don't have a good > sense of how it compares to the difficulty of configuring a server stack to > use the certificate_authorities extension. It appears that at least OpenSSL > has support for the certificate_authorities extension ( > https://github.com/openssl/openssl/issues/13453), though the application > using OpenSSL needs to implement the certificate selection. With TE, I > imagine that certificate selection will happen inside the TLS stack or a TE > library closely tied to the TLS stack. > > I wonder if there are ways to make it harder for a server to choose the > "bad" cert and easier to choose the "good" cert, but this seems like a > social/political problem rather than a technical one. > > On Fri, May 24, 2024 at 2: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. >> > > Sure, the Ebonian government could mandate that all servers get a cert > from Honest Achmed, and provide a specific Ebonia trust store label for the > servers to match against. However, the only time the server would use that > cert chain is when the government inspectors send the Ebonian trust store > label to check if the cert is installed. In step 2 when Ebonia uses the > number of certs from Honest Achmed as part of their argument, it matters > what that count is. Is it the number of certs issued, number of certs > servers are "willing to use" (that's not very well defined), number of > certs that servers are actually using? Of course Ebonia will choose > whatever suits them best, but it also depends where that number came from > and how it was obtained. For example, Ebonia can get a large number of > certs issued by Honest Achmed without Trust Expressions by having Honest > Achmed generate a cert for every cert it sees in CT logs (with the Honest > Achmed leaf using the same public key as in the logged leaf certs so that > they're technically usable by the server). I imagine if Ebonia tried to use > that count of certificates issued as part of their argument for adoption, > there would be outcry about how that volume of cert issuance is > manufactured and meaningless. In the scenario where certs are issued and > delivered to servers, but they only use them in response to the government > inspectors (because those are the only clients that match, this volume of > cert issua
[TLS]Re: TLS Trust Expressions risks
On Fri, May 24, 2024 at 4:15 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > The part of the spec you quoted says: if multiple certs match, choose any. > When TE is rendered in actual code, why do you assume that there will be no > configurable or easily-gameable way to make sure the government CA > always wins? > I'm not assuming there will be no configurable or easily-gameable way to do this - I don't know what exactly that will look like in implementations. I'm asserting that TE alone as currently specified is insufficient for this attack, because TE says "choose any" and the attack needs to choose a specific one. ___ 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 5:18 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > Even with ubiquitous server-side TE support and servers configured with >> both a ubiquitous chain and a government-issued chain, it seems to me this >> government push for use of their CA requires a change to server TLS stacks >> to prefer the government CA chain since both will match the client's >> advertised trust stores. Mandating this server behavior change seems to me >> like a heavier lift than just a minor config change. >> > > The part of the spec you quoted says: if multiple certs match, choose any. > When TE is rendered in actual code, why do you assume that there will be no > configurable or easily-gameable way to make sure the government CA > always wins? > Since the server is free to apply whatever logic (random, smallest number of bytes on the wire, secret government coercion) it likes to pick from multiple matches, If what the government intends is to *always* have the paths matching a particular trust expression chosen on a multiple match, the server software needs to be either gamed, or complicit in making that happen, or it will not happen reliably. (either that or the client needs to be mandated to be modified to simply try with only the desired "bad" trust first, and then if it doesn't work silently reconnect with the "good" trust to work with the rest of the world - which can happen without trust expressions perfectly fine, and is a trick clients have used before for things like, SHA1 deprecation. I don't believe this is in any way different than a server supporting https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 (which says the list should be used as "guidance" and leaves it up to the implementer - maybe the list is in a priority order like key shares, maybe it is not?) While I am not convinced that this is a real risk for surveillance issues that is not already present, as already outlined in our previous replies, If the community at large truly believes that this is a real risk worthy of design work to mitigate, then this should probably also be addressed in 8446 at the same time. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS Trust Expressions risks
Hiya, (I'm currently on travel so just dipping into this thread, but...) On 24/05/2024 19:15, Nick Harper wrote: I’m replying in this separate thread to respond to some of your comments and responses around the risks related to Trust Expressions so that we can keep the primary thread focused on the technical matters. The risks related to abuse of protocols are technical matters. It is true that we have not paid sufficient attention to those risks in the past, but we really should know better by now. On 24/05/2024 22:00, Brendan McMillion wrote: > I'll assert that many people consider eavesdropping by their own > government to be legitimate, I'll assert that many people do not consider the above legitimate, if done at scale, without court-orders etc. etc. BCP188 does not have any local-government exception so if it's the case that this draft makes such local snooping easier, then that seems like a major negative to me. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
