Re: SSL.com root inclusion request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
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, 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
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.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.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). > > 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 applicabl
Re: SSL.com root inclusion request
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... Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
On Thu, Oct 12, 2017 at 3:54 PM, Andrew R. Whalley via dev-security-policy 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" > > 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 EVGs don't use the PSL, they specify third or higher. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
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 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
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 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 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-security-policy@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 > > > > > I will greatly appreciate it if someone will review and comment on this > root inclusion request from SSL.com. > > Thanks, > Kathleen > > > ___ > 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
Re: SSL.com root inclusion request
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. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SSL.com root inclusion request
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) recei
