| I've reviewed the ComSign CPS and while it has a lot of legal language in it, it lacks a certain legal and technical precision that is needed in this case. For example, there is frequent use of the term "electronic certificate" which I think this document means "certificate used for electronic signatures of individual people" even though one might naturally include SSL/TLS and code signing certs as such. Similarly, the use of "SSL" in this doc might also mean "code signing" but that is less clear. I was actually surprised to find code signing in section 3.2.9 given the lack of its even being mentioned elsewhere in the doc. I can appreciate ComSign wanting to take a shortcut by adding on the SSL and code signing stuff to their already detailed doc but my recommendation is for ComSign to rework the document anyway. It's difficult for me to assess the security risk that this root might introduce to the wider Internet population. Based on my current understanding of this document I'd say the attack surface is "large", meaning there seem to be many gaps through which I might fraudulently obtain a ComSign certificate. Further, I would say the potential for harm that I can cause with that ill-gotten cert is probably "unlimited". My hope is that by reworking the CPS document ComSign can more clearly articulate what is and is not possible when it comes to issuing and using their certs and, consequently, my concerns about risk and damage are lessened. That said, I offer some specific comments: * Section 1 should stipulate that The Law was enacted by the State of Israel and has jurisdiction in the relevant Israeli territories. I'm assuming that to be the case, anyway. * I assume The Law does not apply to SSL/TLS certs. What about code signing? * There is a BR from CABF that covers code signing. I must admit I don't know the status of it but this CPS should at least acknowledge it and say if ComSign will adhere to it. * In Section 1 where it says "some procedures dealing with SSL...are not part of the Hebrew version", this statement is insufficient. For example what about code signing? Which SSL procedures are actually in the Hebrew version? This has an important implication when it comes to statements like "only the Hebrew version is binding". * I wasn't sure if a Registration Agent (Section 1.3.2) represents a business entity which is separate and apart from the ComSign company? Will ComSign bear any responsibility for the hiring of people at an RA, for example? This has a significant impact into my evaluation of the attack surface. The greater the "space" between ComSign and the RA, the greater the chance for mistakes or bad acts to happen. * Section 1.4., what are the usage terms for SSL/TLS and code signing certs? Is key sharing allowed for any of the certs issued by ComSign? If key sharing is not allowed, how is that enforced (and who does the enforcing)? * Section 3.2.8.1.1. is provably insecure and should not be used to verify ownership or control of a domain. A WHOIS record might contain an email address of a proxy and is, therefore, unreliable. The "magic" email address names might be directed to an unauthorized person and, therefore, also unreliable. * Section 3.2.8.1.3. is also provably insecure and should not be used. Changing a website proves nothing and if I'm trying to exploit an existing domain for nefarious purposes I probably have control over the website anyway. * Throughout the CPS I found some uses of the term "signature" to be ambiguous. Where possible it would be good to distinguish between a pen-and-paper signature and one that's in some electronic form. I do like that the issuance process is not completely electronic. I do have concerns with other sections in this CPS but I would like to give ComSign a chance to respond or do rework before I get overly detailed. As I stated above, my hope is that a revised CPS will demonstrate that the attack surface is more "medium" and that the potential for damage is less than "unlimited"--that it is constrained in some way.
On 12/10/15 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 > > Noteworthy points: > > * The primary documents are the CP and CPS, provided in Hebrew and > English. Only the Hebrew version of the CPS was approved by the Israeli > CA Registrar. The English version of the CPS adds procedures dealing > with SSL certificates, which are not regulated under Israel's Elctronic > Signature Law. > > Document Repository: https://www.comsign.co.il/ > Document Repository (English): https://www.comsign.co.uk/?page_id=1282 > CPS: > http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf > > * CA Hierarchy: This root has internally-operated subordinate CAs: > ComSign ISA Global CA, ComSign Corporation CA, ComSign Professionals CA, > and ComSign Organizational CA. > CA Hierarchy Diagram: > https://bugzilla.mozilla.org/attachment.cgi?id=8608692 > > * This request is to enable the Websites and Email trust bits. ComSign > is not requesting EV treatment at this time. > > ** Note: The English version of the CPS adds procedures dealing with SSL > certificates, which are not regulated under Israel's Electronic > Signature Law. So, the SSL verification procedures are only part of the > English version of the CPS. > > ** CPS section 3.2.7.1: As part of the identification process, a unique > secret code (the "Secret Code" will be mailed by Comsign to the > Applicant's e-mail address. The Secret Code will be mailed during the > coordination stage preceding the Applicant's personal appearance for the > identification process. The Applicant will provide the Secret Code to > the coordination clerk during the telephone conversation coordinating > the Applicant's personal appearance. If the provided Secret Code is > correct, the coordination clerk will transfer it to the identification > clerk together with all other data pertaining to the applicant > (including the applicant's e-mail address). > > ** CPS section 3.2.7.2: In the event of a non-coordinated visit to > Comsign offices (as well as in any other event) the identification clerk > will mail the Secret Code during the identification process (Comsign > will provide the Applicant with internet access). > > ** CPS section 3.2.7.3. The Applicant must provide the Secret Code in > the application form. The identification clerk will verify the matching > of the Secret Code in the application form with the one reported by the > coordination clerk (or by the applicant himself in a non-coordinated > visit to Comsign offices) as well as the matching of the e-mail address > in the application form with the address reported by the coordination > clerk. Alternatively, the identification clerk will verify the matching > of the Secret Code in the application form to the one mailed by the > identification clerk to the e-mail address provided by the Applicant in > the application form. > > ** CPS section 3.2.7.4: Only the e-mail address to which the verified > Secret Code was mailed will appear in the electronic certificate issued > by Comsign to the Applicant. > > ** CPS section 3.2.8.1: For issuing certificates to organizations > requesting SSL certificates, Comsign performs domain name owner > 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. > Note: Orders for major corporations, well known trademarks and financial > institutions may be queued for further security reviews prior to issuance. > In the event an order is queued for review the administrative contact > must be a full time employee of the company for successful issuance. A > verification telephone call with the administrative contact may be > required. > - Verification methods include one of the following: > *** 3.2.8.1.1 EMail-based DCV > An email is sent to an administrative contact for the required domain. > The email will contain a unique validation code and link. Clicking the > link and entering the code will prove domain control. > Valid email addresses are: Any email address listed in the "whois" > records. The following generic admin type email addresses AT the domain > for which the certificate is being applied: admin@, administrator@, > postmaster@, hostmaster@, webmaster@ > *** 3.2.8.1.2 DNS-based DCV > The CSR that Comsign receives from the Applicant will be hashed. The > hash values are provided to the Applicant, and it must be entered as a > DNS TXT record OR a DNS CNAME record for the domain. The hashes are to > be entered in DNS RR as follows: CNAME Example: > <Value of hash of CSR>.domainname.com CNAME <value of hash of > CSR>.comsign.co.uk. > TXT Example: > DCV TXT <value of hash of CSR> > *** 3.2.8.1.3 HTTP(S)-based DCV > The CSR that Comsign receives from the Applicant will be hashed. The > hash values are provided to you and you must create a simple plain-text > file and place this in the root of your webserver and served over > HTTP-only! The file and its content should be as follows: > http://domainname.com/<Upper case value of hash of CSR>.txt > OR http://domainname.com/<Upper case value of hash of CSR>.html > Content (as a plain text file): <Value of hash of CSR> Comsign > > ** CPS section 3.2.8.2. Authentication of Organization identity > Before issuing SSL certificate and whenever a certificate contains an > organization name, the identity of the organization and other enrolment > information provided by Certificate Applicants (except for Non-verified > Subscriber Information) is confirmed in accordance with the procedures > set forth in ComSign’s documented validation procedures. Comsign shall: > Determine that the organization exists by using at least one third party > identity proofing service or database, or alternatively, organizational > documentation issued by or filed with the applicable government agency > or competent authority that confirms the existence of the organization > or an authorised lawyer that confirm the existence of the organisation > according to local laws, confirm by telephone, confirmatory postal mail, > or comparable procedure to the SSL certificate applicant certain > information about the organization, that the organization has authorized > the certificate application request, and that the person submitting the > Certificate Application request on behalf of the certificate applicant > is authorized to do so. > Where a domain name is included in the SSL certificate - Comsign > authenticates the organization’s right to use that specific domain name > as a fully qualified domain name. > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=549246 > > * EV Policy OID: Not requesting EV treatment > > * Test Website: https://fedir.comsign.co.il/test.html > > * CRL URLs: > http://fedir.comsign.co.il/crl/ComSignGlobalRootCA.crl > http://fedir.comsign.co.il/crl/ComsignOrganizationalCa.crl > CPS Section 2.3: The published list of revoked certificates is valid for > 24 hours. > > * OCSP URL: http://ocsp1.comsign.co.il > > * Audit: Annual audits are performed by Sharony-Shefler, according to > the WebTrust criteria. > Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8599627 > BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8598250 > EV Audit: Not requesting EV treatment > I have exchanged email with the auditor to confirm the authenticity of > the audit statements. > > * Potentially Problematic Practices: None Noted > (http://wiki.mozilla.org/CA:Problematic_Practices) > > This begins the discussion of the request from ComSign to include the > "ComSign Global Root CA" root certificate, and enable the Websites and > Email trust bits. > > At the conclusion of this discussion I will provide a summary of issues > noted and action items. If there are outstanding issues, then an > additional discussion may be needed as follow-up. If there are no > outstanding issues, then I will recommend approval of this request in > the bug. > > Kathleen | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
