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.
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
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
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 184.108.40.206.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 220.127.116.11.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 18.104.22.168 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
* Section 22.214.171.124.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
* Section 4.8.1 fails to enumerate the methods listed in Section 126.96.36.199
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
* 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