Skip to content

Commit

Permalink
Update draft-beck-tls-trust-anchor-ids.md
Browse files Browse the repository at this point in the history
Co-authored-by: Bob Beck <[email protected]>
  • Loading branch information
davidben and bob-beck authored Dec 17, 2024
1 parent bbea203 commit b2c5b79
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion draft-beck-tls-trust-anchor-ids.md
Original file line number Diff line number Diff line change
Expand Up @@ -483,7 +483,7 @@ This attack vector is available with or without trust anchor negotiation. The ne

As with other TLS parameters, negotiation reduces a conflict between availability and security, which allows PKIs to better mitigate security risks to users. When relying parties in an existing TLS ecosystem improve their certificate policies, trust anchor negotiation helps authenticating parties navigate differences between those relying parties and existing relying parties. Each set of requirements may be satisfied without compatibility risk to the other. {{use-cases}} discusses such scenarios in more detail.

Negotiation also reduces pressures on relying parties to sacrifice user security for compatibility. If a relying party does not trust an authenticating party's current CA, connections between the two will fail until either the relying party trusts the CA or the authenticating party uses a already trusted CA. If the authenticating party is limited to one certificate, switching CAs risks compatibility problems with other relying parties. The relying party then faces compatibility pressure to add this CA, even if it deems the CA a security risk. With trust anchor negotiation, the authenticating party can use its existing CA _in addition to_ another CA trusted by the relying party. This allows the ecosystem to improve interoperability without sacrificing user security.
Negotiation also reduces pressures on relying parties to sacrifice user security for compatibility. If a relying party does not trust an authenticating party's current CA, connections between the two will fail until either the relying party trusts the CA or the authenticating party uses an already trusted CA. Without trust anchor negotiation, the authenticating party is limited to one certificate, and therefore switching CAs risks compatibility problems with other relying parties. The relying party then faces compatibility pressure to add this CA, even if it deems the CA a security risk. With trust anchor negotiation, the authenticating party can use its existing CA _in addition to_ another CA trusted by the relying party. This allows the ecosystem to improve interoperability without sacrificing user security.

### Serving Multiple Certificates

Expand Down

0 comments on commit b2c5b79

Please sign in to comment.