[cabf_validation] Validation methods used for Wildcards/ADNs

[Adriano Santoni]

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 
> <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
>       o 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 <http://www.example.com>" when 
> the method used was 3.2.2.4.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 3.2.2.4.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 3.2.2.4.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
> https://lists.cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201218/44501cbc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201218/44501cbc/attachment.p7s>