WebPKI offers no real value over DANE TLSA records beyond Certificate Transparency and only Chromium fully enforces CT as of this month when backdating certificates to bypass it stopped being possible (due to 3 year issuance when they started requiring CT). Just started working.
Conversation
Firefox doesn't enforce it and Safari just started their own policy so they can't fully enforce it for almost another year (which is now the max lifetime largely thanks to Apple's unilateral decision to force it).
Never seen any non-browser bother doing real WebPKI support.
1
Nearly everything else just uses the WebPKI CAs without actually enforcing WebPKI rules beyond that. Some things hard-wire CA pins which is very risky without an out-of-band update mechanism. Few things do leaf pinning and those that do often fail to support rotation properly.
1
Reality is that if you control DNS or at least can appear to control DNS, you can trivially obtain a valid Let's Encrypt or other CA certificate. It's not really misissuance if you don't have DNSSEC + CAA. Hardly anyone checks CT meaningfully beyond making sure it's the right CA.
1
1
I'm looking forward to Let's Encrypt deploying accounturi support to production. They have it in staging (used for dry runs by certbot, etc.) but I can't get information on when it's going to be deployed to production. We use that for grapheneos.org, etc. alongside TLSA.
1
1
1
Look at the CAA records for grapheneos.org and then one of the subdomains like matrix.grapheneos.org. They each have their staging and production accounturi pinned for Let's Encrypt. It'll be nice when they start enforcing in prod. TLSA in browsers would ofc be nicer.
1
1
accounturi at least makes certificate issuance secure for the CA you choose to trust. It doesn't stop other CAs from ignoring DNSSEC/CAA, being compromised, etc. but at least for us our users can assume it's an invalid certificate if it's not Let's Encrypt which is easy to check.
2
If CT requires the CA to publish the CAA record they used to issue it and the signature chain leading to the CAA record, clients could automatically reject fraudulently generated certs.
1
The way it works is they know the domain they control for it and they know the format of their extended options such as accounturi and validationmethods. I don't really think a client could easily enforce CAA records even with that approach. It's not really designed for it.
2
If could reject a certificate issued by a CA that didn't have proof it was allowed to issue certs for that domain at all. I agree the more fine-grained rules are hard if not impossible to automate checking, but the elephant is easy.
1
What I mean is that at the moment, the browser doesn't have a way to map the name of the CA in CAA to an issuer certificate. It's not something you can really do right now. CAA is only really possible to understand by the CA that it corresponds to.
IIRC Mozilla required that CAs submit info about all the intermediates, etc. they have signed, roots they cross-signed, etc. but I don't think they actually know the CAA names for all those.
1
CAA name also just corresponds to some domain they administer, not a specific one of their roots / intermediates. Intermediates could use different CAA names, etc. since they can be separate orgs / setups.
1
Show replies
You're missing the point. You don't need a complete mapping of all CAA strings to CAs to be able to reject unauthorized issuance for the ones you do know (in a minimal implementation that could be just LE).
1
Algorithm is simple:
1. If the CT log has no DNSSEC signature chain proving absence of CAA or authenticity or insecure status of a CAA record, reject the cert.
2. If the CAA record is present and maps to a known CA, and the issuer is not that CA, reject the cert.
3. Else continue