[cabf_validation] Call notes from May 7

[Jeremy Rowley]

Validation Working Group notes
May 7, 2015
Attending: Jeremy, Ben, Kirk, Cecilia, Doug, Tim
1. Legal Opinion Letter:  This group approved it.  Jeremy will send out a ballot to the main mailing list.
2. EV for Individuals:  Jeremy will look at what Cecilia sent him.
3. Domain Validation Proposal:  Jeremy looked at different CA CPSs.  He went through the bigger CPSs and pulled what they do for validation and created a generalized list of all possible ways to conduct validation.  Jeremy then modified them slightly based upon feedback.  There were a couple of comments that Jeremy received. Anoosh did not thing that the practical demonstration of control of #6 was very secure.  Comments on the Mozilla list about #2 and #4 and getting rid of the Administrative Contact.  Jeremy and Cecilia do not think that either of those need to be modified in any way.  A lot of people validate using Administrative Contact.
a. Kirk asked where the 128 bits of entropy for random value came from.  Gerv put in the 128 bits of entropy for Random Value.  Kirk asked if it was necessary to specify 128 vs 120 that would allow some of the most common Random Number generators.  Jeremy doesn't have a problem switching it to that, as long as the applicant is not the one specifying the value. Then it shouldn't matter. Jeremy will modify the following definition:  Random Value:  A value specified by a CA to the Applicant that exhibits 112 bits of entropy.
b. Confirming the Applicant (or the applicant's parent company, subsidiary or affiliate) as the Domain Name Registrant directly with the Domain Name Registrar through a Reliable Method of Communication, for example using information provided through WHOIS.  -Kirk would like to add back in parent, subsidiary and affiliate.
c. Confirming authorization of the Certificate's issuance directly with the Domain Name Registrant using a Reliable Method of Communication that is (i) obtained from the Domain Name Registrar or (ii) listed as the "registrant", "technical", or "administrative" contact for the WHOIS record of the Base Domain.  - Base Domain is defined.
d. Confirming authorization for the Certificate's issuance through an email address created by pre-pending 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' in the local part, followed by the at-sign ("@"), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;  Either the FQDN or the base domain. -  Doug feels from a requirements standpoint, should we allow the FQDN or the Base Domain or anything in between?  Rick suggests that you can prune down FQDN is the right choice, or domain or anything in between.  Kirk is satisfied with the language like it is.  Rick is worried about unintended consequences.  Rick suggests you prune down to the domain name and add admin, webmaster, hostmaster, etc.  Does the current language allow that to happen?  Rick will continue this question on the list.  This is saved for the agenda of next call.
e. Relying upon a Domain Authorization Document that meets the requirements listed below:    Current definition:  Documentation provided by, or a CA's documentation of, a communication with a registrar, registrant, or the person or entity listed in WHOIS as the Domain Name Registrant, including any private anonymous or proxy registration service, attesting to the authority of an applicant, to request a certificate for a specific Domain Namespace.  - A few browsers commented that they did not feel comfortable with Attorney information and they are not included in this definition.  By not changing the definition of Domain Authorization Letters to include attorney letters we have solved this problem.
f. Having the Applicant demonstrate control over the FQDN or Base Domain by adding a file containing a Random Value to the "/.well-known/certificate" directory at either the FQDN or the Base Domain in accordance with RFC 5785. -  Anoosh did not feel like practical demonstration of control was very strong. Base Domain is added in. Jeremy thinks it makes it easier without adding a whole lot of risk.  Doug doesn't feel comfortable with that.  He sent some comments to Jeremy, thinks generally through this whole update, we need to clearly define FQDN, and Base Domain everything in between.  And say, for each of these method, pruning one or more items down to the Base Domain, or is it just FQDN or just Base Domain? Doug thinks we should be careful and precise about how we define each of these 10 items and choose carefully where these changes can happen. If we allow it to happen anywhere in between for email, then why not allow anywhere in between for domains? In which case we would want to expand this last definition to say an FQDN or Base Domain or anything in between if that's what we're doing for email.  Jeremy would be in favor of getting rid of pruning.  Doug can think of cases where that's not good.  Doug's recommendation would be to come up with a defined term and use that term consistently.  Should anything in between be included?  We will come back to that.
g. Having the Applicant demonstrate control over the FQDN or Base Domain by the Applicant making a change to information in a DNS record for the FQDN or Base Domain where the change is a Random Value;
h. Having the Applicant demonstrate control over the requested FQDN by the CA confirming, in accordance with section 11.1.1, the Applicant's controls the FQDN (or Base Domain of the FQDN) returned from a DNS lookup for CNAME records for the requested FQDN;  Kirk does not understand why is states "in accordance with section 11.1.1".  Believes it is a circular argument and confusing.  Jeremy will move "in accordance with section 11.1.1" to the end of the method.
i. Having the Applicant demonstrate control over the requested FQDN by the CA confirming, in accordance with section 11.1.2, that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the requested FQDN; Concern over IP addresses.  Does anyone have any concerns? Ryan Sleevi has a concern with IP addresses.  We will come back to this another time.
j. Having the Applicant demonstrate control over the FQDN by providing a TLS service on a host found in DNS for the FQDN and having the CA (i) initiate a TLS connection with the host and (ii) verify a Random Value or request token that is a in a format recognized as a valid TLS response. Tim: This is Let's Encrypt.  What they say is retrieval of Random Value from https done within a file with https example.com.  It's essentially 6 but you're just using https instead of atp.  This is missing some of the goodness that we've added in #6. Doesn't have the specification that you have to use the well-known location so that could be anywhere on https example.com, and there's also the caveat that in many cases the customer doesn't have the cert yet.  Gerv's suggestion is that, since http is good, you're allowed to do TLS with a self-signed certificate. You're essentially doing unvalidated TLS to download this file.  If unvalidated TLS is permitted, then we need to say so explicitly.  That would not be his reading of it, as written. Kirk: Thinks there's stuff missing.  Leaving out how the Random Value is placed on the website.  If this depends on an agent somewhere, it should be spelled out. Doug:  GlobalSign submitted something to be admitted to cover something that they currently do under the any other method.  The customer generates a CSR, we sign it into some test certificate under some hierarchy, and they install it.  The fact that it's installed on the server, and we can connect to it using TLS, indicates that they have Domain Control enough to install a certificate where it needs to go.  One use case for this, and Gerv made a comment for number 10 that covers that plus other things. Tim: Thinks we should make that 2 different ones.  Kirk doesn't see how the applicant is involved.  Doug agrees that this leaves open all of the holes that we are trying to close above.  Kirk: The other methods show the applicant doing something.  10 does not have steps for the applicant to take in this response.  Doug: Now that the Random Value has been placed on the site, what are the acceptable methods to then validate it? Kirk would like to see more specific details about how the Random Value is given to the Applicant, and how and where it's placed.
Jeremy will write up what we got done on this meeting, and we can revisit this next time.

Agenda for next call:

1.      EV for Individuals

2.      Domain Validation-#4 Should we allow the FQDN or the Base Domain or anything in between?

3.      Domain Validation-#6 Should we have a defined term used for consistency regarding FQDN, Base Domain, and anything in between?

4.      Domain Validation-#10 Should this be 2 different ones? This leaves open all of the holes the group tried to fill in the above methods.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150514/8046dad8/attachment-0001.html