> > 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 <nhar...@nharper.org> 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 <watsonbl...@gmail.com> 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
