On Sun, Apr 15, 2018 at 6:47 PM, Ryan Sleevi <[email protected]> wrote: > > On Sun, Apr 15, 2018 at 9:13 AM Henri Sivonen via dev-security-policy > <[email protected]> wrote: >> >> (Mozilla hat off.) >> >> After reading about the California versus Delaware thing when it comes >> to the certificate for stripe.com, out of curiosity, I took a fresh >> look at the ISO 3166-1 code in the EV certificates of some of the >> banks that operate in Finland. (Result: https://www.nordea.fi/ is SE, >> https://www.handelsbanken.fi/ is SE but https://danskebank.fi/ is FI >> and not DK.) >> >> While at it, I noticed that the certificate for >> https://www.saastopankki.fi/ is an OV cert whose O field says >> "Saastopankkiliitto osk". However, according to >> >> https://tietopalvelu.ytj.fi/yritystiedot.aspx?yavain=25460&tarkiste=F663C7B776290379F1DAB6A4E251EE3FA727742A >> , the trade name of the entity is "Säästöpankkiliitto osk". It also >> has parallel trade names "Sparbanksförbundet anl" (Swedish translation >> of the primary name) and "Savings Banks' Union Coop" (English >> translation of the primary name) and auxiliary trade names >> "Säästöpankkikeskus" and "Sparbankscentralen". But no >> "Saastopankkiliitto osk". >> >> While I don't think there is any risk of confusion in this particular >> case[1], I'm wondering: What in the Baseline Requirements authorizes >> DigiCert to omit the diaereses from the trade name? >> >> The Baseline Requirements have this to say: "If present, the >> subject:organizationName field MUST contain either the Subject’s name >> or DBA as verified under Section 3.2.2.2. The CA may include >> information in this field that differs slightly from the verified >> name, such as common variations or abbreviations, provided that the CA >> documents the difference and any abbreviations used are locally >> accepted abbreviations; e.g., if the official record shows “Company >> Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company >> Name”." >> >> The variation covered by the example would have authorized the use of >> the abbreviation "osk" had the registered name contained "osuuskunta" >> (but it contained "osk" to begin with) or to drop "osk". >> >> Is it documented anywhere what transformations other than ones that >> are analogous to transforming "Incorporated" to "Inc." (or dropping >> it) are acceptable as differing "slightly"? > > > No. It is presently up to the CA and the Auditor, if the Auditor happens to > examine that certificate. Otherwise it’s left up to the RA and their ability > to follow the CA’s policies - presuming they have them documented, and not > just a blanket waiver like you cited.
Two observations: First, it seems to me that the Baseline Requirements allow transformations of the organization's name only if the CA documents such transformations. I am unable to find such documentation in DigiCert's CP and CPS documents. Am I missing something? Second, while verifying that the applicant indeed represents a specific real organization is a difficult problem, in the case where the country that the certificate designates operates an online-queryable database of registered businesses, associations, etc., it should be entirely feasible to eliminate the failure mode where the certificate's organization field is (absent documented transformations permitted under the Baseline Requirements) not canonically equivalent (in the Unicode sense) to the name of any organization registered in the country that the certificates designates. That (inferring from the certificate for www.alandsbanken.fi) there isn't technical process that would by necessity remove diacritical marks from the organization field and that the certificate for www.saastopankki.fi has them removed is strongly suggestive that DigiCert's process for validating Finland-based organization does not include as a mandatory part either the retrieval of the organization's name via an online API to the business registry or a human CA representative copying and pasting the organization's name from a browser view to the business registry. While the Baseline Requirements clearly permit relying on an opinion letter, which is vulnerable to failure modes such as the author of the opinion letter helpfully omitting diacritical marks (perhaps assuming that foreign systems couldn't deal with them) or the recipient of an opinion letter failing to precisely input a name displayed on the opinion letter into a computer system, I wonder: When a given country has an online-queryable business registry, why isn't it either recommended or required to import names digitally from the business registry into certificates? Such practice would eliminate the failure mode of the certificate designating a name that doesn't match any entry in the business registry for such country. (Obviously, if it was _required_, the BRs would need to include a list of countries whose business registry is considered online-queryable in the sense that the requirement would apply, but unwillingness to maintain such a list does not explain why it isn't even recommended.) >> In the Finnish language, ä >> and ö are considered to be distinct letters from a and o (so distinct >> that they sort to the end of the alphabet), so from that perspective, >> one could argue that the transformation is not "slight" for trade >> names themselves even though it is customary for transforming trade >> names into domain names[1]. >> >> Clearly, this isn't a matter of technical limitation, because DigiCert >> was able to put "Ålandsbanken Abp" in the O field of the cert for >> https://www.alandsbanken.fi/ . >> >> [1] https://www.saastopankki.fi/ is the primary address to which >> http://säästöpankki.fi/ (but not https!) redirects. Web site operators >> in Finland generally prefer interoperability with non-IDN-cabable >> usage over correct spelling. >> >> -- >> Henri Sivonen >> [email protected] >> https://hsivonen.fi/ >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
