On Fri, May 24, 2024 at 2:16 PM Nick Harper <nhar...@nharper.org> wrote: > > On Fri, May 24, 2024 at 10:14 AM Dennis Jackson > <ietf=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 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 Trust Expressions if it has a > certificate chain that at issuance time matched one of the client’s > TrustStores. Trust Expressions only enables the deployment of certs from a > new CA if that CA is trusted by a client when the CA sends the subscriber the > TrustStoreInclusionList alongside the certificate chain. The client has to > trust the CA before Trust Expressions enables use of a new CA, hence it only > enables new CAs that are trusted. If the CA makes up its own trust store > label to use for deployment, clients would have to be compelled to advertise > that trust store label for this “pre-distribution” of certificates to have > any use. 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. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
