Cite draft-ietf-tls-cert-abridge instead of the older one

Datatracker metadata was missing, so I missed this.

draft-davidben-tls-trust-expr.md

@@ -722,7 +722,7 @@ In many PKIs today, root CAs issue certificates to intermediate CAs which, in tu
 
 However, this comes at a size cost: the certification path, sent in the TLS handshake, includes an extra certificate. This is an extra public key and signature, as well as extra copies of X.509 metadata. (An average X.509 name in the Chrome Root Store {{CHROME-ROOTS}} or Mozilla CA Certificate Program {{MOZILLA-ROOTS}} is around 100 bytes, despite largely being an opaque identifier in modern usage.) Post-quantum signature algorithms shift this tradeoff dramatically. Dilithium3 {{Dilithium}}, for example, has a total public key and signature size of 5,245 bytes.
 
-{{?I-D.jackson-tls-cert-abridge}} proposes to predistribute known intermediate certificates to relying parties, as a compression scheme. A multi-certificate deployment model provides another way to achieve this effect. To relying parties, a predistributed intermediate certificate is functionally equivalent to a root certificate. PKIs use intermediate certificates because changing root certificates requires updating relying parties, but predistributed intermediates already presume updated relying parties.
+{{?I-D.ietf-tls-cert-abridge}} proposes to predistribute known intermediate certificates to relying parties, as a compression scheme. A multi-certificate deployment model provides another way to achieve this effect. To relying parties, a predistributed intermediate certificate is functionally equivalent to a root certificate. PKIs use intermediate certificates because changing root certificates requires updating relying parties, but predistributed intermediates already presume updated relying parties.
 
 A CA operator could provide subscribers with two certification paths: a longer path ending at a long-lived trust anchor and shorter path the other ending at a short-lived, revocable root. Relying parties would be configured to trust both the long-lived root and the most recent short-lived root. The negotiation mechanism in {{tls-certificate-negotiation}} would then send the shorter path to up-to-date relying parties, and the longer path to older relying parties.