[TLS]I-D Action: draft-ietf-tls-tls13-pkcs1-01.txt
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]Re: Dnsdir early review of draft-ietf-tls-svcb-ech-01
Submitted new revision: https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-02 Only change is adding the text to Security Considerations as discussed above. Erik On Wed, Apr 10, 2024 at 9:14 AM Sean Turner wrote: > Ted & ErikN, > > So it looks like ErikN submitted the following PR and ekr approved: > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1 > > If we have resolved your comments, can I ask on of the authors to spin a > new version and we can look to move this I-D. > > Also, could I kindly ask you to revise your review to change to “ready” > and maybe refer to thread: > https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/ > > spt > > > On Mar 30, 2024, at 19:17, Eric Rescorla wrote: > > > > > > > > On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon wrote: > > Encrypted dns transport works if you can trust the provider you are > talking to. DNSSEC works even if you can’t. And if your provider is > trustworthy, DNSSEC validation of results acquired through this tunnel > should work. So it’s silly in this case to trust the tunnel—there’s no > upside to doing so other than avoiding a few signature verifications. > > > > I don't object to people doing DNSSEC validation of ECH records (though > AFAIK no major browser does so), but... > > > > 1. The resolver only gains a limited amount by forging the SVCB response > because the resolver already knows the domain name you are going to. This > does conceal (say) the ALPN, but that's usually less interesting than the > SNI. > > 2. If the authoritative domain is misconfigured, which is not unheard > of, then this can create resolution failures (this is true for A/, of > course). Probably not much of an issue for the big public recursives, but > can definitely be an issue if you are just talking to some locally-supplied > resolver. > > > > -Ekr > > > > > > Op za 30 mrt 2024 om 14:02 schreef Rob Sayre > > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren > wrote: > > > > An attacker who can prevent SVCB resolution can deny clients any > associated security benefits. > > > > Yes. > > > > A hostile recursive resolver can always deny service to SVCB queries, > but network intermediaries can often prevent resolution as well, even when > the client and recursive resolver validate DNSSEC and use a secure > transport. These downgrade attacks can prevent a client from being aware > that "ech" is configured which would result in the client sending the > ClientHello in cleartext. > > > > I think s/would/could/ here. > > > > I don't know if we want to write it, but doesn't using encrypted > transport DNS to an IP address avoid this problem? Like using 1.1.1.1 or > 8.8.8.8 etc. I know that raises centralization issues, but it does help > with this issue. > > > > thanks, > > Rob > > > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]I-D Action: draft-ietf-tls-svcb-ech-02.txt
Internet-Draft draft-ietf-tls-svcb-ech-02.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings Authors: Ben Schwartz Mike Bishop Erik Nygren Name:draft-ietf-tls-svcb-ech-02.txt Pages: 6 Dates: 2024-05-23 Abstract: To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-02.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-02 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]Re: WG Adoption for TLS Trust Expressions
I am joining this thread a bit late but have been following the discussion. I want to express my support for Trust Expressions and comment on a few points that have been made. First, the reality is that websites already have to support multiple certificates to accommodate both ECC and RSA. This is a common reality that will only become more pronounced with the advent of post-quantum cryptography. These certificates typically come from different CA hierarchies, as most customers prefer algorithm-pure chains. The complexity of this is managed by the server or certificate lifecycle management solution they use. For example, Caddy hides all of this from the operator. Therefore, arguments suggesting that this proposal adds complexity seem disconnected from the current operational reality. Regarding the concern about government-mandated adoption of root certificates, I also care deeply about this issue. This is why I am disappointed by the one-sided nature of the conversation. I see no mechanism in this proposal that bypasses operator consent, and while governments do and will continue to force operators to make changes not in their interest, this proposal doesn't change that reality. Continuing to focus on this issue in this way detracts from the more constructive discussions happening in this thread. The most compelling argument against Trust Expressions I see in the thread is the potential for fragmentation. However, the current conversation on this topic overlooks the existing fragmentation challenges faced by site operators. The primary concern I hear from these operators is the anxiety over changes related to cipher suites and certificates, fearing that these changes might inadvertently break services in exchange for security properties that their leadership isn’t asking for. Trust Expressions, in my view, offers a net-positive solution to this problem by allowing site operators to manage the trust anchor portion of this risk, which they cannot do effectively today. At the same time, we are seeing more embedded devices being deployed without long-term maintenance strategies, automatic updates, or mechanisms to manage root store lists. This makes the Web PKI less agile, and Trust Expressions provides a way to manage this reality. Basically, fragmentation is already a present issue and is worsening, making the web less agile. Even if these devices don’t adopt Trust Expressions, it still provides a way to serve a separate certificate to well-maintained clients. So, rather than ignoring the issue, this proposal acknowledges that reality and provides a structured way to manage it. I believe Trust Expressions addresses tangible problems faced by server operators today. While I support continued discussion, I am supportive of this proposal. Ryan Hurst On Thu, May 23, 2024 at 10:40 AM Watson Ladd wrote: > On Thu, May 23, 2024 at 12:42 PM David Benjamin > wrote: > > > > > 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. > > As the old saw goes "past performance is no guarantee of future > results, but it sure helps". Moreover root programs have to balance > the benefits of including a CA against the costs. One of those > benefits is the number of sites that use it. > > Sincerely, > Watson > > > > > David > > ___ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > > > -- > Astra mortemque praestare gradatim > > ___ > 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: WG Adoption for TLS Trust Expressions
On Thu, May 23, 2024 at 12:42 PM David Benjamin wrote: > > 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. As the old saw goes "past performance is no guarantee of future results, but it sure helps". Moreover root programs have to balance the benefits of including a CA against the costs. One of those benefits is the number of sites that use it. Sincerely, Watson > > David > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: WG Adoption for TLS Trust Expressions
Hi! Let’s clam it down some in this thread. Just a gentle reminder to keep it professional. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: WG Adoption for TLS Trust Expressions
On Thu, May 23, 2024 at 11:09 AM Dennis Jackson 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
[TLS]Re: WG Adoption for TLS Trust Expressions
Hi David, On 23/05/2024 14:07, David Adrian wrote: There is certainly a discussion to be had about how well Trust Expressions solves problems experienced by the HTTPS ecosystem and the Web PKI today. However, that requires moving past repeated, unsubstantiated claims about how Trust Expressions enables government surveillance, something has been repeatedly debunked by multiple people in this thread, all of whom are attempting to discuss in good faith. And yet, each time someone does this, you change the shape of your argument, claim there is more nuance that no one except you can see, and describe some easily debunked partial scenario that you believe to be worse. This is, politely, hogwash and a rather shabby attempt to portray this as a one-sided discussion. I have presented a single consistent argument about how Trust Expressions solves a key deployment challenge for parties trying to perform this kind of abuse. This argument has not changed over the course of the thread, as I noted in my latest reply to Nick, this was just a summary of the previous discussion. This argument has been supported by others in the thread, in particular by Stephen Farrell: Having read the draft and the recent emails, I fully agree with Dennis' criticisms of this approach. I think this is one that'd best be filed under "good try, but too many downsides" and left at that. Meanwhile, the four loudest voices who deny there are legitimate concerns around this proposal all work for the same team at Google and have announced their intent to prototype this technology already [1]. The majority of the participants in this thread have engaged with these discussions with curiosity and have yet to voice any conclusion. I am sure they will do so when they have made up their minds. My personal reading has been that folks who have engaged in the discussion would agree there is both reasonable concern about how effective T.E. is at solving the problems it claims to and that the risks of abuse cannot be dismissed as easily as the authors would like. It may be worth taking a step back, and considering if the people you have worked with for nearly a decade or more, and who have been instrumental in improving TLS over the years, have truly suddenly decided to pivot to attempting to backdoor mass surveillance through the IETF. I have noted throughout that this is a complex topic which reasonable people may disagree on. I have a great deal of respect for the authors who I know are acting out of genuine intent to improve the world. We simply disagree on whether the proposed design is likely to effective at solving the problems it sets out and how seriously it could be abused by others. A few replies relating to surveillance are inline. -dadrian > 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. Can you explain, specifically, the government and site action that you expect that will result in surveillance, keeping in mind that ACME _already_ allows the CA to provide a bundle of untrusted intermediates? What is the chain of events here? What are the actions you see taken by a government, a CA, site owners, and root programs? CA provided intermediates doesn't offer any long term transition without Trust Expressions. You could absolutely stuff the domestic CA in there on some short term basis, but you're never going to be able to take out the WebPKI recognized intermediate (for all the folks connecting without the domestic CA). As a resu
[TLS]Re: WG Adoption for TLS Trust Expressions
Hi Dennis, There is certainly a discussion to be had about how well Trust Expressions solves problems experienced by the HTTPS ecosystem and the Web PKI today. However, that requires moving past repeated, unsubstantiated claims about how Trust Expressions enables government surveillance, something has been repeatedly debunked by multiple people in this thread, all of whom are attempting to discuss in good faith. And yet, each time someone does this, you change the shape of your argument, claim there is more nuance that no one except you can see, and describe some easily debunked partial scenario that you believe to be worse. It may be worth taking a step back, and considering if the people you have worked with for nearly a decade or more, and who have been instrumental in improving TLS over the years, have truly suddenly decided to pivot to attempting to backdoor mass surveillance through the IETF. A few replies relating to surveillance are inline. -dadrian > 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, instead providing vague statements about adoption and how enabling quicker CA rollout might enable a bad CA to be rolled out, an argument that sounds suspiciously similar to "if we make HTTPS adoption easier, then bad people might use HTTPS". > This is incorrect. Governments have a wide range of incentives available to them to encourage adoption by websites, including simply making it a legal requirement. Currently, none of those incentives are strong enough to overcome the fact that the website would become simply inoperable without Trust Expressions. > Without Trust Expressions, web servers are locked into one certificate chain which needs to be widely trusted. With Trust Expressions, web servers can add arbitrary certificate chains regardless of client trust, and CAs are empowered to ship additional chains without the operator's consent. This makes it much easier to deploy a new CA regardless of trust. Neither the operator, not the client, needs to trust the new CA cert chain for it to be provisioned. Can you explain, specifically, the government and site action that you expect that will result in surveillance, keeping in mind that ACME _already_ allows the CA to provide a bundle of untrusted intermediates? What is the chain of events here? What are the actions you see taken by a government, a CA, site owners, and root programs? > Whilst having your domestic root CA ship in clients does enable surveillance, it's not especially useful when no websites use that root CA, so targets can tell when their connection is being intercepted. Governments therefore either have two choices: MiTM everything (a substantial hurdle to have passed into law) or compel adoption by websites of the domestic CA (so that MiTM certs blend in with real ones). This attack is possible right now. There are already domestic root CAs included in root stores. However, we have no reason to suspect that they are being used for MITM because of certificate transparency. And if they were being used for MITM, they would be removed by root programs (subject to legal requirements). Can you explain what you mean by "blend in", given that certificate transparency exists? In both MITM situations you describe above, the certificates would be logged and logging would be enforced by all major browsers except Firefox, thereby making MITM detectable and acting as a deterrent. Certainly, CT does not prevent malicious issuance, however we already accept that risk today. Any CA, domestic or not, could be breached, compelled to issue maliciously, or simply decide to misbehave, however that action would have to be disclosed if they wanted to target any users besides Firefox users. On Thu, May 23, 2024 at 7:15 AM Dennis Jackson wrote: > Hi Nick, > > I think the issues around risk have a great deal of nuance that you're not > appreciating, but which I've tried to lay out below. I appreciate that > rational reasonable people can absolutely disagree on how they weigh up > these risks, but 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. > > On the issues around benefit, you've repeated the high level talking > points around PQ, adopting new CAs and supporting older devices, but these > talking points don't pan out on closer inspection. > > The central problem is that whilst Trust Expressions introduces a > negotiation mechanism at the TLS layer, it is only moving the pain up the > stack, without actually solving anything. To actually solve these problems,
[TLS]Re: WG Adoption for TLS Trust Expressions
Hi Nick, I think the issues around risk have a great deal of nuance that you're not appreciating, but which I've tried to lay out below. I appreciate that rational reasonable people can absolutely disagree on how they weigh up these risks, but 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. On the issues around benefit, you've repeated the high level talking points around PQ, adopting new CAs and supporting older devices, but these talking points don't pan out on closer inspection. The central problem is that whilst Trust Expressions introduces a negotiation mechanism at the TLS layer, it is only moving the pain up the stack, without actually solving anything. To actually solve these problems, Trust Expressions envisages that either website operators are doing a complex dance with multiple CAs to enable the universal compatibility they already enjoy today or that new CAs are forming business relationships with incumbent CAs, identically as they would for a cross sign. In both cases, we're adding a lot more complexity, fragmentation and pain, for no actual return. A detailed response is inline below. Best, Dennis On 22/05/2024 07:28, Nick Harper wrote: The second way this could happen is that the government compels a browser to add a CA to their root store regardless of whether it complies with root store policy, implicitly stating that this CA will misissue certificates. The browser's choice is to comply or leave the market. Until this new CA is in a trust store advertised by clients, there's no incentive for server operators to get a certificate issued by that CA, as there are no clients for it to present that cert to. This is incorrect. Governments have a wide range of incentives available to them to encourage adoption by websites, including simply making it a legal requirement. Currently, none of those incentives are strong enough to overcome the fact that the website would become simply inoperable without Trust Expressions. Thus, server adoption is no factor in the government's pressure to compel a browser to add their CA, and I see the same probability of this being successful as in the current state of the world without Trust Expressions. The conclusion that server adoption has no role in government pressure doesn't follow from any of the argument that you made and is in any case, wrong. Government capability to compel browsers is fundamentally one of legitimacy. In democracies, this usually plays out in debates between elected lawmakers who will either support or oppose new legislation impacting browsers. Website adoption is absolutely a factor in this debate. "A large fraction of our domestic websites have adopted our new domestic certificates, but American browsers refuse to trust them leaving us dependent on foreign infrastructure" is a much more powerful argument than "we made a new CA that no one uses, pretty please can we force browsers to trust it". A substantial issue that you didn't pick up on is how Trust Expressions changes government incentives to perform this kind of mass surveillance. Whilst having your domestic root CA ship in clients does enable surveillance, it's not especially useful when no websites use that root CA, so targets can tell when their connection is being intercepted. Governments therefore either have two choices: MiTM everything (a substantial hurdle to have passed into law) or compel adoption by websites of the domestic CA (so that MiTM certs blend in with real ones). This latter path is substantially easier from the perspective of lawmaking and is only possible with Trust Expressions (otherwise the adopting sites would become inaccessible. As noted earlier in the thread, this approach with Trust Expressions also scales nicely, allowing many countries to do this in parallel with the website using the domestic CA of each one. > The real problem here is that you've > (accidentally?) built a system that makes it much easier to adopt and > deploy any new CA regardless of trust, rather than a system that makes > it easier to deploy & adopt any new *trusted* CA. I disagree that it makes it easier to adopt and deploy a new CA *regardless of trust*. Trust Expressions only makes it easier to deploy a CA that is in a trust store advertised by clients. If a CA is in a client's trust store, that to me sounds like a *trusted CA*. Without Trust Expressions, web servers are locked into one certificate chain which needs to be widely trusted. With Trust Expressions, web servers can add arbitrary certificate chains regardless of client trust, and CAs are empowered to ship additional chains without the operator's consent. This makes it much easier to deploy a new CA regardless of trust. Neither the operator, not the client, needs to trust the new CA c
