Reposting this, as Kathleen confirmed it made it to her, but not the list: On Thu, December 10, 2015 12:01 pm, Kathleen Wilson wrote: > This request is to include the "ComSign Global Root CA" root > certificate, and enable the Websites and Email trust bits. This root > will eventually replace the "ComSign CA" root certificate that is > currently included in NSS, and was approved in bug #420705. > > ComSign is owned by Comda, Ltd., and was appointed by the Justice > Ministry as a CA in Israel in accordance with the Electronic Signature > Law 5761-2001. ComSign has issued electronic signatures to thousands > of business people in Israel. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=675060 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8697333
Kathleen, I've attempted to complete a review of the CPS as if this was a new inclusion. I did not review the specific SSL CP, as I found enough concerning information in the CPS that it did not seem to warrant the time or energy. Similar to past discussions, I've attempted to clarify this into three sections - Good (which I believe should serve as examples for other CAs), Meh (which are undesirable or inadvisable, but not strictly forbidden, or which require further clarification), and Bad (things which I believe are inconsistent with Mozilla policy or the interest of Mozilla users) Per your email, I focused on http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf as the version of the CPS to review == Good == * Section 3.2.8 thoroughly details the methods for domain name validation. While I realize others have raised concerns (which I believe are unfounded and not relevant to the discussion, as they're permitted by the BRs), I do believe it's a positive sign to include such throughness within a CP/CPS. * Section 4.1.1 provides substantial documentation about the roles and parties involved in the issuance of certificates. == Meh == * Page 7 of the CPS clearly documents the Hebrew version of the document as binding. While this is likely relevant to their role within Israel of issuing certificates qualified under the national scheme, to the Mozilla community, I believe the English version is of interest and relevance. For example, does Page 7 imply that ComSign may unilaterally update the Hebrew version, without a corresponding update to the English version? Does that facilitate Mozilla community review? At a minimum, the English version should be seen as 'as binding' as the Hebrew version, which provides some assurances about the consistency therein. * Section 2.1 states that "The list of revoked certificates containing their serial number and date of revocation is accessible for controlled viewing." This implies that the revocation information is not freely and publicly available, which contradicts the statements about the CRLs and OCSP information being freely publicized within the Repository. Could ComSign clarify what is meant by this section? * Section 2.3 disclaims any responsibility if CRLs are not fetched every time, every verification. This defeats many of the purposes of CRLs having validity periods, and seems to discourage a scalable infrastructure. * Section 3.2.5 indicates that certificate renewal is permitted. ComSign should be aware that for the purposes of the Mozilla policy, the act of renewal is seen as if it was a new certificate issuance. That is, at time of "renewal", the renewed certificate must comply with all current and in-force policies - it CANNOT violate the requirements in effect at the time of signing (for example, a SHA-1 certificate CANNOT be renewed after 2016-01-01, as this would be new issuance) * Section 3.2.8.2.2 has a typo (trough -> through) * Sections 7.1 - 7.4 are unclear as to whether the EKUs enumerated represent examples (and thus, issued certificates may include other such EKUs), as the section titles imply, or whether they represent an exhaustive list of what can appear within that field. If it is merely exemplary, this does represent a concern as non-SSL certificates may inadvertently be enabled for SSL if the wrong EKUs are presented. * Section 7.1.4 documents multiple CRL locations may appear, but ComSign should be aware that virtually all major clients ignore these multiple URLs and will only check a single URL. Thus, it seems inefficient and wasteful to encode as such. == Bad == * The CPS does not appear to conform to either RFC 2527 or RFC 3647, as required by the Baseline Requirements. The CPS seemingly follows 3647, based on the rough outline, but Sections 9 and 10 definitely diverge. The document states they were formulated according to ETSI TS 456, but that does not seem an acceptable form. * Examples of such divergence: Sections 1.3.3, 1.4.*, 3.2 * Section 3.2.6.1.2 does not seem to permit revocation based on demonstrating proof of possession of a private key (which would seem important if the customer loses the revocation code), nor does it permit revocation based on writing (which MUST be supported, per 4.9.1.1 of the Baseline Requirements v.1.3.1) * Section 10.15.1 reserves ComSign the right to unilaterally employ additional methods at ComSign's discretion. This seems to run counter to the Mozilla Policy which obligates the CA to notify Mozilla of any meaningful changes to the CP/CPS. * ComSign fails to document and operate test URLs compliant with Section 2.2 of the Baseline Requirements, v1.3.1. * ComSign has failed to document how CAA records are handled. While ComSign was audited to v1.1.6 of the Baseline Requirements, and CAA was not required until Ballot 125, which was incorporated into 1.2.0, ComSign states in Section 10 that they adhere to the latest published version of the Baseline Requirements (as the BRs require), which is demonstrably false. * Section 3.2.8.1.3 employs a validation method that, while permitted by the Baseline Requirements at present, is recognized as a security risk and is quite contentiously discussed within the CA/Browser Forum's Validation Working Group. The use of methods like this have been used to cause misissuance in the past, and for that reason the Mozilla community should be suspicious about endorsing it, even if the BRs permit it. * Section 3.3.4 fails to document procedures for rejecting certificate requests for the reasons documented in Section 4.1.1 of v1.3.1 of the Baseline Requirements. * Section 4.8.1 fails to enumerate the methods listed in Section 4.9.1.1 of v1.3.1 of the Baseline Requirements. * Contrary to Section 4.9.3 of the Baseline Requirements, ComSign does not appear to have documented a means to report suspected misissuance or compromise. * Section 10.15.15 permits the suspension of certificates, which is contrary to Section 4.9.3 of v1.3.1 of the Baseline Requirements. I suspect that, on a more detailed analysis, one might find more aspects of BR non-compliance. The structure of the CPS, and it's use of a non-standard format, makes it exceptionally difficult to align ComSign's stated practices with the requirements of the Baseline Requirements. My recommendations, based on the failure of ComSign to routinely update their practices and documentation to adhere to the developments within the CA/Browser Forum, despite their CPS stating they do, would be to refuse this renewal request and, given how long such requirements have existed within the Baseline Requirements, to recommend that ComSign be scheduled for removal, consistent with https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
