> We can restart the discussion and please review their updated documents and > comment in this discussion if you have further questions or concerns about > this request. > After reviewing Comsign's updated CPS and related documents, I have the following comments:
== Good == - CPS follows RFC 3647 and includes a table of revisions - CAA requirements are met - Audit reports cover a full year - Contact information for problem reporting is clearly stated in section 4.9.3 - Aside from what I’ve listed below, all of the issues reported earlier by Ryan Sleevi appear to have been addressed. == Meh == - Fingerprints in the audit reports are SHA-1; should be SHA-256 - The CPS is located at https://www.comsign.co.il/CPS under the heading “CPS – in accordance with the Electronic Signature Law of Israel” but earlier discussions indicate that SSL certificates aren’t covered by this law, in which case it’s not clear what the difference is between this CPS and the one listed under “CPS – for - Certificates that are not under the Electronic Signature Law of Israel” on the same page. - None of the subordinate CAs contain an EKU extension. [1] - Section 3.1.3 states that “Comsign will not issue an Electronic Certificate bearing a nickname of the Subscriber or one that does not state the name of the Subscriber” but section 7.1.2.3(iv) shows a DV certificate profile that doesn’t name the Subscriber. If the term ‘Electronic Certificate’ is intended to only apply to non-SSL certificates, then the definition should be clarified. - The domain validation methods specified in CPS section 3.2.2.4 are nearly cut-and-paste from the BRs, so this section provides little information that can be used to evaluate Comsign’s domain validation practices. [2] - None of the four intermediates shown in the root hierarchy diagram [3] are disclosed in CCADB at this time (this isn’t required until the root is included). There are (at least) 3 different “ComSign Organizational CA” subordinate CA certificates with the same public key that should be disclosed. == Bad == - The Hebrew version of the CPS at https://www.comsign.co.il/repository/ is version 3.1 while the English version on the same page is 4.0, so I assume that these are different documents. I see nothing in the English version stating that it takes precedence over the Hebrew version. - Section 1 of the CPS doesn’t clearly state that Comsign adheres to the **latest** version of the BRs, nor that the BRs take precedence over the CPS (BR 2.2). - The Creative Commons license is not listed in the CPS (Mozilla policy 3.3). - Audit reports don’t list any intermediates covered by the audit (Mozilla policy 3.1.4). - 3.2.2.4 states “All authentication and verification procedures in this sub-section shall be performed either directly by Comsign's personnel (RAs) or by Comsign's authorized representatives.”. There is no definition of who can be an ‘authorized representative’, but in this context it sounds like a Delegated Third Party, and CAs are not permitted to delegate domain validation (BR 1.3.2). - CPS 3.2.2.4 states: “For issuing certificates to organizations requesting SSL certificates,Comsign performs domain name owners verification to detect cases of homographic spoofing of IDNs. Comsign employs an automated or manual process that searches various ‘whois’ services to find the owner of a particular domain. A search failure result is flagged and the RA rejects the Certificate Request. Additionally, the RA rejects any domain name that visually appears to be made up of multiple scripts within one hostname label.” How does a WHOIS check or a human review effectively detect mixed scripts in a label? I don’t believe this is an effective safeguard against homograph spoofing. - The audit reports supplied cover the period from 2015-04-27 to present. This doesn’t appear to satisfy the requirement for an unbroken sequence of audit periods back to the issuance of the first certificate on 2014-10-26 (refer to earlier discussion in this thread). Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Usage_of_Appropriate_Constraints [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership [3] https://bug675060.bmoattachments.org/attachment.cgi?id=8608692 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
