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 applicable to a Subscriber. Criteria 4.9.9.1 (4), is applicable by both Subscribers and non-Subscribers (any third-party can send a revocation request according to 4.9.3.3). > > 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." Currently, the BRs allow for this exception to RFC5280 in order to increase compatibility with various application software suppliers. For the moment, SSL.com has decided that whenever there is a case we need to issue CA Certificates with name constraints, this extension will not be marked "Critical" in order to avoid compatibility issues. In the future, this may change and our CP/CPS will be updated, especially if this change is mandated in an updated version of the BRs. > > "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 > Our plan is to use the version control table of Section 1.2.1 to reflect substantial changes to the policy document (including the annual review that forces the version number to increment), more than a simple typo. We feel that fixing typos and indicating this as a substantial change in table 1.2.1 would be of no real interest to the Relying Parties. However, we shall note minor non-substantive changes and corrections between versions in section 1.2.1. > -- > > Cheers, > > Andrew > Regards, Leo _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
