[cabfpub] Domain Validation Revision

[Jeremy Rowley]

Thanks Ryan, 

In line with "tightening up" the requirements, it would be nice to see Section 7 tightened to go from "Making a change on any file on a web server" to being a specific path (e.g. a .well-known URI)
[JR] We discussed this, but I can't remember what the objection was.  I'll bring it back to the working group unless someone else chimes in.

Incidentally, due to other discussions, I'm curious how 2 and 3 tangibly differ (given that the Registrar will provide WHOIS information). Even if they are kept separate, does it make sense to add "through a Reliable Method of Communication" to Section 3, as you have with 1/2?
[JR] For 2 sometimes we call up the registrar to get info on how to contact the registrant (such as when the domain is private). However, we could probably combine them to a single bullet point and apply reliable method of communication to both. 

Regarding the language "agreed-upon", this does seem to give significant leeway for CAs to be lax in ways that attackers may exploit. Consistent with your "tightening up" goal, should Items 6 and 7 be explicit that the CA must dictate what change to make? Otherwise, I am concerned that the attacker can "propose" a change (using a portion of the system that they control) and then be issued a certificate. As I've mentioned in the past, it would be nice to see an explicit whitelist for these two methods, consistent with the whitelist for email addresses in Section 4.
[JR] Agreed. By posting this to the mailing list, we're hoping that CAs will indicate exactly what they want covered so we can narrow the scope of these two sections. I probably should have mentioned that in the original email...

Put differently, I can see 7 being a little fuzzy-on-the-edges, even though it does approach a more restrictive subset. It would be great to explicitly specify record types that may be used to perform this demonstration (e.g. a TXT record with some CA-dictated value, making a change to a CNAME/A/AAAA in some meaningful way, etc)
[JR] I'll have the working group come up with an initial list. If anyone has specific ways they verify though DNS, please email it to me for consideration. 

8 concerns me for a couple reasons, even though it's moving in the right direction.
- You require HTTPS, but that seems overkill, when you only need to perform a TLS handshake. That is, consider a mail server configured for SMTP-S - it seems that would be a viable configuration
- It would seem that anyone that can get a port forwarded on a particular address can now get a certificate on that address. For things like STUN-TCP services, this seems quite bad!
- The definition of "test certificate" is, from experience, a bit of a handwave that varies from CA to CA. It would be nice to put some explicit technical profile in place here (e.g. a critical poison extension, a requirement that EKUs are present but not serverAuth/clientAuth, issued from a CA independent of the issuing CA's 'trusted' hierarchy) that would prevent relying parties from believing the test certificate is "real"
[JR] This was added by GlobalSign so I'll let them comment.
 

These are just some initial reactions from the proposal; more may come in time.


On Thu, Feb 12, 2015 at 6:55 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> Attached is a draft proposal from the EV working group about revising 
> the domain validation in the BRs.  The intent is 1) to eliminate the 
> “any other option” (as it made domain validation essentially 
> meaningless, 2) tighten up the domain validation language, and 3) 
> permit attorney/accountants to draft the domain authorization document.
>
>
>
> Note that revising this section will automatically revise domain 
> validation in EV. Also note that this is a draft from the working 
> group and not yet a proposed ballot.
>
>
>
> Jeremy
>
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>