[cabf_validation] Validation methods used for Wildcards/ADNs

[Ryan Sleevi]

Yes, that is correct in how Authorization Domain Names and Wildcard Domain
Names work, and precisely what this proposal sets forward to accomplish.
This is because demonstrating the ability to edit a file on the web server
is not equivalent to demonstrating you have controlver over DNS, as the
other validation methods achieve, and is equivalent more to demonstrating
control over an TLS handshake, where we have intentionally limited in the
same way.

On Fri, Dec 18, 2020 at 4:55 AM Adriano Santoni via Validation <
validation at cabforum.org> wrote:

> Ryan,
>
> do I understand correctly that your post below implies the following?
> (first bullet is just a typical example, of course it would be the same for
> all subdomains)
>
>    - if domain validation is passed on (say) domain.tld by the website
>    change method (§3.2.2.4.6), then a certificate containing
>    www.domain.tld MUST NOT be issued
>    - if domain validation is passed on (say) domain.tld by the website
>    change method (§3.2.2.4.6), then a certificate containing *.domain.tld
>    MUST NOT be issued
>
> Adriano
>
>
> Il 03/12/2020 02:31, Ryan Sleevi via Validation ha scritto:
>
> 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 3.2.2.4 methods can be used for
> Authorization Domain Names / Wildcard Domain Names.
>
> I made an initial attempt at
> https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules
> 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
>
>
>    - 3.2.2.4.6: Agreed-upon Change to Website
>       - Sunset 2020-06-03 for new validations
>    - 3.2.2.4.18: Agreed-upon Change to Website v2
>    - 3.2.2.4.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 3.2.2.4.20 (TLS using ALPN), which also only demonstrates
> control over a single service/port on a single FQDN.
>
> This doesn't touch 3.2.2.4.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 3.2.2.4.6 for "example.com").
> Just sharing those numbers is useful to understand any challenges CAs might
> face.
>
> For example:
>
>    - 30% of our certificates used 3.2.2.4.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 3.2.2.4.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.
>
> _______________________________________________
> Validation mailing listValidation at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/validation
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201218/aaa6de75/attachment.html>