[cabf_validation] Validation methods used for Wildcards/ADNs

Fri Jan 15 18:33:46 UTC 2021

Of the validation methods in question here, Let's Encrypt only uses
3.2.2.4.19 (Agreed-upon Change to Website - ACME, a.k.a. RFC 8555's
HTTP-01). Let's Encrypt does not allow this method of validation to be used
for wildcard names, so 0% of our certificates would be affected.

Additionally, we often receive enquiries as to why we do not allow HTTP-01
for wildcards, so I would support having this language in the BRs.

Aaron

On Thu, Jan 14, 2021 at 8:43 AM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

> 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
>>
> _______________________________________________
> 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/20210115/252ec22c/attachment.html>