[cabf_validation] Validation methods used for Wildcards/ADNs

[Ryan Sleevi]

Just resurrecting this for the new year, and hoping people have had a
chance to look at data.

We'll work on circulating a concrete draft for the next call to accomplish
this, but would love to have data to inform the timelines.

On Fri, Dec 18, 2020 at 9:45 AM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

> 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
>>
> _______________________________________________
> 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/20210114/81d45a07/attachment.html>