Tighten up the introductory text a bit (#71)

* Tighten up the introductory text a bit

* Fixups

* Fix link in other markdown flavor

draft-beck-tls-trust-anchor-ids.md

@@ -111,30 +111,29 @@ Additionally, to support TLS clients with many trusted certification authorities
 
 # Introduction
 
-TLS {{!RFC8446}} endpoints typically authenticate using X.509 certificates {{!RFC5280}}. These are assertions by a certification authority (CA) that associate a TLS key with DNS names or other identifiers. If the peer trusts the CA, it will accept this association. The authenticating party (usually the server) is known as the *subscriber* and the peer (usually the client) is the *relying party*.
+TLS {{!RFC8446}} authentication uses X.509 certificates {{!RFC5280}} to associate the authenticating party's, or *subscriber's*, TLS key with its application identifiers, such as DNS names. These associations are signed by some certificate authority (CA). The peer, or *relying party*, curates a set of CAs that are trusted to only sign correct associations, which allows it to rely on the TLS to authenticate application identifiers. Typically the subscriber is the server and the relying party is the client.
 
-{{Section 4.2.4 of RFC8446}} defines the `certificate_authorities` extension, which allows the subscriber, who may have multiple certificates available, to select the correct certificate for the relying party. However, this extension’s size is impractical for some applications.
+A single subscriber may need to interoperate with relying parties that trust different sets of CAs. {{Section 4.2.4 of RFC8446}} defines the `certificate_authorities` extension to accommodate this. It allows the subscriber to provision multiple certificates and select the one that will allow the relying party to accept its TLS key. This is analogous to parameter negotiation elsewhere in TLS.
 
-Without such a negotiation mechanism, the subscriber must somehow obtain certificates which simultaneously satisfy all relying parties. This is a challenge for subscribers when relying parties are diverse. This translates to analogous challenges for CAs and relying parties:
+However, `certificate_authorities`'s size is impractical for some applications. Existing PKIs may have many CAs, and existing CAs may have long X.509 names. As of August 2023, the Mozilla CA Certificate Program {{MOZILLA-ROOTS}} contained 144 CAs, with an average name length of around 100 bytes. Such TLS deployments often do not use trust anchor negotiation at all.
 
-* For a new CA to be usable by subscribers, all relying parties must trust it. This is particularly challenging for older, un-updatable relying parties. Existing CAs face similar challenges when rotating or deploying new keys.
+Without a negotiation mechanism, the subscriber must obtain a single certificate that simultaneously satisfies all relying parties. This is challenging when relying parties are diverse. PKI transitions, including those necessary for user security, naturally lead to relying party diversity, so the result is that service availability conflicts with security and overall PKI evolution:
 
-* When a relying party must update its policies to meet new security requirements, it must choose between compromising on user security or imposing a significant burden on subscribers that still support older relying parties.
+* For a subscriber to use a CA in its single certificate, all supported relying parties must trust the CA. PKI transitions then become difficult when subscribers support older, unupdated relying parties. This impacts both new keys from existing CA operators and new CA operators.
 
-The `certificate_authorities` extension’s size becomes impractical due to two factors. First, X.509 names are large. Second, many clients, notably web browsers, trust a large number of CAs. As of August 2023, the Mozilla CA Certificate Program {{MOZILLA-ROOTS}} contained 144 CAs, with an average name length of around 100 bytes. This document introduces Trust Anchor Identifiers, which aims to address both of these challenges.
+* When a relying party must update its policies to meet new security requirements, it adds to relying party diversity and the challenges that subscribers and CAs face. The relying party must then choose between compromising on user security or burdening the rest of the ecosystem, potentially impacting availability in the process.
 
-There are four parts to this mechanism:
+To address this, this document introduces Trust Anchor Identifiers. There are four parts to this mechanism:
 
 1. {{trust-anchor-ids}} defines *trust anchor identifiers*, which are short, unique identifiers for X.509 trust anchors.
 
-
 2. {{tls-extension}} defines a TLS extension that communicates the relying party’s requested trust anchors, and the subscriber’s available ones. When the relying party is a TLS client, it can mitigate large lists by sending a, possibly empty, subset of its trust anchors to the TLS server. The server provides its list of available trust anchors in response so that the client can retry on mismatch.
 
 3. {{dns-service-parameter}} allows TLS servers to advertise their available trust anchors in HTTPS or SVCB {{!RFC9460}} DNS records. TLS clients can then request an accurate initial subset and avoid a retry penalty.
 
 4. {{acme-extension}} defines an ACME {{!RFC8555}} extension for provisioning multiple certification paths, each with an associated trust anchor identifier.
 
-Together, they extend the `certificate_authorities` mechanism to a broader set of applications, enabling a more flexible and robust PKI.
+Together, they reduce the size costs of trust anchor negotiation, supporting flexible and robust PKIs for more applications.
 
 # Conventions and Definitions
 

explainer.md

@@ -2,7 +2,7 @@
 
 This document is a high-level overview and [explainer](https://tag.w3.org/explainers/) for [TLS Trust Anchor Identifiers](https://davidben.github.io/tls-trust-expressions/draft-beck-tls-trust-anchor-ids.html) and [TLS Trust Expressions](https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html). While they differ in approach, both mechanisms aim to allow the server to select certificates based on the client's trusted CAs. We refer to overall problem being solved as "trust anchor negotiation".
 
-The two drafts apply to both TLS server certificates, where the server authenticates to the client, and TLS client certificates, where the client authenticates to the server. The two cases use similar protocol mechanisms, but their PKIs are often structured differently. As most of the motivating scenarios are drawn from server certificate deployments, this explainer focuses on those roles.
+The two drafts apply to both TLS server certificates, where the server authenticates to the client, and TLS client certificates, where the client authenticates to the server. The two cases use similar protocol mechanisms, but their PKIs are often structured differently. As most of the motivating scenarios are drawn from server certificate deployments, this explainer primarily focuses on those roles, but most of it applies analogously to client certificates.
 
 ## Authors
 
@@ -17,40 +17,33 @@ The two drafts apply to both TLS server certificates, where the server authentic
 
 ## Introduction
 
-[TLS](https://www.rfc-editor.org/rfc/rfc8446) endpoints typically authenticate using [X.509 certificates](https://www.rfc-editor.org/rfc/rfc5280). These are used as assertions by a certification authority (CA) that associate some TLS key with some DNS name or other identifier. If the peer trusts the CA, it will accept this association. The authenticating party (usually the server) is known as the *subscriber* and the peer (usually the client) is the *relying party*.
+[TLS](https://www.rfc-editor.org/rfc/rfc8446) uses [X.509 certificates](https://www.rfc-editor.org/rfc/rfc5280) to associate the authenticating party's, or *subscriber's*, TLS key with its application identifiers, such as DNS names. These associations are signed by some certificate authority (CA). The peer, or *relying party*, curates a set of CAs that are trusted to only sign correct associations, which allows it to rely on the TLS to authenticate application identifiers. Typically the subscriber is the server and the relying party is the client.
 
-Today, subscribers typically provision a single certificate for all supported relying parties, because relying parties do not communicate which CAs are trusted. We call this a *single-certificate deployment model*. In this model, the single certificate must simultaneously satisfy all relying parties.
+A single subscriber may need to interoperate with relying parties that trust different sets of CAs. TLS 1.3 defines the [`certificate_authorities` extension](https://www.rfc-editor.org/rfc/rfc8446#section-4.2.4) to accommodate this. It allows the subscriber to provision multiple certificates and select the one that will allow the relying party to accept its TLS key. This is analogous to parameter negotiation elsewhere in TLS.
 
-This constraint imposes costs on the ecosystem as PKIs evolve over time. The older the relying party, the more its requirements may have diverged from newer ones, making it increasingly difficult for subscribers to support both. This translates to analogous costs for CAs and relying parties:
+However, `certificate_authorities`'s size is impractical for some applications. Existing PKIs may have many CAs, and existing CAs may have long X.509 names. As of August 2023, the [Mozilla CA Certificate Program](https://wiki.mozilla.org/CA/Included_Certificates) contained 144 CAs, with an average name length of around 100 bytes. Such TLS deployments often do not use trust anchor negotiation at all.
 
-* For a new CA to be usable by subscribers, it must be trusted by all relying parties. This is particularly challenging for older, unupdatable relying parties. Existing CAs face similar challenges when rotating or deploying new keys.
+Without a negotiation mechanism, the subscriber must obtain a single certificate that simultaneously satisfies all relying parties. This is challenging when relying parties are diverse. PKI transitions, including those necessary for user security, naturally lead to relying party diversity, so the result is that service availability conflicts with security and overall PKI evolution:
 
-* When a relying party must update its policies to meet new security requirements, it must choose between compromising on user security or imposing a significant burden on subscribers that still support older relying parties.
+* For a subscriber to use a CA in its single certificate, all supported relying parties must trust the CA. PKI transitions then become difficult when subscribers support older, unupdated relying parties. This impacts both new keys from existing CA operators and new CA operators.
 
-The two drafts aim to remove this constraint, by enabling a *multi-certificate deployment model*. Subscribers are instead provisioned with multiple certificates and automatically select the correct one to use with each relying party. This allows a single subscriber to use different certificates for different relying parties, including older and newer ones.
+* When a relying party must update its policies to meet new security requirements, it adds to relying party diversity and the challenges that subscribers and CAs face. The relying party must then choose between compromising on user security or burdening the rest of the ecosystem, potentially impacting availability in the process.
 
-There are three parts to understanding this proposal:
-
-1. The multi-certificate model itself
-2. A TLS extension for relying parties to succinctly communicate trusted CAs
-3. An [ACME](https://www.rfc-editor.org/rfc/rfc8555.html) extension for provisioning multiple certificates
-
-Together, these aim to support a more flexible and robust Public Key Infrastructure (PKI).
+To address this, the two proposals extend the `certificate_authorities` extension to reduce the size cost, supporting flexible and robust PKIs for more applications. The proposals also define a supporting [ACME](https://www.rfc-editor.org/rfc/rfc8555.html) extension to help subscribers provision multiple certificates.
 
 ## Goals
 
-At a high level, the goal for TLS trust anchor negotiation is to enable a multi-certificate deployment model for TLS, particularly as used in HTTPS on the web.
+At a high level, the goal for these proposals is to *enable TLS servers to handle diversity in client trust, so that server availability does not conflict with PKI security and evolution*.
+
+In doing so, we aim to:
 
-Our goals in doing so are:
+* Enable PKIs to evolve as needed for user security, in a timely manner and without conflicting with availability.
+* Minimize burden to server operators, particularly avoiding ongoing manual work. Most ongoing decisions should instead come from TLS software, ACME client software, and ACME servers.
+* Minimize bandwidth cost to the TLS handshake.
 
-* PKIs can evolve over time, to meet user security needs, without conflicting with availability.
-* Subscribers can configure multiple TLS certificates, with TLS software automatically sending the right one on each connection.
-* As much as possible, minimize manual changes by server operators. Most ongoing decisions should instead come from TLS software, ACME client software, and ACME servers.
-* To achieve this, CAs, via automated protocols like ACME, can transparently provision subscribers with multiple TLS certificates.
-* Minimal bandwidth cost to the TLS handshake.
+Matching the standard pattern for other TLS parameters, we target a deployment model where subscribers can configure multiple TLS certificates, with TLS software automatically sending the right one on each connection. To aid in this, CAs can transparently provision subscribers with multiple TLS certificates with ACME or another automated protocol.
 
-We discuss the motivations for a multi-certificate deployment model in more
-depth below.
+We discuss these motivations in more depth below.
 
 ### Why Multiple Certificates?