I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:


CA diagrams are useful, thanks.


" may delegate the performance of *all or any* part of these
requirements to a Delegated Third Party" though the BRs preclude sections and - See ballot 215 which hopes to clear up any confusion
on this topic.

"may contractually authorize the Subject of a specified Valid EV
Certificate to perform the RA function and authorize 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 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

" shall confirm that, as of the date the Certificate issuance,
either *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 § (even though it is allowed in this section of
the BRs) - See ballot 215 which hopes to clear up any confusion on this


" does not verify information contained in the Organization Unit
(OU) field in any certificate request"

Section 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"


"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

"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

"It is forbidden for Intermediate CAs to issue end-entity Certificates
which blend the serverAuth (, emailProtection
( and codeSigning ( extended key



"Minor changes (e.g. correction of grammatical, syntactical, spelling
errors) may, at'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




On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy <> wrote:

> On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> > This request from is to include the “ Root Certification
> Authority RSA”, “ Root Certification Authority ECC”, “ EV
> Root Certification Authority RSA”, and “ 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.
> >
> > 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:
> >
> >
> > BR Self Assessment is here:
> >
> >
> > Summary of Information Gathered and Verified:
> >
> >
> I will greatly appreciate it if someone will review and comment on this
> root inclusion request from
> Thanks,
> Kathleen
> _______________________________________________
> dev-security-policy mailing list

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

dev-security-policy mailing list

Reply via email to