On Thu, May 23, 2024 at 11:09 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote
> > > I think we have to agree that Trust Expressions enables websites to > adopt new CA chains regardless of client trust and even builds a > centralized mechanism for doing so. It is a core feature of the design. > > No one has to agree to this because you have not backed this claim at all. > Nick sent two long emails explaining why this was not the case, both of > which you have simply dismissed [...] > > This is something that I believe David Benjamin and the other draft > authors, and I all agree on. You and Nick seem to have misunderstood either > the argument or the draft. > > David Benjamin, writing on behalf of Devon and Bob as well: > > By design, a multi-certificate model removes the ubiquity requirement for > a trust anchor to be potentially useful for a server operator. > > [...] > > Server operators, once software is in place, not needing to be concerned > about new trust expressions or changes to them. The heavy lifting is > between the root program and the CA. > > From the Draft (Section 7): > > Subscribers SHOULD use an automated issuance process where the CA > transparently provisions multiple certification paths, without changes to > subscriber configuration. > > The CA can provision whatever chains it likes without the operator's > involvement. These chains do not have to be trusted by any clients. This is > a centralized mechanism which allows one party (the CA) to ship multiple > chains of its choice to all of its subscribers. This obviously has > beneficial use cases, but there are also cases where this can be abused. > Hi Dennis, Since you seem to be trying to speak on my behalf, I'm going to go ahead and correct this now. This is not true. I think you have misunderstood how this extension works. In fact, the extension with this property is the certificate_authorities extension, already standardized by the TLSWG, and with an even longer history as a non-extension field of the CertificateRequest message. At the end of the day, the TLS components of trust expressions are simply a more size-efficient form of the certificate_authorities field. The rest is working through the deployment implications to reduce server operator burden. However, the way we achieve this size efficiency is by *not* saying the CAs names. Instead, the CA sets are indirected through named and versioned "trust stores". However, the price one inherently needs to pay here is that servers need to know how to map from those trust stores back to the certificates. We solve this with the TrustStoreInclusionList metadata from the CA. That TrustStoreInclusionList structure is necessarily a point-in-time snapshot of the state of the world. If a root program has not included a CA yet, the CA cannot claim it in the metadata or connections will fail. If the CA is included in zero root programs, the only viable (i.e. correct and does not cause interop issues) TrustStoreInclusionList is the empty list, in which case the certificate will never be presented. If the root program were to add that CA later, the server *still will not send those certificates* to updated clients. It takes a new TrustStoreInclusionList from the CA for the certificate to be sent. We can (and must for interop) efficiently solve version skew for removals, hence the excluded_labels machinery. But version skew for additions requires saying *something* preexisting that names the CA. Now, if the client really, really wanted to trigger that certificate, it could do so today. It could send the name of the CA in the certificate_authorities extension. I wouldn't expect clients to want to waste bandwidth on this. Regardless, trust expressions has no involvement in that process, the tool you use there is the certificate_authorities extension. Now, _after_ a root program has made an addition, trust expressions' deployment model allows for reduced server operator burden as in the text you quoted, but at that point the CA has already been trusted. 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. Ultimately, the trustworthiness of CAs is a subjective social question: do we believe this CA has *and will continue* only sign true things? We can build measures to retroactively catch issues like Certificate Transparency, but the key question is fundamentally forward-looking. The role of a root program is to make judgement calls on this question. A root program that so misunderstands its role in this system that it conflates these two isn't going to handle its other load-bearing responsibilities either. David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
