This request from SSL.com is to include the “SSL.com Root Certification Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV Root Certification Authority RSA”, and “SSL.com EV Root Certification Authority ECC” root certificates, turn on the Email and Websites trust bits for the two non-EV roots, turn on the Websites trust bit for the two EV roots, and enable EV treatment for the two EV roots.
SSL.com is a commercial organization that provides digital certificates in over 150 countries worldwide, with the goal of expanding adoption of encryption technologies and best practices through education, tools and expertise. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1277336 BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8881939 Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8895068 * Root Certificate Download URL: RSA: https://www.ssl.com/repository/SSLcomRootCertificationAuthorityRSA.cer ECC: https://www.ssl.com/repository/SSLcomRootCertificationAuthorityECC.cer EV RSA R2: hhttps://www.ssl.com/repository/SSLcom-RootCA-EV-RSA-4096-R2.pem EV ECC: www.ssl.com/repository/SSLcomEVRootCertificationAuthorityECC.cer * Documents are in English https://www.ssl.com/repository/ CP/CPS: https://www.ssl.com/app/uploads/2017/06/SSLcom_CP_CPS_Version_1_2_1.pdf * CA Hierarchy: The SSL.com root certificates currently only have internally-operated intermediate certificates. These root certs have not been cross-signed by any other CA. It is possible that these root certs may issue externally operated subCA in the future, but SSL.com states that they will comply to Mozilla's Root CA Program and be either technically constrained or publicly disclosed and audited. * This request is to turn on the Email and Websites trust bits for the two non-EV roots, turn on the Websites trust bit for the two EV roots, and enable EV treatment for the two EV roots. ** Organization and Identity Verification Procedures are described in section 3.2 of the CP/CPS. Section 3.2.2.1: If the Subject Identity Information is to include the name or address of an organization, SSL.com shall verify the identity and address of the Applicant. This verification shall use documentation provided by, or through communication with, at least one of the following: 1) A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition; 2) A third party database that is periodically updated and considered a Reliable Data Source as defined in Section 3.2.2.7; 3) A site visit by SSL.com or a third party who is acting as an agent for SSL.com; or 4) An Attestation Letter, as defined in Section 1.6.1 SSL.com may use the same documentation or communication described in 1) through 4) above to verify both the Applicant’s identity and address. Alternatively, SSL.com may verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that SSL.com determines to be reliable. ** Section 3.2.2.4 defines the permitted processes and procedures for validating the Applicatn’s ownership or control of the domain. Please see the CP/CPS for further details in each section. *** 3.2.2.4.1 Validating the Applicant as a Domain Contact Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar. *** 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact Confirming the Applicant's control over the FQDN by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact. *** 3.2.2.4.3 Phone Contact with Domain Contact Confirming the Applicant's control over the requested FQDN by calling the Domain Name Registrant's phone number and obtaining a response confirming the Applicant's request for validation of the FQDN. SSL.com or Delegated Third Party MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact. Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call. *** 3.2.2.4.4 Constructed Email to Domain Contact Confirm the Applicant's control over the requested FQDN by (i) sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"), followed by an Authorization Domain Name, (ii) including a Random Value in the email, and (iii) receiving a confirming response utilizing the Random Value. *** 3.2.2.4.5 Domain Authorization Document Confirming the Applicant's control over the requested FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document. The Domain Authorization Document MUST substantiate that the communication came from the Domain Contact. SSL.com MUST verify that the Domain Authorization Document was either (i) dated on or after the date of the domain validation request or (ii) that the WHOIS data has not materially changed since a previously provided Domain Authorization Document for the Domain Name Space. *** 3.2.2.4.6 Agreed-Upon Change to Website Confirming the Applicant's control over the requested FQDN by confirming one of the following under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port *** 3.2.2.4.7 DNS Change Confirming the Applicant's control over the requested FQDN by confirming the presence of a Random Value or Request Token in a DNS TXT or CAA record for an Authorization Domain Name or an Authorization Domain Name that is prefixed with a label that begins with an underscore character. *** 3.2.2.4.8 IP Address Confirming the Applicant's control over the requested FQDN by confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the FQDN in accordance with Section 3.2.2.5. *** 3.2.2.4.9 Test Certificate Confirming the Applicant's control over the requested FQDN by confirming the presence of a non-expired Test Certificate issued by SSL.com on the Authorization Domain Name and which is accessible by SSL.com via TLS over an Authorized Port for the purpose of issuing a Certificate with the same Public Key as in the Test Certificate. *** 3.2.2.4.10. TLS Using a Random Number Confirming the Applicant's control over the requested FQDN by confirming the presence of a Random Value within a Certificate on the Authorization Domain Name which is accessible by SSL.com via TLS over an Authorized Port. Also see: ** 3.2.2.5 Authentication for an IP Address ** 3.2.2.6 Wildcard Domain Validation ** 3.2.2.7 Data Source Accuracy ** 3.2.2.8 CAA Records ** 3.2.2.9 Validation of Email Address Control Where required, SSL.com or an RA may verify an Applicant's control of any email address listed in a certificate via a challenge and response or other approved method. Any challenge email sent by SSL.com to the Applicant must include a Random Value. ** 3.2.5 Validation of authority * EV Policy OID: SSL.com EV Root Certification Authority RSA R2: 2.23.140.1.1 SSL.com EV Root Certification Authority ECC: 2.23.140.1.1 * Test Websites SSL.com Root Certification Authority RSA https://test-ov-rsa.ssl.com https://revoked-rsa-dv.ssl.com https://expired-rsa-dv.ssl.com SSL.com Root Certification Authority ECC https://test-ov-ecc.ssl.com https://revoked-ecc-dv.ssl.com https://expired-ecc-dv.ssl.com SSL.com EV Root Certification Authority RSA R2: https://test-ev-rsa.ssl.com https://expired-ev-rsa.ssl.com https://revoked-ev-rsa.ssl.com SSL.com EV Root Certification Authority ECC https://test-ev-ecc.ssl.com/ https://revoked-ecc-ev.ssl.com https://expired-ecc-ev.ssl.com * CRL URLs: http://crls.ssl.com/ssl.com-rsa-RootCA.crl http://crls.ssl.com/ssl.com-ecc-RootCA.crl http://crls.ssl.com/SSLcom-RootCA-EV-RSA-4096-R2.crl http://crls.ssl.com/ssl.com-EVecc-RootCA.crl CP/CPS section 4.9.10: For the status of Subscriber Certificates: SSL.com shall update information provided via an Online Certificate Status Protocol at least every single (1) day. OCSP responses from this service must have a maximum expiration time of seven (7) days. * OCSP URLs: http://ocsps.ssl.com * Audit: Annual audits are performed by BDO according to the WebTrust for CA and BR audit criteria. WTCA: https://www.ssl.com/app/uploads/2017/07/SSL-COM-WTCA-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf WTBR: https://www.ssl.com/app/uploads/2017/07/SSL-COM-WTBR-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf WTEV: https://cert.webtrust.org/SealFile?seal=2286&file=pdf * Potentially Problematic Practices (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices) ** Delegation of Domain / Email validation to third parties ** Allowing external entities to operate subordinate CAs *** CP/CPS session 1.3.2: SSL.com may delegate the performance of all or any part of these requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2 of this CP/CPS. Before SSL.com authorizes a Delegated Third Party to perform a delegated function, SSL.com shall contractually require the Delegated Third Party to: 1) Meet the qualification requirements of Section 5.3.1, when applicable, to the delegated function; 2) Retain documentation in accordance with Section 5.5.2; 3) Comply with (a) the SSL.com CP/CPS or (b) the Delegated Third Party’s (SSL.comapproved) CP/CPS; 4) Abide by the other provisions (i.e. Contract between SSL.com and Delegated Third Parties) that are applicable to the delegated function. *** CP/CPS section 1.3.5: SSL.com shall contractually guarantee that all applicable requirements specified in the CP/CPS, including satisfaction of EV Guidelines, are met in all contracts with Subordinate CAs, external RAs, Enterprise RAs, and/or subcontractors that involve or relate to the issuance or maintenance of Certificates. For Technically Constrained Subordinate CAs allowed to issue SSL/TLS Certificates in line with Section 7.1.5, SSL.com shall enforce these obligations and internally audit each such entity for compliance with this CP/CPS on an annual basis per Section 8.7. For Subordinate CAs that are not Technically Constrained, SSL.com shall require an annual audit performed by a Qualified Auditor per Section 8.4. *** CP/CPS session 3.2.2.4: SSL.com shall confirm that, as of the date the Certificate issuance, either SSL.com or a Delegated Third Party has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below. . This begins the discussion of the request from SSL.com to include the “SSL.com Root Certification Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV Root Certification Authority RSA R2”, and “SSL.com EV Root Certification Authority ECC” root certificates, turn on the Email and Websites trust bits for the two non-EV roots, turn on the Websites trust bit for the two EV roots, and enable EV treatment for the two EV roots. Aaron _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
