| (changed the subject since we're not talking about SECOM anymore) Thanks for the info, Kathleen. Originally my concern was mostly with domain registrant proxies (if that's the preferred term?) but after reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items listed under section 3.2.2.4 have problems but some are worse than others (and there probably is no ideal solution anyway). I offer the following: 1) Item 4 is not only exploitable but in fact has already been exploited. I think the incident came up in this forum but if not I'll try to dig up an article. Either way, I suggest that the Mozilla policy be to specifically forbid this practice by CA's seeking inclusion in the trust store and that the CA policy docs state they will not use any "magic" email addresses. Of course I would encourage the CABF to remove this item from the BR, but Mozilla should take action on this regardless. 2) Item 6 should be forbidden as well. Demonstrating control over a website is not the same as having practical control over a domain. Seizing control over someone else's website can be a fairly straightforward process in some cases, so manipulating a web page proves only that it can be manipulated. Again my recommendation is for Mozilla to forbid the practice, for the CA policy documents to explicitly state that the method will not be used, and that the BR be updated in due time. 3) Both items 5 and 7 are entirely too ambiguous and open-ended. (I tried to find any specifications on what a domain authorization document must contain but didn't see it.) As written, I could declare ownership in a number of silly ways that a less scrupulous CA might just accept. I can appreciate that CA's might want and need flexibility in how they perform the verification, so it's important that CA's also document their verification procedures in some detail in their policy docs. My recommendation is for Mozilla to require a detailed description of any custom procedures that a CA intends to use. The description would be included in the CP/CPS and would need to specify the contents to appear in evidentiary documentation as well as how that documentation is to be transmitted from the cert applicant to the cert issuer. The CABF should tighten up the language in the BR, but Mozilla could still impose a mandate in the interim. Also: how long is a CA expected to retain such documentation and in what form? 4) Using WHOIS data as spelled out in item 3 is probably the most reliable mechanism since it is probably the least likely (amongst the other methods in section 3.2.2.4) to be falsified. That doesn't mean it can't be falsified, of course. However, if we set that aside there is still the matter of dealing with registrant proxies. If such a proxy is used, the information in whois cannot be relied upon to validate that the cert applicant is the actual domain owner. So the question becomes: How does a CA know if the contact info in whois is for a proxy or the real registrant? I don't have a good answer for that which leaves me a little dissatisfied with item 3. 5) Items 1 and 2 seem like they are fairly trustworthy but are not without pitfalls, too. For example, do cert applicants necessarily want their domain name registrar knowing if/when they have requested a cert, and under which CA? Is a registrar necessarily trustworthy enough to validate domain ownership all on their own without ever contacting the actual registrant? I assume there are perfectly valid situations where the registrar can or even must provide that validation, but I don't think a registrar should be trusted to make that decision under any and all circumstances. They probably can be trusted to have the correct contact info for the true owner-registrant but then what do you do if all they have is the proxy registrant's info? And how do I know that my registrar will not just give out my information to anyone who calls up posing as a cert issuer (i.e. be susceptible to social engineering)? The only recommendation I have at this point is that CA's should stipulate under what conditions they will use method 1 for ownership validation. I would expect it to be limited to specific situations but I don't know. The other subsections in 3.2.2 look like they might be problematic too, but I only really focused on 3.2.2.4. Any thoughts? Did I overlook something?
On 12/2/15 11:13 AM, Peter Kurrasch wrote:
> I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers? > > Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain. > > The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly. > Copied from the Baseline Requirements (note #2 and #4)... ~ 3.2.2.4. Authorization by Domain Name Registrant For each Fully‐Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN by: 1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar; 2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar; 3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field; 4. Communicating with the Domain’s administrator using 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; 5. Relying upon a Domain Authorization Document; 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed‐upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
