Issuance Auditability: Certificate Validation Methods
With great power, comes even greater transparency requirements
We can describe Certificate Issuance as the process of encoding attested and validated information about a subject into a document and then cryptographically signing that document. When that subject presents the certificate to others who trust the certificate’s signer, they can be reasonably certain that the data included in the certificate is valid.
Data Encoded and Asserted in Certificates
The data included in a certificate can be split into two categories:
Data that the subject wanted to be attested and included in the certificate. For example: the DNS name of a website, the country of an organization, etc.
Data that the issuer had access to at the time of certificate issuance. For example: the Signed Certificate Timestamp (SCTs, used in Certificate Transparency).
First, let’s describe one view of an ideal world. In this world, everyone has access to the internet with faster-than-light latency, and reasonable bandwidth. In this world, we’d mandate the CAs include every single bit of information they had access to when issuing a certificate. For example:
The validation logs (e.g. if DNS domain control validation was used, then the entire DNS request/response dump).
The SBOM of the issuing software.
The network logs for CAA checking.
Etc.
Why don’t we do this today? Large certificates would be a choke point for much of the internet. We don’t want to send any data to a website until we’ve received (and validated) the website’s certificate, as it can lead to us leaking private information included in our data. Even today, we send too much information in plaintext to establish an HTTPS connection. Fortunately, the Encrypted Client Hello proposal aims to fill most of that gap.
Unfortunately, we haven’t (yet) figured out a way to have faster-than-light internet latency, and most people don’t have access to “good” internet service. So we need to make compromises about the data we end up including in a certificate.
In another vision of an ideal world, Certificate Issuance is something that is completely automated and there are effectively no humans involved in the process. Even though this ideal world is significantly easier to achieve than the world envisioned above, we’re unfortunately many steps away from this.
Data Inclusion Litmus Test
Let’s define a “test” that checks if some data meets the bar of being included in a certificate.
Data that is included in a certificate should fall into one or more of these categories:
Values that a CA can “attest” about a subscriber.
Values that help a user agent (such as your browser) “validate” a subscriber.
Values that are important for general WebPKI security.
For example, the actual signature of the certificate.
Values that either help, or make it possible for the WebPKI community (Subscribers, Root Programs, Security Researchers, Certification Authorities, and the general public) to use automation to validate the behavior of a subscriber, a CA, or both.
Beyond these four categories, it is also important that this data follows all the following rules as well:
It must be useful to most relying parties in order to drive decisions on trust.
Should take the size of the encoded data into consideration.
A silly example: a full system dump of an issuance system would be useful for researchers, but is infeasible to include in X.509.
It serves a unique purpose not already addressed by other data within the certificate.
For example, there’s no reason to encode the expiration date in two different formats in a certificate.
It does not require a human to be involved to validate and attest the information.
Humans and security don’t mix together.
Should be information that the CA can be reasonably certain about at the time of issuance.
However, I must note a caveat regarding the last point: Certification Authorities cannot be reasonably certain about the data included in Extended Validation (EV) or Organization Validation (OV) certificates. This is one reason I believe EV and OV certificates should be deprecated, as they attempt to convey information that CAs cannot genuinely attest to. Furthermore, the inclusion of bits of data necessary for EV and OV provide no useful information for Relying Parties (other than maybe deny listing them :P)
The last criteria is crucial not only from a technical standpoint but also from a social perspective. We want to avoid repeating incidents like the British Post Office scandal, where flawed systems made invalid claims and caused significant injustice to the people involved.
Among all the data included in certificates today, realistically only one—the Signed Certificate Timestamps (SCTs)—is primarily there to aid in automated auditing (for example, SCT auditing is used in Chrome). Of course, other data encoded in the certificate can aid with auditing, but that is not the primary reason they were included.
That’s a lot of words to say: we need to consider encoding some data that the CA can attest to that will help the WebPKI community audit certificates and CAs.
Domain Validation Methods
Currently, there are 13 domain control validation methods that the baseline requirements permit:
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
Domain Contact is defined as: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
3.2.2.4.4 Constructed Email to Domain Contact
I think the label of this method in the BRs is incorrect. I’ve filed a bug for it.
An interesting domain validation method. Effectively allows you to get a certificate for a domain by proving control over the IP that the A/AAAA record of that domain points to.
I’m not entirely sure why this method is still permitted, I don’t have the data to know if anyone is using it, and it certainly is hard to reason about.
This is analogous to 3.2.2.5.3 Reverse Address Lookup in the IP address verification side of the BRs.
3.2.2.4.15 Phone Contact with Domain Contact
There’s possibly a bug here too.
The majority of certificate issuance on the web uses only a handful of these methods. For example, Let’s Encrypt only uses 3.2.2.4.7, 3.2.2.4.19, and 3.2.2.4.20.
Usually, incidents that require mass revocation from many CAs stem from a fundamental problem with a validation method. This has happened several times in the past: TLS-SNI-01, ALPN-TLS.
The outcome of these incidents is a mass revocation for all certificates issued with the impacted Domain Control Validation method. However, this raises a question: Can we verify that the CA hasn’t mistakenly or maliciously omitted certificates from being revoked?
Unfortunately, without relying on WebTrust Auditing (I promise I’ll write about my experiences with WebTrust Audits in the future, but for now you can take my word for it that they’re awful and don’t provide any meaningful security), there is no way we can verify these claims from a CA.
<StartRant>
I also want to take a moment to specifically point out that many of these validation methods should have been banned ages ago. There is absolutely no reason we should be doing domain control validation over phone calls, emails, fax (yes, fax!), or postal mail. The inclusion of these methods in ${CURRENT_YEAR} is baffling. I can't believe that both CAs and relying parties find these validation methods acceptable. I'd go as far as saying that every day the CA/B Forum delays in getting rid of these methods, they're doing a disservice to everyone and actively making the web a worse place for all of us. So I'll just end this rant with:
Chrome, Mozilla, Apple, and Microsoft Root Programs: please stop allowing the use of these broken validation methods.
No one should be proving control over a domain using a phone call.
<EndRant>
Let’s Encode the Domain Control Validation Method in the Certificate
Going back to the “Data Inclusion Litmus Test” defined above, including the domain control validation method in a certificate certainly passes that test.
The Domain Control Validation Method falls partially within the third, and fully within the fourth category. Furthermore, this value also passes the four rules to be included as well:
This value is useful for relying parties to drive trust. For example:
Apple Lockdown mode can use this data to limit “trusted certificates” only to certificates that are using known-automatable validation methods (e.g. ACME).
It allows for slow sunsetting of bad domain control validation methods by browsers.
This value increases the certificate size by a miniscule amount.
This value serves a unique purpose which is not already addressed by another value.
This value does not require a human to be involved to validate and attest the data.
This value is information that can be definitively asserted by the CA at the time of issuance.
The Watchtowr Report
You may not be convinced yet, so let’s take a look at what the watchtowr folks found a couple of days ago.
In this report, the watchtowr folks demonstrated an attack where, by taking over the WHOIS domain for the .mobi TLD, they were able to get a CA to issue a certificate for them under the 3.2.2.4.2 domain control validation method.
Once this report was made public, GlobalSign filed a preliminary incident report for this situation. However, many more CAs beyond GlobalSign are potentially (not yet confirmed, but they do rely on WHOIS based domain validation methods) impacted by this. If we had the Domain Control Validation method encoded in the certificate, it would be possible to find anomalous certificate issuance patterns for the impacted issuance methods across all CAs.
Beyond that, it would also make it possible for us to quickly confirm which CAs are impacted by this issue. To do this today, we’d need to read through every CA’s CPS document to find out if they use this method or not. These CPS documents are not always the best maintained (which is a whole problem in and of itself), and are hard to do proper analysis on.
Prior and Future Discussions
Unsurprisingly, this idea has been discussed in the past and will be discussed in the future. The past discussions are quite illuminating; a lot of bike-shedding happened in the thread I’ve linked, but I think Ryan Sleevi (once again) puts it perfectly:
I think it's framing the question wrong.
Understandably, some CAs will object to anything that allows clients to make more informed trust decisions. We've certainly seen this with opposition to Certificate Transparency, in the past. At the same time, we've seen four validation methods demonstrated as insecure. Two have been removed from the Forum (but with a grace period, allowing CAs to continue issue certificates despite knowing that information is not valid), while two are still permitted but which are forbidden by software vendors. We've also seen multiple CAs relying on cached domain validation information beyond the permitted window. We've seen browsers take steps to deprecate validation methods in advance of the Forum, in response to ongoing and emerging security threats - such as disallowing the "Any Other Method" even while the BRs permitted it.
We've seen multiple claims from members that "no certificate using Method X has ever been misissued", but, to date, no data to support that statement has been provided, nor is it quantifiable. Thus, relying parties have no idea whether or not certain methods are demonstrably weaker, and the CAs that practice those methods demonstrably less secure.
The distinction here is that the Baseline Requirements capture the minimum, but that should not be conflated with what is sufficient. CAs routinely make this argument to their customers, when they discuss the value of OV and EV certificates, in that they posit that there is a greater value than the common acceptable level. Equally, we see browser vendors disagreeing on what the appropriate level of product security is for their customers, and some requiring additional information - such as, for example, Certificate Transparency information, or deprecating weak and insecure algorithms. Because the BRs capture the minimum state, they will never and can never capture stronger security requirements.
In this regard, enshrining this information allows for both relying parties and CAs the ability to make discerning choices about the level of trust introduced and afforded. Should we pretend that this information somehow belongs elsewhere (likely because CAs wish to preserve using insecure methods), then inevitably the next steps would be to see greater fragmentation, in browsers requiring this information to be established even if the BRs don't, should that be appropriate for their client security - or potentially distrusting CAs that use validation methods they feel are insecure.
I think it's misguided and mistaken to believe that this information is not relevant or applicable for trust decisions, and while I know CAs are keen to protect their interests in using methods that they may feel are 'secure enough' (much like they did with SHA-1), the reality is that trustworthiness is in the eye of the RP, not the CA.
The Future
The software and technology industry has understood that transparency and auditability are important properties for any software system to have. In the past few years, we’ve seen that principles such as reproducibility, hermeticity, correctness, and the inclusion of supply chain metadata (e.g., SBOMs) slowly become more relevant. We’ve seen that companies such as Chainguard and communities such as Nix and Bazel take a front seat in trying to address some of these challenges.
The inclusion of the domain control validation method in issued certificates could be partially seen as another entry in SBOMs—e.g. where and how did this certificate come to be?
I hope that Root Programs and Certification Authorities agree about the usefulness of including the domain control validation method in the issued certificates. I also hope to see less bike-shedding discussion in the CA/B Forum regarding on how this should be adopted.
In future posts, I hope to write about some more data that I believe should be included in certificates. To give you a sneak peek of one, I also believe—mainly due to much of the same reasoning in this post—that versioned CPS (Certification Practice Statement) URIs should also be included in the leaf certificates.