On Thursday, February 4, 2016 at 10:57:54 PM UTC+2, Ryan Sleevi wrote: > 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/
Thank you, We will review all of these remarks and try to answer them in an orderly fashion. Eli Spitzer | Information security & System Management | Comsign _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
