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 < [email protected]> 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
