(no title)
sleevi | 4 years ago
For example, QWACs cannot legally be automated (e.g. via ACME), because of certain restrictions applied to needing to validate the natural or legal person making the certificate request. This actually was an issue for one CA (BuyPass) that tried to support ACME but ran afoul of the framework.
While originally QWACs were proposed as optional, regulation such as PSD2 attempts to make them mandatory for (financial services) servers to obtain. If one of those keys is compromised, then the server wishing you obtain a replacement certificate may have to wait weeks to obtain such a certificate, or make an in-person visit to the CA (e.g. the post office).
A considerable number of compromised or misissued certificates have failed to been revoked on the industry-agreed upon timelines (24 hours or 5 days, depending), because of challenges CAs have faced because their customers haven’t (or legally can’t) automate replacement, and because the additional information in the certificate requires manual validation, despite having no technical impact on the TLS connection.
kjetil|4 years ago
I get QWAC goes against the trend of phasing out EV certs. But isn’t the real issue that the browsers don’t trust TSP audits carried out for EU member states?
sleevi|4 years ago
Similarly, automation affects how easy or hard it is to replace a CA, for example, if moving to distrust a CA. If you rely on QWAC attributes, you can only use QWAC CAs, and changing CAs becomes significantly more complex.
The audit issue is definitely an issue: the audits used are fundamentally different than what browsers try to achieve, and so having to adopt the lower standard definitely impacts user security. However, my point was that in addition to those concerns, the technical design itself results in less robust and less agile systems, and that makes things less secure.