28 Feb 2023
Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Ivan Ristić.
BROUGHT TO YOU BY OUR SPONSOR
Architecture
for Machine Identity Management.
What will your PKI look like when fast application development triggers an explosion of new machine identities?
Read this reference architecture to learn new strategies for orchestrating machine identities in data center,
cloud and edge environments. VENAFI
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.
This subscription is just for the newsletter; we won't send you anything else.
Here are some things that caught our attention since the previous newsletter:
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.