Doug, I am not aware of any requirement for CAs to detect or prevent homograph spoofing in the names contained in certificates they issue. Mozilla's position is that this is something best handled by registries/registrars just as stated in the CPS you quoted.
In the case of the ComSign CPS, my concerns were that the paragraph was confusing and it described an ineffective process, so I asked for clarification. Wayne On Tue, Dec 19, 2017 at 4:14 PM, Doug Beattie <doug.beat...@globalsign.com> wrote: > 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
