For a little while now I've been following a new type of certificate that you may soon be hearing a lot more about. They're called a "Qualified Website Authentication Certificate", or QWAC, and I think it's worth talking a little bit about them.
Certificate Validation
Before we dig in, it's worth clarifying what is meant by the 'validation level' of a certificate. Right now, we have 3 types of certificate you can use on your website; Domain Validation (DV), Organisation Validation (OV) and Extended Validation (EV).
A DV certificate requires that you prove control of the domain in question in order for the Certificate Authority (CA) to issue you a certificate. If you inspect the certificate on almost any website, you will find a DV certificate. When inspecting a certificate, the Subject is the 'person/entity' the certificate was issued to and the Subject field contains their information, so the Subject field in my certificate is information about 'me'.
Subject:
CN = scotthelme.co.uk
O = Cloudflare, Inc.
L = San Francisco
S = California
C = USIn a DV certificate, only the 'domain' is 'validated' and as such this is the only information you can rely on being accurate, that I am scotthelme.co.uk. Cloudflare do however automatically issue OV certificates.
An OV certificate would have an additional piece of information validated, the 'Organisation' (O), unsurprisingly!
Subject:
C=DE
ST=Hamburg
L=Hamburg
O=DFN-CERT Services GmbH
CN=ldap1.pca.dfn.deYou can find currently valid OV certificates that are in use with this Censys Search (just tweak the expiry date) and see examples of others that exist.
An EV certificate will have another piece of information that will be accurate in the form of the Country ('C'), which was traditionally used in the browser UI, and various other fields governed by the Certificate Authority/Browser Forum document called the EV SSL Certificate Guidelines.
Subject:
jurisdictionCountry=GB
businessCategory=Private Organization
C=GB
ST=London
L=London
jurisdictionCountry=GB
O=Barclays PLC
businessCategory=Private Organization
OU=Technology11
serialNumber=00048839
CN=qa01-svc.barclaycardus.comAs an example, the serialNumber field is required to be the registered company number for the organisation and I can search for that at Companies House, our government register of companies here in the UK, and find the registered company. Of course, we depend on the CA to properly validate all of this information and put it in the certificate, and that doesn't always happen, but that's the idea.
The decline of EV Certificates
The data shows that the use of EV certificates is declining quite rapidly, even with the explosion in the use of HTTPS, and thus certificates, across the Web. In my last analysis of the Top 1 Million sites in the World, I observed the continuing decline in the use of EV certificates despite a sharp increase in the number of websites using certificates.
There are different theories about this but I summarise them to:
- EV certificates are horrendously expensive.
- EV certificates are harder to manage/renew.
- EV certificates are less friendly to automation.
- EV certificates don't 'do' anything...
My stance on EV certificates is no secret and I haven't been a fan of them for some time, and with good reason:
Are EV certificates worth the paper they're written on?
When your CA turns against you
Extended Validation not so... extended? How I revoked $1,000,000 worth of EV certificates!
On a serious note though, my biggest problem with EV certificates is that they 100% depend on the user to work. When we have phrases like "the user must look for the EV indicator in the address bar" or "the user should check the information is accurate", you can forget about it ever being effective. I'm not criticising users, I'm a user, we're unreliable! WE SHOULD NOT DEPEND ON THE USER. This is number one reason I'm against EV certificates and any other mechanism that firmly places the burden on the user to be responsible and "do" or "not do" something in order for the mechanism to succeed.
Qualified Website Authentication Certificate
Given the above, and how we know that placing a burden on the user is a Bad Idea (TM), I was quite surprised to see the rise of the QWAC. Governed by eIDAS (electronic IDentification, Authentication and trust Services) in the EU, people in favour of QWACs have a lot of great things to say about them.
Take this snippet taken from the Wikipedia page about QWACs that provides no citations whatsoever.
Extended Validation certificates offer the highest quality in terms of assurance of the identity of a certificate owner among existing types of certificate in the market. Typically the use of an EV certificate is indicated by a green color – but this varies by browser.
The eIDAS Regulation has taken into account that there is an established market with its own industrial standardization efforts. The objective is not to create a disruption with existing initiatives but to optimize the effort for qualified providers to align both with the EU regulations and with the existing market standards."
It's very quickly starting to sound like EV++ to me and if you want you can dive deep into the regulation (specifically ANNEX IV) that outlines exactly what "Qualified certificates for website authentication shall contain". All of the basics are in there around domain names, start/end dates and information about the entity that issued the certificate and the entity the certificate was issued to, of course. OK, so the information is in the certificate, but what's supposed to happen with it, is someone or something supposed to check it? If so, what do we check it against? What's it for?
The main CA pushing QWACs is Entrust, and this is their list of "QWAC eIDAS Features", so let's see what they have to say about why I should get one.
Legal Compliance
Secure and verify organizations in compliance with eIDAS regulations.
Strongest Security
All of our certificates are identity checked in accordance with European standards and secured using the latest security guidelines: SHA-2/2048 bit keys, 128-256-bit encryption and support RSA encryption.
Unlimited Reissues
Cancel and reissue SSL certificates throughout their term without hassle.
Unlimited Server Licenses
Install TLS/SSL certificates on an unlimited number of servers at no extra cost.
Robust Reporting
Avoid accidental certificate expirations with automatic expiration notifications.
Apart from the first point around legal compliance, the rest are just absolute nonsense that apply to literally any other type of certificate you might care to acquire, but other CAs aren't missing out on the party. DigiCert recently acquired QuoVadis who are a Trust Service Provider (TSP) recognised in the EU, giving DigiCert the ability to issue QWACs in accordance with the eIDAS regulation.
Are QWACs useful?
There are arguments both ways here and one thing I could see value in the requirement to use QWACs derived in Payment Service Providers Directive 2 (PSD2) when my application is doing tasks like talking to my Payment Service Provider (PSP) and we can require the higher validation level of a QWAC compared to, let's say, a DV certificate. But that's a machine talking to a machine or a business talking to a business, and we have other ways to make that reliable. My real concern is the push towards placing yet another burden on the user. Even the eIDAS regulation itself outlines this in Recital 67 (highlights mine).
Website authentication services provide a means by which a visitor to a website can be assured that there is a genuine and legitimate entity standing behind the website. Those services contribute to the building of trust and confidence in conducting business online, as users will have confidence in a website that has been authenticated. The provision and the use of website authentication services are entirely voluntary. However, in order for website authentication to become a means to boosting trust, providing a better experience for the user and furthering growth in the internal market, this Regulation should lay down minimal security and liability obligations for the providers and their services.
It sounds like all of the old problems with EV, all over again. What does it mean if I'm assured that the website I'm visiting is "genuine and legitimate"? If I decide to visit cheap-nike-trainers.com and they have a QWAC, they're the 'genuine' and 'legitimate' Nike trainer company, right? They're not going to sell my data because they're a 'genuine' and 'legitimate' company and they wouldn't do that, right? We've already been through all of this with the Guidelines for the Issuance and Management of Extended Validation Certificates which sets out the following:
2.1.3. Excluded Purposes
EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:
1. That the Subject named in the EV Certificate is actively engaged in doing business;
2. That the Subject named in the EV Certificate complies with applicable laws;
3. That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or
4. That it is “safe” to do business with the Subject named in the EV Certificate.
Verifying a company is registered and exists against some official register of companies tells you absolutely nothing about that company other than someone paid the £14 (~$20) fee to register a company, but CAs will continue to push EV, and soon QWACs, because they can be sold for 💲💲💲 in a world where certificates are becoming free for almost everyone.
Don't worry though, if this all seems complicated and too difficult for you, ENISA has created the "Security guidelines on the appropriate use of qualified website authentication certificates - Guidance for users" document that's a mere 43 pages long and tells you all about QWACs and what they do and do not do!
Audacity That Knows No Bounds
Back in September 2021, the The European Union Agency for Cybersecurity (ENISA) held the Trust Services Forum - CA Day 2021 which had quite a few interesting presentations on the agenda. I didn't participate, but I've spoken to people who did and most of the presentations are available online for public viewing. There were more than a few things that caught my eye and a couple that are worth raising. In one of the early talks, "Building Trust in the digital world: The European Identity Vision", I noted the first hint towards something I was expecting and worried to see.
The phrase "Display of qualified website certificates by browser in a consumer-friendly manner" is just screaming 'EV UI' all over again, and I wonder how we didn't learn our lesson there, but something else worried me even more. The preceding words in that sentence were "Regulatory Proposal". There is a serious suggestion here that the EU should introduce regulation to force browser vendors to implement a regulated UI for QWACs! Now, the presenter is the Managing Director of a CA and a regulated browser UI would allow them to say "green address bar!!11!1" all over again, but actually have it stick this time. They weren't the only one either...
Entrust decided to come out with all guns blazing and talk about "Designing the New eIDAS 2 Browser UI". Just let that sink in a moment. A Certificate Authority giving a talk on how they should regulate and design the UI of someone else's software product! You really should read the entire presentation but here are a few of the good bits:
"[Browsers] should recognise and display [QWACs] to provide a high level of assurance, allowing website owners to assert their identity as owners of a website and users to identify the website owners with a high degree of certainty."
"“[QWACs] *** shall be recognised by web-browsers. For those purposes web-browsers shall ensure that the identity data provided *** is displayed in a user friendly manner. Web-browsers shall ensure support and interoperability with [QWACs] ***"
While we're here, why don't we try and bend the GDPR and make it fit our goals of having expensive QWACs be a requirement?
How ridiculous! It does get worse though and this next slide fills me with horror and rage at the same time.
The audacity of a CA with a dying product knows no bounds when they're trying to revive it and honestly I could screenshot almost every other slide for your consumption, but you really do need to go and scroll through the entire thing because it just, gets, worse.
Going back to the 2019 ETSI Security Week, eIDAS was discussed and again the 'problem' of not being able to control browser UI was described by a CA. This isn't a recent concern.
Other Problems With QWACs
Yes, yes, I know.
But there is another problem here and it sits smack bang in middle of the "we've already made this mistake before" category. For years we've battled with the problems around certificate revocation with standards like CRL and OCSP coming and going during that time. We may have a glimmer of hope on the horizon in the form of CRLite, but for now, we have nothing. The core issue with revocation checking a certificate is how does the client check the status of the certificate without reaching out to an external party, creating dependencies, single points of failure, performance costs and privacy issues abound. We ended up realising that revocation checking is pointless but now, we're looking at introducing many of the same problems again with QWACs.
Surely there isn't going to be some external component to QWACs that will require a browser to reach out to a service and validate the certificate?.. Well, ENISA built a plugin to demo the use of a QWAC in the browser and published a report. The report contains some absolute zingers and is well worth a read:
Since they [DV] are the least apparently secure (from what they provide and also from a system wide perspective) and do not require appended identification information, they allow malware and fraudulent websites to ‘hide’ more easily from currently available common security tools. Problematically, according to a report from Infosecurity Magazine, the protection offered by SSL hides not only the data with good intentions but also the bad. In fact, nearly 50 percent of cyber attacks in the past year reportedly arose from sites and services protected by SSL.
Of course those naughty free certificates are bad and a certificate that costs 💲💲💲 is the solution! I'm also really happy to see that "nearly 50 percent of cyber attacks [are] protected by SSL", only another 50% to go! If we're going to encrypt 100% of traffic on the Web then it includes bad traffic, of course, because 100% is 100%. I've talked about this before, Let's Encrypt are enabling the bad guys, and why they should, and how it's impossible to say 'we should only encrypt "good" traffic'. If we're going to encrypt everything, it means everything.
But that's not what I wanted to highlight from the report, it's this.
Validation of QWACs (R1)
The software component will read and confirm a certificate’s presence on an EU member state’s Trusted List or via the EU “List of the Lists” in order to verify that it has been created and issued with transparency and according to the definition of qualified trust service as laid out in the eIDAS Regulation
This sounds an awful lot like "your browser will reach out to some service and check the certificate is valid", which is exactly the problem we had with revocation. Imagine you open your browser and visit kinky-adult-videos.com which is operated by Kinky Vids Inc. GB. Your browser is then going to reach out to some external service to query if the certificate issued to kinky-adult-videos.com operated by Kinky Vids Inc. GB is valid and can be trusted?.. Well, that sounds like real-time monitoring of my browsing activities to me... 🤷♂️
Of course, all of my fears are confirmed by reading a little further through the report (highlight mine).
5.2 Providing online validation
5.2.1 Architecture The proposed solution consists of a modern extension and an additional online service provided by a trusted third party that plays the role of a qualified online QWAC validator. The extension is built to send the URL of the current SSL/TLS connection to the dedicated online QWAC validator. The online validator checks the certificate and sends information back to the extension. The extension indicates something using a green or red icon, or an icon with the European flag, on the right-hand side of the address panel.
Be it an extension or built natively in to the browser, any system that requires an online dependency such as this is an absolute hard "no" from me, every day of the week, and will be from the browser vendors too. This is a terrible idea and is OCSP all over again.
What do the browser vendors think?
I think it's fair to say that the response from browser and client vendors has not been what the CAs might have wanted. Most notably, Mozilla set out some really excellent arguments, as they always do, in their response to the European Commission Review of eIDAS. You really need to read the whole thing but I will summarise their main points here.
1. It violates the eIDAS Requirements
2. It will undermine technical neutrality and interoperability
3. It will undermine privacy for end users
4. It will create dangerous security risks for the web
There's a whole section on "TLS server certificates are not the correct place to store QWAC identity information" and Mozilla go on to suggest the use of QWACs outside of TLS certificates, being delivered to the client via a DNS TXT record, the well-known URI or a JWT. I can't find anything I disagree with in their response and I think this summarises my view entirely: "Mozilla recommends that eIDAS be re-written to exclude website authentication via QWACs from its purview in its entirety".
It's not just Mozilla and it's not just recent opposition, either. Back in 2015 eIDAS QWACs were being discussed at the CAB/Forum F2F in Istanbul and the minutes make for interesting reading along with the slides for the presentation. I think it's fair to say that there's an amount of scepticism around both the value and implementation of eIDAS QWACs.
The most recently published stance comes from a selection of operating system and browser vendors and can be found on the CAB/Forum mailing list here which links out to this Executive Summary with the following opening sentence: "This document outlines a proposed change to the technical profile for Qualified Website Authentication Certificates".
Conclusion
Given everything I've looked at and all of the research I've been doing on QWACs, I still can't get away from viewing them as nothing more than a glorified EV certificate.
ENISA compared their properties to other types of certificates and the pricing column always stands out for me.
Of course CAs are hugely supportive of this mechanism because they can get back to the good old days of selling certificates for 💲💲💲. But, just like I challenged many CAs in years gone by to provide evidence of their claims that EV was better, where is the evidence that supports QWACs being better? We're charging ahead with QWACs and claims are made with great frequency about all of the benefits that will befall those willing to buy a QWAC and how forcing the browser to implement a specific UI is the way forwards, but I've yet to see any evidence to back up a single one of those claims and until I do, I will remain sceptical.
For now, and until something changes, QWACs seem like a bit of a dead duck to me. ☠️🦆