[cabf_validation] Validation methods used for Wildcards/ADNs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Tue Feb 23 11:31:05 UTC 2021
Would it make sense to allow "agreed-upon change to website" methods to
validate wildcard *onion* domain names since these terminate on the same
On 3/12/2020 3:31 π.μ., Ryan Sleevi via Validation wrote:
> Hey all,
> 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 22.214.171.124
> methods can be used for Authorization Domain Names / Wildcard Domain
> 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 summary
> * 126.96.36.199.6: Agreed-upon Change to Website
> o Sunset 2020-06-03 for new validations
> * 188.8.131.52.18: Agreed-upon Change to Website v2
> * 184.108.40.206.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 220.127.116.11.20 (TLS using ALPN), which also
> only demonstrates control over a single service/port on a single FQDN.
> This doesn't touch 18.104.22.168.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 <http://www.example.com>" when
> the method used was 22.214.171.124.6 for "example.com <http://example.com>").
> Just sharing those numbers is useful to understand any challenges CAs
> might face.
> For example:
> * 30% of our certificates used 126.96.36.199.6. Of that 30%:
> o 80% of our certificates had at least one FQDN validated by
> ADN, with 40% of that being "www.".
> o Of the 20% that had >1, we saw an average of 7.3 additional
> FQDNs validated by FDN.
> * 17% of our certificates used 188.8.131.52.18. of that 17% ....
> o 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.
> Validation mailing list
> Validation at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation