Hi Wayne, I noticed your comment on IDN validation. Is there a requirement that CAs establish an effective safeguard against homograph spoofing?
The reason I ask is that Let's Encrypt's CPS says this: "Regarding Internationalized Domain Names, ISRG will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names." Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > Wayne Thayer via dev-security-policy > Sent: Tuesday, December 5, 2017 1:44 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: ComSign Root Renewal Request > > > 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#Verifyin > g_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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
