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