CAA Expands into New Use Cases

Originally published in?Bulletproof TLS Newsletter, a free periodic newsletter designed to keep you informed about the latest developments in SSL/TLS and Internet PKI. Written by?Ivan Risti?.

Certification Authority Authorization (CAA) is a good example of a technology that’s slow and steady. Originally conceived in 2013 as?RFC 6844, it was adopted by the CA/Browser Forum and mandated for all CAs in?2017, and eventually brought to its current shape in 2019 as?RFC 8659. Although not perfect, it gets the job done, and support for it continues to grow.

If you’re not already familiar with CAA, in essence it’s a mechanism that enables domain owners to advertise a certificate issuance policy, in effect controlling which CAs are allowed to issue certificates for their properties. It builds on top of DNS and relies on a new resource record type.

The original form of CAA has been extended to satisfy two additional use cases. First, the CA/Browser Forum added the?contactemail?and?contactphone?extensions to enable policies to communicate contact information for those in charge of certificate issuance.

Separately, the ACME Working Group realized that there wasn’t enough permission granularity in the original CAA design. To remedy that, the group added the?accounturi?extension to enable targeting specific customer accounts within CAs, thus reducing the attack surface even further. They also added the?validationmethods?extension to control which validation methods can be used for certificate issuance. This can be useful, for example, if you want to centralize issuance using only DNS validation methods. For the documentation, refer to?RFC 8657. These extensions are not yet mandated by CA/Browser Forum, which means that CAs don’t have to support them. However, that’s not necessarily terrible, because you only need them to be supported by the CA you’re using. Let’s Encrypt supports the extensions as of?December 2022. You can read more about that in?an article on Hugo Landau’s website.

But that’s not all. There are several new efforts in progress to adapt CAA to support additional functionality and certificate types.

For example, BIMI is a recent effort to bring company logos to email. This standard, currently in the early stages of deployment, relies on CAA and the new?issuevmc?property?to control issuance of Verified Mark Certificates.

More recently, the Limited Additional Mechanisms for PKIX and SMIME (LAMPS) Working Group?voted?to adopt a?new RFC, one that specifies a new property called?issuemail, which controls issuance of S/MIME certificates.

Finally, it’s very early, but there is interest in expanding CAA so that it can control issuance of certificates bound to IP addresses. The IETF mailing list recently received a?message from Antonios Chariton, who’s working on a draft of the new specification.

Short news

Here are some things that caught our attention since the previous newsletter:

• Luxemburk and ?ejka published their work in the field of encrypted traffic classification in an article titled “Fine-Grained TLS Services Classification with Reject Option.”
• Tanya Verma wrote about Cloudflare’s work on?Geo Key Manager v2, which is designed to support control of distribution of private keys by geographic location.
• Neil Madden appeared on the?Cryptography FM #23?podcast to discuss Java’s?Psychic Signatures?(last year’s discoveries about botched ECDSA signing).
• In his blog post titled “Never DIY Your PKI,” J. Hunter Hawke talks about why building your own PKI is too much work.
• GitHub suffered a security breach, with?three of its code-signing certificates compromised. However, the certificates were password protected, which prevented malicious use.
• The Calgary Internet Exchange (YYCIX)?deployed ASPA filtering on a public peering fabric. The YYCIX Route Servers drop ASPA-invalid BGP routes in order to protect multilateral peers.
• NIST?announced FIPS 186-5, which, for the first time, allows the use of the Edwards Curve Digital Signature Algorithm (EdDSA).
• The?Open Source Cryptography Workshop?is taking place on March 30, 2023, in Tokyo, the day after the?Real World Cryptography?(RWC) symposium. Registration for RWC is now open.
• OpenSSL patched?several vulnerabilities, the most severe one marked High.
• Chrome developers announced that they will?deprecate and remove the block-all-mixed-content CSP directive, which is rarely used these days.
• The Sigstore project’s blog included a post about?the project’s work securing the Java ecosystem. Sigstore released its production for?Python in January 2023, offering a new effort to digitally secure the software component supply chain.
• Wladimir Palant investigated the curious case of?South Korean banks installing their own root CA certificates?onto customers’ computers.
• Shikhar Gupta wrote about?bypassing certificate pinning on Android?in a blog post.
• Chrome continues to vary its TLS handshake?with TLS extension permutation. These changes are an effort to defeat fingerprinting and ecosystem ossification.
• NIST selected the Ascon family?in its lightweight cryptography competition and standardization.
• Frank Denis compiled?OpenSSL 3 for WebAssembly.
• Neil Madden reviewed?The Joy of Cryptography, a free book by Mike Rosulek of Oregon State University.
• The Brave Privacy Team wrote about Brave’s efforts to?always use HTTPS when it’s available.
• A post on Elttam’s blog discussed its research into?practical exploitation of weak (noncryptographic) random number generators in Java.
• Mike Malone wrote a blog post about?using short-lived certificates?to avoid having to deal with revocation.
• Mammoth, one of the oldest CT logs, run by Sectigo,?reached the end of its life?after?suffering an availability incident?that exceeded the allowed downtime.
• Andrew Ayer released a new tool called?CRL Watch, which highlights CA operators with CRL delivery problems.