Re: Transforming a trade name into ASCII in the O field of an OV cert
On Tue, Apr 24, 2018 at 11:03 PM, cbonnell--- via dev-security-policy wrote: > On Tuesday, April 24, 2018 at 4:33:24 PM UTC-4, Henri Sivonen wrote: >> On Tue, Apr 24, 2018 at 10:18 PM, Jeremy Rowley via >> dev-security-policy wrote: >> > That is correct. We use transliteration of non-latin names through a system >> > recognized by ISO per Appendix D(1)(3) >> >> But "Säästöpankkiliitto osk" is not a non-Latin name! (It is a >> non-ASCII name.) Also, no such transliteration is applied to >> "Ålandsbanken Abp", so evidently there's no technical necessity for >> transforming the name. >> >> Clearly, D(1) does not apply (the name is not non-Latin). D(2) doesn't >> make sense (it doesn't make sense to Romanize a Latin-script name). >> D(3) is about *translated* names (the organization has translated >> names [in Swedish and in English], but the name on the certificate is >> neither of those). >> >> -- >> Henri Sivonen >> hsivo...@hsivonen.fi >> https://hsivonen.fi/ > > Although the EV Guidelines don’t explicitly state this, I think it’s > reasonable to interpret the EV Guidelines’s use of “Latin characters” as the > characters comprising the ISO basic Latin alphabet > (https://en.wikipedia.org/wiki/ISO basic Latin_alphabet) or the characters in > the Basic Latin Unicode Block > (https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)). That's not at all clear from the text of the document. If the document means Basic Latin, it ought to say so instead of saying Latin. > Since the original Organization Name contains characters outside that > alphabet/code block, it is reasonable to interpret Appendix D as being > applicable to these Finnish organization names. Is there a system with higher priority than a lawyer or accountant asserting things that meets the criteria under D 1. (2) and results in the transformation that's seen in the certificate? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Transforming a trade name into ASCII in the O field of an OV cert
On Tue, Apr 24, 2018 at 10:32 PM, Henri Sivonen wrote: > On Tue, Apr 24, 2018 at 10:18 PM, Jeremy Rowley via > dev-security-policy wrote: >> That is correct. We use transliteration of non-latin names through a system >> recognized by ISO per Appendix D(1)(3) > > But "Säästöpankkiliitto osk" is not a non-Latin name! (It is a > non-ASCII name.) Also, no such transliteration is applied to > "Ålandsbanken Abp", so evidently there's no technical necessity for > transforming the name. > > Clearly, D(1) does not apply (the name is not non-Latin). D(2) doesn't > make sense (it doesn't make sense to Romanize a Latin-script name). > D(3) is about *translated* names (the organization has translated > names [in Swedish and in English], but the name on the certificate is > neither of those). I meant D 1. (1), D 1. (2) and D 1. (3). -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Transforming a trade name into ASCII in the O field of an OV cert
On Tue, Apr 24, 2018 at 10:18 PM, Jeremy Rowley via dev-security-policy wrote: > That is correct. We use transliteration of non-latin names through a system > recognized by ISO per Appendix D(1)(3) But "Säästöpankkiliitto osk" is not a non-Latin name! (It is a non-ASCII name.) Also, no such transliteration is applied to "Ålandsbanken Abp", so evidently there's no technical necessity for transforming the name. Clearly, D(1) does not apply (the name is not non-Latin). D(2) doesn't make sense (it doesn't make sense to Romanize a Latin-script name). D(3) is about *translated* names (the organization has translated names [in Swedish and in English], but the name on the certificate is neither of those). -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Transforming a trade name into ASCII in the O field of an OV cert
On Sun, Apr 15, 2018 at 6:47 PM, Ryan Sleevi wrote: > > On Sun, Apr 15, 2018 at 9:13 AM Henri Sivonen via dev-security-policy > 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 busi
Transforming a trade name into ASCII in the O field of an OV cert
(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"? 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 hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Estonia e-residency instructing users not to update Firefox (on Mac)
(Not sure if this is the right mailing list, but while I'm not sure how exactly the PKI operations of the government of Estonia are structured organizationally, on surface it looks like this is related to client cert activities of a CA that is Mozilla-trusted for server certs.) A Medium post claiming[1] to represent Estonia e-residency https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52 instructs Mac users not to update Firefox from December 15 2017 onwards. The post claims that there is a Firefox release scheduled for December 15 2017, but I don't see one at https://wiki.mozilla.org/RapidRelease/Calendar . (There is one scheduled whose month and day are both off by one compared to the date stated: November 14.) Regardless of the date, instructing users not to update their browser is not good in terms of security. The post doesn't explain in technical detail the reason for the recommendation not to update. Why is not updating being recommended? [1] I don't understand why this wasn't published on a domain belonging to the government of Estonia. I don't know how to validate that a Medium blog belongs to who it claims to belong to. However, I hear that a link to this post was distributed to e-residents in a manner that suggests that this blog actually belongs to whom it claims to belong. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom continues to sell untrusted certificates
On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/05/17 07:52, Percy wrote: >> It seems that StartCom continues to sell untrusted certs. Neither their home page https://www.startcomca.com/ nor their announcement page https://www.startcomca.com/index/news mentions that those certs are not trusted. > > Why is this something that Mozilla should be concerned with? > > "Selling untrusted certs" is not a crime, or a violation of any > standard. Mozilla is not the global authority on what certificates may > be issued. If StartCom are providing certificates which do not do what > their customers expect, I'm sure those customers will let them know > about it soon enough. What StartCom claims about compatibility is potentially more Mozilla-relevant than what they are silent about. At the bottom of their front page, it says "StartCom™ / StartSSL™is supported by:" followed by icons. The icons include an early icon for Camino and the SeaMonkey icon. Since Camino was discontinued before Mozilla's change in trust in StartCom certificates, I guess having Camino there isn't technically incorrect, but is about as relevant as having the Flock icon there. However, is it correct to have the SeaMonkey icon there? The latest SeaMonkey release seems to post-date the Mozilla root program's trust change in StartCom certificates. (But then, it seems that there have been a number of Firefox ESR security patch releases that post-date the SeaMonkey release. Is SeaMonkey still active, despite appearing not to ship Gecko security updates, and does SeaMonkey implement the same trust special-casing as Firefox? It seems to produce nightlies still.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On Thu, Apr 20, 2017 at 4:02 PM, Gervase Markham via dev-security-policy wrote: > I don't believe the issuance of wildcard DV certs is problematic in > practice. Mozilla is of the view that ubiquitous SSL is the highest > priority for the Web PKI, and wildcard certs are a part of that. Mozilla > also doesn't believe that it's the job of CAs to police phishing, which > is the concern raised. > > I propose this section be removed from the document. I support this proposal. To get code isolation in a browser, you have to have different origins for the things you are isolating from each other. A security system (like Sandstorm.io) can mint new origins by minting hostnames. Even with ACME, getting a non-wildcard cert for each throw-away on-demand-minted hostname doesn't make sense in terms of CA latency and CA rate limits. A wildcard cert solves this, and the solution should be broadly available (not just to those who pay for OV). -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy