On Sun, March 22, 2015 4:18 pm, Kathleen Wilson wrote:
>  After reading this:
>  
> https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html
>
>  I'm thinking we need to update our wiki page:
>
>  
> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
>  ~~~
>  For domain-validated SSL certificates, many CAs use an email
>  challenge-response mechanism to verify that the SSL certificate
>  subscriber owns/controls the domain to be included in the certificate.
>  Some CAs allow applicants to select an address from a predetermined list
>  to be used for this verification.
>
>  Offering too many options for the email address prefix increases the
>  risk of issuing a certificate to a subscriber who does not own/control
>  the domain. Therefore, the list of email address prefixes should be
>  limited.
>
>  Mozilla's recommendation is to limit the set of verification addresses
>  to the following.
>
>       admin@domain
>       administrator@domain
>       webmaster@domain
>       hostmaster@domain
>       postmaster@domain
>       Plus any address listed in the technical or administrative contact
>  field of the domain's WHOIS record, regardless of the addresses' domains.
>  ~~~
>
>  What do you all think?
>
>  Kathleen
>
>  (Note this is also in Baseline Requirements section 11.1.1)

Hi Kathleen,

I'm slightly concerned with the wording, because it seems to reinforce the
notion that this is a Mozilla policy-specific requirement, rather than the
Baseline Requirements, as you note. It also reinforces the notion of
"Domain-validated" SSL certs, which are simply a marketing term that CAs
have created for BR-complying certs that don't contain organizational
information (which the BRs list as optional, but, if present, must comply
to certain requirements)

The other thing with your proposed wording is that it doesn't handle the
FQDN pruning permitted by 11.1.1 p4. That is, if I apply for
ryan.sleevi.example.com, then a CA is allowed to use {whitelisted
address}@ryan.sleevi.example.com, {whitelisted
address}@sleevi.example.com, or {whitelisted address}@example.com during
the application (as indeed, ryan.sleevi.example.com and sleevi.example.com
may not have MX records)

Because of this, perhaps it might be simpler to word

~~~
Mozilla's Root Inclusion Policy requires that CAs conform to the Baseline
Requirements in the issuance and management of publicly trusted SSL
certificates. This includes the Baseline Requirements' restrictions and
requirements on the use of email as a way of validating and authenticating
certificate requests.

CAs are expected to conform to Section 11.1.1, which restricts the email
addresses that may be used to authenticate the subscriber to information
listed in the "registrant", "technical", or "administrative" WHOIS records
and a selected whitelist of local addresses, which includes local-parts of
"admin", "administrator", "webmaster", "hostmaster", and "postmaster".

A CA that authorizes requests by contacting any other email addresses is
deemed to be non-compliant with Mozilla's Inclusion Policy, non-conforming
to the Baseline Requirements, and may have action taken upon it as
described in "Maintaining Confidence in Included Root Certificates".

CAs are also reminded that this policy extends to any certificates that
are technically capable of issuing SSL certificates and that are not
technically constrained; subordinate CAs that fail to enforce these
requirements reflect upon the issuing CA that certified it.
~~~

Or something to that nature.

I'm totally on board with spelling it out, but the fact is, this is a
Baseline Requirements requirement, and is perhaps the most basic. Any CA
not following this raises serious red flags for the rest of 11.1.1 (the
single most important requirement of the BRs), and raises serious
questions as to the competence of the CA.

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to