No. The definition of Authorization Domain Name allows a CA to issue www.example.com if the CA can prove control over example.com. However, the reverse is not true. Proving control over www.example.com does not validate example.com.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Man Ho (Certizen) Sent: Monday, October 3, 2016 2:55 AM To: Peter Bowen <pzbo...@gmail.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org <dev-security-policy@lists.mozilla.org> Subject: Re: Comodo issued a certificate for an extension On 10/3/2016 11:50 AM, Peter Bowen wrote: > 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly > defined "Authorization Domain Name", which should avoid this in the > future. Thank you for pointing me to those sections, but my confusion may be starting from the definition of "Authorization Domain Name". Does it simply mean one of the aliases of a FQDN that is specifically used to obtain authorization for that FQDN? I think an example of "Authorization Domain Name" could help me jump out from such abstraction of definition/term. Thank you. By simply reading the requirement, I feel that if I can create a CNAME record to let "www.<example.com>" pointing to "<example.com>", and I prove to a CA that I control the "www.<example.com>", then the CA should be able to issue a certificate of "<example.com>" according to those sections, correct? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
