[cabfpub] Domain Validation Revision

[Ryan Sleevi]

Jeremy,

I'm excited to see momentum towards removing the the "Any other
option" language, so I'm glad to hear the EV working group is tackling
this.

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)

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?

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.

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)

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"

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
>