On 10/12/2015 05:36, Peter Kurrasch wrote:
(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.
This is actually the most common way for "domain validated"
certificates. It uses a standard defined point of contact that has a
reasonable chance of being done by a different computer system than the
one protected by a web server TLS certificate, thus reducing the chance
of a web server compromise escalating to obtaining a fraudulent
certificate for permanently hijacking that site.
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.
That argument is the reason #4 is more popular. However not all
webserver domains have e-mail servers handling them, which is why #6
(or a similar technique for DNS) is sometimes used.
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.
#7 covers a lot of cases that cannot be reasonably enumerated in the BR,
but should be listed in the specific CPS, for example:
- The CA is itself the subject of the certificate
- Ultra high security procedures involving direct non-Internet contact
between the CA and the subject. For example Government CAs often uses
government internal identity checking procedures when issuing
certificates for Government entities.
- Regular high security procedures such as requiring the subject to
appear in person with specific kinds of identity proof combined with
checks against official records.
- A (Sub)CA issuing e-mail and client certificates to its employees.
- Previously validated CA customers logging on to a secure CA web
portal to request additonal certificates.
- Renewal via proof of possession of the prior certificate.
As for #5 a domain authorization document is often a message from the
WHOIS registrant of the domain that another party is allowed to request
the certificate.
Some common cases:
- The web page is hosted on a shared server and the hosting provider
wants to add the domain name as a SubjectAlternativeName to the
certificate that handles incoming https for all the domains hosted on
a given IP address. Here the verified domain owner issues a form
letter authorizing the hosting provider to make that request from
their chosen CA.
- The web page is held "in trust" for its true owner by a related party
(e.g. the domain may be registered in the name of an executive or
sister company yet the certificate is requested by the IT department
elsewhere in the legal structure of a big organization).
- The certificate requesting is done by an outsourced IT organization
and the actual owner issues a letter authorizing that outsourced IT
organization to request the certificate.
- The domain is registered via a proxy and the proxy then issues a
document allowing the true owner to request the certificate.
The CA must validate the originator of the message as thoroughly as it
would have a requestor-on-own-behalf and be equally thorough in
validating that the requestor is the entity named in the authorization
document. In practice the authorization document is required to refer
specifically to a single request via e.g. a date or some identifying number.
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.
Indeed, unfortunately some registrant proxies operate under a "burn all
mail" principle that prevents them from forwarding challenge messages
to the true owner. Hence the need for using the other items as
fallback.
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 believe the most common cases of #1 and #2 are when the CA (or the
CA's registration agent) is also the Registrar (or domain reseller) for
the domain. In other words these are cases of first hand knowledge but
possibly via a "sister company" relationship, e.g. between GoDaddy
domain registrations and GoDaddy CA . Or the previous relationship
between VeriSign Network Solutions and VeriSign the CA.
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?
*From: *Kathleen Wilson
*Sent: *Wednesday, December 2, 2015 2:18 PM
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
