Hello, In response to the issues raised by Mr. Sleevi, we are making a number of changes in to ComSign's CPS. Some of the issues raised here will be addressed by the changes in the CPS, while others will remain the same because we feel that they do not represent problems with our compliance to the Mozilla Policy.
Listed here are all of the replies in order of Mr. Sleevi's remarks (and with the division between 'Meh' and 'Bad'). The draft of the revised CPS can be viewed in this address: "http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf" It includes most of the suggested changed (red-lined), but it still has the existing CPS structure. We are planning to change the structure and order of sections as well. Also, I would like to thank Mr. Sleevi, since this is an opportunity for us to improve our CPS and do some serious housekeeping, which we may not have done without his objections. > == 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. The Hebrew version of this CPS is binding in regards to matters of Israeli law and regulations, specifically for the purpose of issuing personal certificates in accordance with the Israeli Law of Electronic Signature - Hebrew being the formal and common language of the state of Israel. The scope of personal certificates which are bound to the Israeli law is defined by the Intermediate CA's that issue only this type of certificates - and no other types: a. ComSign Professionals CA b. ComSign Corporations CA The English version of this CPS is binding in regards to matters of SSL certificates, Code signing and International Email certificates - which are not covered by the Israeli law of Electronic Signature. The scope of certificates which are managed and operated according to the English version of this CPS is defined by the Intermediate CA that issues these certificates: c. ComSign Organizational CA These clarification will be added to the upcoming revision of the CPS and can be reviewd in the linked draft. > * 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? The language in this section is indeed vague and unclear. We are revising this paragraph to make it clear that certificate revocation is always freely and publically accessible, including the list of serial numbers of certificates that were revoked and the date and time of the revocation. This information is of course part of ComSign's signed CRL files and signed OCSP responses, as required by Mozilla's policy. > * 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. The reservation that appears in this section states that the most updated CRL is the one published by ComSign. This is pretty straight-forward: certificate may be revoked at any time, and according to some standards that we are committed to (e.g. CWA 14167-1 [RM2.2]) any revocation is reflected immediately in our CRL and OCSP service. If any client software is configured to retrieve revocation information only according to the "Next Update" field of the CRL, then it will be aware of new revocation entries some time after they are first published. > * 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) Agreed. The section regarding renewal of certificate has no precedence over other sections of the CPS which explicitly declare compliance to Mozilla's or CA/B forum's policies (e.g. validity periods). In the upcoming revision the CPS we may add a clarification stating that the policies and limitations that apply to any renewed certificate are those which are valid at the time of the renewal of the certificate. This can be reviewd in the linked draft. > * Section 3.2.8.2.2 has a typo (trough -> through) Will be corrected in the upcoming CPS version, and can be reviewd in the linked draft. > * 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. The certificate structure listed is a statement of the certificates issued by ComSign. It does not represent mere examples. This includes any EKU listed as part of the certificate structure. A clarification can be reviewd in the linked draft. > * 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. The second CRL location may be ignored by some clients, but we intend to leave it as it is. > == 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 We are planning to re-order the CPS and to apply the RFC structure in one of the next CPS revisions. > * 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) We do not support revocation based on demonstrating proof of possession of a private key. As stated in this section, we offer other means of validating the identity of a person requesting certificate revocation. Regarding a request in writing, we shell add an explicit addition to this section which lists writing as an acceptable method of requesting revocation with regards to SSL certificates. This also applies to section 4.8.1 in ComSIgn's CPS. These additions can be reviewd in the linked draft. > * 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. This is a "General Statement of Conformity" section, which states that all of ComSign's methods of performing tasks related to certificate issuance will comply with the policies of the Certification Authority / Browser Forum ("CAB Forum"). It also stated that "In case multiple or alternative methods or options are possible by the baseline requirements or guidelines ... ComSign reserves the right to choose any of the methods or options applicable". The methods themselves are listed and enumerated throw-out the CPS. There is no mention in this section of the option to add additional methods, or to make any major or meaningful change to the CP/CPS. Of course ComSign is obligated and WILL notify Mozilla of any meaningful change in its CP/CPS, but this is not relevant to this section. > * ComSign fails to document and operate test URLs compliant with Section The linked to the test URL's will be added to the CPS in the upcoming revision. They can be reviewd in the linked draft. > 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. ComSign's approach for handling CAA records will be stated in the upcoming revision of the CPS. In addition, we will amend the statement regarding the latest published version of the Baseline Requirements, to be the exact version which we comply with. Both these additions can be reviewd in the linked draft. > * 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. HTTP based Domain Control Validation is a method which is explicitly permitted by the Baseline Requirements, the Mozilla policy does not forbidden this method, and a number of well-known public CA's use this method. In accordance with these facts ComSign still reserved the right to use this method. > * 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. ComSign's systems were audited according to "WebTrust for Certification Authorities - SSL Baseline Requirements" and the requirement in section 4.1.1 of the Baseline Requirements is covered by section 4.7 of the WebTrust criteria. However, due to an oversight the adherence to this section was not included in the CPS. This will be corrected in the upcoming CPS revision, and can be reviewd in the linked draft. > * Section 4.8.1 fails to enumerate the methods listed in Section 4.9.1.1 > of v1.3.1 of the Baseline Requirements. In the upcoming CPS revision we will specify additional revocation reasons in order to comply with section 4.9.1.1. They can be reviewd in the linked draft. > * 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. In the upcoming CPS revision we will specify the means to report such information in accordance with section 4.9.3. It can be reviewd in the linked draft. > * 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. Certificate suspension is a practice used by ComSign only in relation to personal certificates and not SSL certificates. In the upcoming CPS revision we will specify a clarification for the issue. It can be reviewd in the linked draft. 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
