Re: SSL.com root inclusion request

2017-10-16 Thread Kathleen Wilson via dev-security-policy
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

2017-10-12 Thread Andrew R. Whalley via dev-security-policy
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


SSL.com root inclusion request

2017-08-08 Thread Aaron Wu via dev-security-policy
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)