info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSL.com root inclusion request
1,007 views
Skip to first unread message
Aaron Wu
Aug 8, 2017, 5:26:02 PM8/8/17
to mozilla-dev-s...@lists.mozilla.org
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
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
Kathleen Wilson
Sep 8, 2017, 2:08:13 PM9/8/17
to mozilla-dev-s...@lists.mozilla.org
On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> 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
>
I will greatly appreciate it if someone will review and comment on this root inclusion request from SSL.com.
> 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
>
Thanks,
Kathleen
Andrew R. Whalley
Oct 12, 2017, 6:55:00 PM10/12/17
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Greetings,
I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
1.3.
CA diagrams are useful, thanks.
1.3.2
"SSL.com may delegate the performance of *all or any* part of these
requirements to a Delegated Third Party" though the BRs preclude sections
3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion
on this topic.
1.3.2.1
"may contractually authorize the Subject of a specified Valid EV
Certificate to perform the RA function and authorize SSL.com to issue
additional EV Certificates at *third and higher domain levels* that are
contained within the domain of the original EV Certificate"
This assumes the number of labels in domains appearing in the Public Suffix
List, which is inadvisable.
1.5.5
SSL.com CP/CPS annual review: Might be worth making it explicit that there
will be a CP/CPS version number bump even if there is no change, per
Mozilla Root Store Policy v 2.5 §3.3
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
out procedures under §3.2.2.4 (even though it is allowed in this section of
the BRs) - See ballot 215 which hopes to clear up any confusion on this
topic.
3.2.4
"SSL.com does not verify information contained in the Organization Unit
(OU) field in any certificate request"
Section 7.1.4.2.1 of the BRs states: "The CA SHALL implement a process that
prevents an OU attribute from including a name, DBA, tradename, trademark,
address, location, or other text that refers to a specific natural person
or Legal Entity unless the CA has verified this information in accordance
with Section 3.2 and the Certificate also contains
subject:organizationName, , subject:givenName, subject:surname,
subject:localityName, and subject:countryName attributes, also verified in
accordance with Section 3.2.2.1."
4.9.2
"Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"
It's not immediately clear what non-subscribers are referred to in in §4.9.1
7.1.2.2
"f. nameConstraints (optional)
If present, this extension should not be marked critical*."
Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked
critical."
"It is forbidden for Intermediate CAs to issue end-entity Certificates
which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection
(1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key
usages."
Good
9.12.1/2
"Minor changes (e.g. correction of grammatical, syntactical, spelling
errors) may, at SSL.com's sole discretion, be carried out without any prior
notice and without OID modification."
Even if the version number isn't changed, it would be good to ensure all
modifications, however minor, are listed in the Version Control table of
§1.2.1
--
Cheers,
Andrew
On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
1.3.
CA diagrams are useful, thanks.
1.3.2
"SSL.com may delegate the performance of *all or any* part of these
requirements to a Delegated Third Party" though the BRs preclude sections
3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion
on this topic.
1.3.2.1
"may contractually authorize the Subject of a specified Valid EV
Certificate to perform the RA function and authorize SSL.com to issue
additional EV Certificates at *third and higher domain levels* that are
contained within the domain of the original EV Certificate"
This assumes the number of labels in domains appearing in the Public Suffix
List, which is inadvisable.
1.5.5
SSL.com CP/CPS annual review: Might be worth making it explicit that there
will be a CP/CPS version number bump even if there is no change, per
Mozilla Root Store Policy v 2.5 §3.3
3.2.2.4
"SSL.com shall confirm that, as of the date the Certificate issuance,
Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least
one of the methods listed below."
Section 1.3.2 of the BRs prohibits Delegated Third Parties from carrying
one of the methods listed below."
out procedures under §3.2.2.4 (even though it is allowed in this section of
the BRs) - See ballot 215 which hopes to clear up any confusion on this
topic.
3.2.4
"SSL.com does not verify information contained in the Organization Unit
(OU) field in any certificate request"
Section 7.1.4.2.1 of the BRs states: "The CA SHALL implement a process that
prevents an OU attribute from including a name, DBA, tradename, trademark,
address, location, or other text that refers to a specific natural person
or Legal Entity unless the CA has verified this information in accordance
with Section 3.2 and the Certificate also contains
subject:organizationName, , subject:givenName, subject:surname,
subject:localityName, and subject:countryName attributes, also verified in
accordance with Section 3.2.2.1."
4.9.2
"Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"
It's not immediately clear what non-subscribers are referred to in in §4.9.1
7.1.2.2
"f. nameConstraints (optional)
If present, this extension should not be marked critical*."
Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked
critical."
"It is forbidden for Intermediate CAs to issue end-entity Certificates
which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection
(1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key
usages."
Good
9.12.1/2
"Minor changes (e.g. correction of grammatical, syntactical, spelling
errors) may, at SSL.com's sole discretion, be carried out without any prior
notice and without OID modification."
Even if the version number isn't changed, it would be good to ensure all
modifications, however minor, are listed in the Version Control table of
§1.2.1
--
Cheers,
Andrew
On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> > 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
> >
>
>
> 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
> >
>
>
> I will greatly appreciate it if someone will review and comment on this
> root inclusion request from SSL.com.
>
> Thanks,
> Kathleen
>
>
> _______________________________________________
> root inclusion request from SSL.com.
>
> Thanks,
> Kathleen
>
>
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Nick Lamb
Oct 12, 2017, 8:21:35 PM10/12/17
to mozilla-dev-s...@lists.mozilla.org
On Thursday, 12 October 2017 23:55:00 UTC+1, Andrew R. Whalley wrote:
> This assumes the number of labels in domains appearing in the Public Suffix
> List, which is inadvisable.
An illustrative example, probably worth using by any CAs which have humans involved in the domain verification process as software engineers or directly as agents for individual verifications is www.me.uk
> This assumes the number of labels in domains appearing in the Public Suffix
> List, which is inadvisable.
me.uk is a Public Suffix operated by Nominet in the UK alongside more famous examples like .gov.uk or .co.uk and so www.me.uk is simply one of a great many different sub-domains within that suffix owned by completely unrelated parties. In that particular case Adrian "RevK" Kennard the owner of a small but significant UK Service Provider and someone who enjoys making mischief.
Kennard doesn't own or run .me.uk and has no legitimate claim over most other names in that suffix (obvious exceptions include revk.me.uk) but he received the www.me.uk name because nobody saw fit to prohibit it from being registered under this suffix and he was the first to ask. And so it sure _looks_ to anyone who hasn't consulted the Public Suffix List and isn't familiar with the history of these names, as though Kennard's "www.me.uk" is the web site of an entire domain under Kennard's control named simply me.uk
Peter Bowen
Oct 13, 2017, 1:01:46 AM10/13/17
to Andrew R. Whalley, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
On Thu, Oct 12, 2017 at 3:54 PM, Andrew R. Whalley via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
>
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
>
> 1.3.2.1
>
> "may contractually authorize the Subject of a specified Valid EV
> Certificate to perform the RA function and authorize SSL.com to issue
> additional EV Certificates at *third and higher domain levels* that are
> contained within the domain of the original EV Certificate"
>
>
> "may contractually authorize the Subject of a specified Valid EV
> Certificate to perform the RA function and authorize SSL.com to issue
> additional EV Certificates at *third and higher domain levels* that are
> contained within the domain of the original EV Certificate"
>
> This assumes the number of labels in domains appearing in the Public Suffix
> List, which is inadvisable.
This is taken directly from the EV Guidelines section 14.2.2. The
> List, which is inadvisable.
EVGs don't use the PSL, they specify third or higher.
Gervase Markham
Oct 13, 2017, 10:41:41 AM10/13/17
to Peter Bowen, Andrew R. Whalley, Kathleen Wilson
On 13/10/17 06:01, Peter Bowen wrote:
> This is taken directly from the EV Guidelines section 14.2.2. The
> EVGs don't use the PSL, they specify third or higher.
Er, we should fix that...
> This is taken directly from the EV Guidelines section 14.2.2. The
> EVGs don't use the PSL, they specify third or higher.
Gerv
Leo Grove
Oct 13, 2017, 2:58:17 PM10/13/17
to mozilla-dev-s...@lists.mozilla.org
Hello and thank you Andrew for taking the time to review and/or comment on the SSL.com CP/CPS v1.2.1 for any potential issues. I will be more than happy to answer your questions below:
On Thursday, October 12, 2017 at 5:55:00 PM UTC-5, Andrew R. Whalley wrote:
> Greetings,
>
> I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
>
> 1.3.
>
> CA diagrams are useful, thanks.
You're welcome :-)
>
> 1.3.2
>
> "SSL.com may delegate the performance of *all or any* part of these
> requirements to a Delegated Third Party" though the BRs preclude sections
> 3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion
> on this topic.
As voting members of the CA/Browser Forum, we monitor all changes that take place in the Baseline Requirements as soon as the Forum passes a ballot. This and other sections of our CP/CPS will be revised to align with the latest Baseline Requirements.
Accordingly, we will remove allowance of validation of domain authorization or control and authentication for IP addresses for Delegated Third Parties. Our new language will be:
"With the exception of sections 3.2.2.4 and 3.2.2.5, SSL.com may delegate the performance of all or any part of these requirements to a Delegated Third Party, apart from the validations of domain authorization or control and IP address authentication as described in Sections 3.2.2.4 and 3.2.2.5 which have to be performed by the CA."
>
> 1.3.2.1
>
> "may contractually authorize the Subject of a specified Valid EV
> Certificate to perform the RA function and authorize SSL.com to issue
> additional EV Certificates at *third and higher domain levels* that are
> contained within the domain of the original EV Certificate"
>
> This assumes the number of labels in domains appearing in the Public Suffix
> List, which is inadvisable.
As Peter Bowen mentioned, this language has been taken directly from the EV Guidelines Section 14.2.2. However, according to the Baseline Requirements and the definition of "Base Domain Name" (section 1.6.1), public suffixes alone are not allowed. We could add some language in a future update to make this more explicit, and we could even discuss this in the CA/B Forum mailing list on changing the EVG in order to fix this problem.
>
> 1.5.5
>
> SSL.com CP/CPS annual review: Might be worth making it explicit that there
> will be a CP/CPS version number bump even if there is no change, per
> Mozilla Root Store Policy v 2.5 §3.3
Not a problem. We already implement this process, but we will also change the language of 1.5.5 from
"Even if there is no compulsory reason for a change in the SSL.com CP/CPS, the PMA shall perform a management and technical review of the CP/CPS and all related documents at least once a year in an effort to improve policies and practices."
to
"Even if there is no compulsory reason for a change in the SSL.com CP/CPS, the PMA shall perform a management and technical review of the CP/CPS and all related documents at least once a year in an effort to improve policies and practices and update the CP/CPS version number and update the version control table in section 1.2.1".
> 3.2.4
>
> "SSL.com does not verify information contained in the Organization Unit
> (OU) field in any certificate request"
>
> Section 7.1.4.2.1 of the BRs states: "The CA SHALL implement a process that
> prevents an OU attribute from including a name, DBA, tradename, trademark,
> address, location, or other text that refers to a specific natural person
> or Legal Entity unless the CA has verified this information in accordance
> with Section 3.2 and the Certificate also contains
> subject:organizationName, , subject:givenName, subject:surname,
> subject:localityName, and subject:countryName attributes, also verified in
> accordance with Section 3.2.2.1."
We actually implement this process, as it is stated in section 7.1.4.2.2(i) of our CP/CPS. We will add a reference in section 3.2.4 to point to 7.1.4.2.2 (i).
>
> "It is forbidden for Intermediate CAs to issue end-entity Certificates
> which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection
> (1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key
> usages."
>
> Good
>
> 9.12.1/2
>
> "Minor changes (e.g. correction of grammatical, syntactical, spelling
> errors) may, at SSL.com's sole discretion, be carried out without any prior
> notice and without OID modification."
>
> Even if the version number isn't changed, it would be good to ensure all
> modifications, however minor, are listed in the Version Control table of
> §1.2.1
>
Our plan is to use the version control table of Section 1.2.1 to reflect substantial changes to the policy document (including the annual review that forces the version number to increment), more than a simple typo. We feel that fixing typos and indicating this as a substantial change in table 1.2.1 would be of no real interest to the Relying Parties.
However, we shall note minor non-substantive changes and corrections between versions in section 1.2.1.
> --
>
> Cheers,
>
> Andrew
>
Regards,
Leo
On Thursday, October 12, 2017 at 5:55:00 PM UTC-5, Andrew R. Whalley wrote:
> Greetings,
>
> I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:
>
> 1.3.
>
> CA diagrams are useful, thanks.
>
> 1.3.2
>
> "SSL.com may delegate the performance of *all or any* part of these
> requirements to a Delegated Third Party" though the BRs preclude sections
> 3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion
> on this topic.
Accordingly, we will remove allowance of validation of domain authorization or control and authentication for IP addresses for Delegated Third Parties. Our new language will be:
"With the exception of sections 3.2.2.4 and 3.2.2.5, SSL.com may delegate the performance of all or any part of these requirements to a Delegated Third Party, apart from the validations of domain authorization or control and IP address authentication as described in Sections 3.2.2.4 and 3.2.2.5 which have to be performed by the CA."
>
> 1.3.2.1
>
> "may contractually authorize the Subject of a specified Valid EV
> Certificate to perform the RA function and authorize SSL.com to issue
> additional EV Certificates at *third and higher domain levels* that are
> contained within the domain of the original EV Certificate"
>
> This assumes the number of labels in domains appearing in the Public Suffix
> List, which is inadvisable.
>
> 1.5.5
>
> SSL.com CP/CPS annual review: Might be worth making it explicit that there
> will be a CP/CPS version number bump even if there is no change, per
> Mozilla Root Store Policy v 2.5 §3.3
"Even if there is no compulsory reason for a change in the SSL.com CP/CPS, the PMA shall perform a management and technical review of the CP/CPS and all related documents at least once a year in an effort to improve policies and practices."
to
"Even if there is no compulsory reason for a change in the SSL.com CP/CPS, the PMA shall perform a management and technical review of the CP/CPS and all related documents at least once a year in an effort to improve policies and practices and update the CP/CPS version number and update the version control table in section 1.2.1".
>
> 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."
>
> Section 1.3.2 of the BRs prohibits Delegated Third Parties from carrying
> out procedures under §3.2.2.4 (even though it is allowed in this section of
> the BRs) - See ballot 215 which hopes to clear up any confusion on this
> topic.
>
Please see our response for sec 1.3.2 earlier
> 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."
>
> Section 1.3.2 of the BRs prohibits Delegated Third Parties from carrying
> out procedures under §3.2.2.4 (even though it is allowed in this section of
> the BRs) - See ballot 215 which hopes to clear up any confusion on this
> topic.
>
> 3.2.4
>
> "SSL.com does not verify information contained in the Organization Unit
> (OU) field in any certificate request"
>
> Section 7.1.4.2.1 of the BRs states: "The CA SHALL implement a process that
> prevents an OU attribute from including a name, DBA, tradename, trademark,
> address, location, or other text that refers to a specific natural person
> or Legal Entity unless the CA has verified this information in accordance
> with Section 3.2 and the Certificate also contains
> subject:organizationName, , subject:givenName, subject:surname,
> subject:localityName, and subject:countryName attributes, also verified in
> accordance with Section 3.2.2.1."
>
> 4.9.2
>
> "Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"
>
> It's not immediately clear what non-subscribers are referred to in in §4.9.1
4.9.2 addresses who may request revocation, and non-subscribers (and the reasons they might request revocation) are described in 3.4.2. Some of these reasons are clearly only for Subscribers. For example, criteria 4.9.1.1 (1), is only applicable to a Subscriber. Criteria 4.9.9.1 (4), is applicable by both Subscribers and non-Subscribers (any third-party can send a revocation request according to 4.9.3.3).
> 4.9.2
>
> "Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"
>
> It's not immediately clear what non-subscribers are referred to in in §4.9.1
>
> 7.1.2.2
>
> "f. nameConstraints (optional)
>
> If present, this extension should not be marked critical*."
>
> Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked
> critical."
Currently, the BRs allow for this exception to RFC5280 in order to increase compatibility with various application software suppliers. For the moment, SSL.com has decided that whenever there is a case we need to issue CA Certificates with name constraints, this extension will not be marked "Critical" in order to avoid compatibility issues. In the future, this may change and our CP/CPS will be updated, especially if this change is mandated in an updated version of the BRs.
> 7.1.2.2
>
> "f. nameConstraints (optional)
>
> If present, this extension should not be marked critical*."
>
> Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked
> critical."
>
> "It is forbidden for Intermediate CAs to issue end-entity Certificates
> which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection
> (1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key
> usages."
>
> Good
>
> 9.12.1/2
>
> "Minor changes (e.g. correction of grammatical, syntactical, spelling
> errors) may, at SSL.com's sole discretion, be carried out without any prior
> notice and without OID modification."
>
> Even if the version number isn't changed, it would be good to ensure all
> modifications, however minor, are listed in the Version Control table of
> §1.2.1
>
However, we shall note minor non-substantive changes and corrections between versions in section 1.2.1.
> --
>
> Cheers,
>
> Andrew
>
Regards,
Leo
Gervase Markham
Oct 16, 2017, 6:38:03 AM10/16/17
to Peter Bowen, Andrew R. Whalley, Kathleen Wilson
On 13/10/17 15:41, Gervase Markham wrote:
> Er, we should fix that...
Well, actually it's scoped as being inside the original EV cert request,
> Er, we should fix that...
so there's probably no harm in practice. If any CAB Forum member wants
to fix this small error, great, but I've got too many other ballot ideas
to juggle.
Gerv
Kathleen Wilson
Oct 16, 2017, 6:15:07 PM10/16/17
to mozilla-dev-s...@lists.mozilla.org
Thank you to those of you who reviewed and commented on this 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.
I believe that all of the questions and concerns that were raised in this discussion have been properly addressed.
As a result of this discussion, there are a couple of minor changes that the CA plans to make in their CP/CPS, but those are not show-stoppers.
Therefore, I am closing this discussion and I will state my intent to approve this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1277336
Any further follow-up should be added directly to the bug.
Thanks,
Kathleen
I believe that all of the questions and concerns that were raised in this discussion have been properly addressed.
As a result of this discussion, there are a couple of minor changes that the CA plans to make in their CP/CPS, but those are not show-stoppers.
Therefore, I am closing this discussion and I will state my intent to approve this request in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1277336
Any further follow-up should be added directly to the bug.
Thanks,
Kathleen
0 new messages