[cabf_validation] Validation methods used for Wildcards/ADNs
sleevi at google.com
Thu Dec 3 01:31:05 UTC 2020
I know we're not quite done with the certificate profile work, and I'm not
wanting to distract from that too much. However, one of the long-standing
items we had from our Herndon, VA validation summit (from Meeting 43) was
in harmonizing the rules around what 188.8.131.52 methods can be used for
Authorization Domain Names / Wildcard Domain Names.
I made an initial attempt at
to capture this. In effect, allowing validation as an ADN is conceptually
"the same as" allowing a Wildcard Domain Name, since the ADN can authorize
all children/grandchildren/etc of a domain, and a Wildcard is just a cert
that works for all children of a domain.
As we've become aware of some CAs having poorly evaluated the security
risks in this space, we'd like to try to close this gap. Here's the TL;DR
- 184.108.40.206.6: Agreed-upon Change to Website
- Sunset 2020-06-03 for new validations
- 220.127.116.11.18: Agreed-upon Change to Website v2
- 18.104.22.168.19: Agreed-upon Change to Website - ACME
(The other bits are just aligning some of the language, so that "MAY NOT"
becomes a clearer "MUST NOT", even though we mean the same)
These methods are proposed to *only* authorize a single FQDN, because they
only demonstrate control over a specific service/port on a specific FQDN,
and not demonstration of control over the whole domain namespace. This
aligns with 22.214.171.124.20 (TLS using ALPN), which also only demonstrates
control over a single service/port on a single FQDN.
This doesn't touch 126.96.36.199.4 (Constructed Email to Domain Contact),
although we identified that one as potentially messy. However, hopefully
we'll see that one fully sunset separately, in favor of the improved CAA
methods (.13 - .17).
It'd be useful to spend a few minutes on the call discussing folks initial
reactions. The big question, as always, is going to be timelines for
changes. If folks think more time is needed than "immediately", my request
is that they'd share concrete data.
Since Ballot 190 (2017-09-19), CAs have been required to maintain records
of the validation methods they use, so this "should" be as easy as scanning
all unexpired validations for these three methods and identifying cetrs
which have a SAN that doesn't equal the validated FQDN (e.g. a cert with "
www.example.com" when the method used was 188.8.131.52.6 for "example.com").
Just sharing those numbers is useful to understand any challenges CAs might
- 30% of our certificates used 184.108.40.206.6. Of that 30%:
- 80% of our certificates had at least one FQDN validated by ADN,
with 40% of that being "www.".
- Of the 20% that had >1, we saw an average of 7.3 additional FQDNs
validated by FDN.
- 17% of our certificates used 220.127.116.11.18. of that 17% ....
- 80% of the FQDNs validated by ADNs were for domains that did not
resolve (e.g. "internal.corp.foo.example"), and thus would have to switch
to a new validation method or expose those services publicly.
This sort of concrete data helps understand the impact to CAs, and their
customers, and thus indirectly, our users. It also helps figure out what
reasonable time frames to phase in could be, in the unlikely event a
phase-in became necessary.
This sunset "should" be fairly simple and uncontroversial, but since there
are edge cases (like internal servers), concrete data like the above is
useful if folks have concerns.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation