Transforming a trade name into ASCII in the O field of an OV cert

[Henri Sivonen]

(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
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Ryan Sleevi]

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.

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/ <http://xn--sstpankki-v2aa2t.fi/> (but not

> https!) redirects. Web site operators
> in Finland generally prefer interoperability with non-IDN-cabable
> usage over correct spelling.
>
> --
> Henri Sivonen
> hsiv...@hsivonen.fi
> https://hsivonen.fi/

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Henri Sivonen]

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

[Ryan Sleevi]

On Mon, Apr 23, 2018 at 1:11 PM, Henri Sivonen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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?
>

At present, these are not required to be in the public documentation.
Merely, the requirement is that the CA "documents" - i.e. it is presently
acceptable to only include this documentation in information provided to
the auditors.

> 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.
>

The Baseline Requirements do not dictate the datasource used in various
jurisdictions. Thus even when there is a canonical source through
legislation, the BRs do not require its use.

> 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.)
>

"Recommended" is pointless. Required is the only thing that makes sense,
and the complexities and overhead involved precisely explain why it isn't
required.

[Wayne Thayer]

Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. If
this were an EV cert I would argue that it was misissued.

[cbon...@trustwave.com]

Appendix D of the EV Guidelines (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.8.pdf) describes additional allowances for the Organization Name to be written with Latin letters. Section 1.2 of Appendix D is especially relevant here, as it appears that the organization names that are mentioned by Henri are transliterations of the original Finnish names.

[Jeremy Rowley]

That is correct. We use transliteration of non-latin names through a system
recognized by ISO per Appendix D(1)(3)

-----Original Message-----
From: dev-security-policy
<dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org>
On Behalf Of cbonnell--- via dev-security-policy
Sent: Tuesday, April 24, 2018 7:12 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Transforming a trade name into ASCII in the O field of an OV
cert

On Monday, April 23, 2018 at 3:34:38 PM UTC-4, Wayne Thayer wrote:

> > https://clicktime.symantec.com/a/1/BvQKGKG-atiF6qzY2ACOk9yeXt5fmZNpd
> > -faQX5l0PY=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4d
> > cVTpsXAtxoPHgF9wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbN
> > mjtVrSrgW9MjFpB_PV_GA0a6d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-
> > 0V-gd5e-1RY-WPPfqqiSVefSEHM3CbmoTYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07
> > NalO1afKP9pBC8NHIaF2qytDuUbZ-0_7wZVecDePdhfK4ghowJT_2N6v2KHnCG1cElhU
> > 822SsjxhXhwrQTBMTCLXhqVFTQqZtfPfRLDYzl0PcS-PLbsh2A96Dr_Y2gQ_rxoeIKIc
> > z5ln_0I189aAACvwnBtEFieiU0dIZxR3_s0ZN8Zp7MAS_0DY8i7xp0YGMCEiaC-X0rpJ
> > 5VXKItovyxmoIN7_63_vr5ObrP47_KLALVV-eG2OCX&u=https%3A%2F%2Flists.moz
> > illa.org%2Flistinfo%2Fdev-security-policy

> >

Appendix D of the EV Guidelines

(https://clicktime.symantec.com/a/1/k5LVvsTsn1aOD8kIgUl5TxWF-s1BWAyIy_p_gHjK
8OE=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4dcVTpsXAtxoPHgF9
wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbNmjtVrSrgW9MjFpB_PV_GA0a
6d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-0V-gd5e-1RY-WPPfqqiSVefSEHM3Cbm
oTYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07NalO1afKP9pBC8NHIaF2qytDuUbZ-0_7wZVecDe
PdhfK4ghowJT_2N6v2KHnCG1cElhU822SsjxhXhwrQTBMTCLXhqVFTQqZtfPfRLDYzl0PcS-PLbs
h2A96Dr_Y2gQ_rxoeIKIcz5ln_0I189aAACvwnBtEFieiU0dIZxR3_s0ZN8Zp7MAS_0DY8i7xp0Y
GMCEiaC-X0rpJ5VXKItovyxmoIN7_63_vr5ObrP47_KLALVV-eG2OCX&u=https%3A%2F%2Fcabf
orum.org%2Fwp-content%2Fuploads%2FCA-Browser-Forum-EV-Guidelines-v1.6.8.pdf)

describes additional allowances for the Organization Name to be written with
Latin letters. Section 1.2 of Appendix D is especially relevant here, as it
appears that the organization names that are mentioned by Henri are
transliterations of the original Finnish names.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://clicktime.symantec.com/a/1/BvQKGKG-atiF6qzY2ACOk9yeXt5fmZNpd-faQX5l0
PY=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4dcVTpsXAtxoPHgF9w
jrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbNmjtVrSrgW9MjFpB_PV_GA0a6
d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-0V-gd5e-1RY-WPPfqqiSVefSEHM3Cbmo
TYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07NalO1afKP9pBC8NHIaF2qytDuUbZ-0_7wZVecDeP
dhfK4ghowJT_2N6v2KHnCG1cElhU822SsjxhXhwrQTBMTCLXhqVFTQqZtfPfRLDYzl0PcS-PLbsh
2A96Dr_Y2gQ_rxoeIKIcz5ln_0I189aAACvwnBtEFieiU0dIZxR3_s0ZN8Zp7MAS_0DY8i7xp0YG
MCEiaC-X0rpJ5VXKItovyxmoIN7_63_vr5ObrP47_KLALVV-eG2OCX&u=https%3A%2F%2Flists
.mozilla.org%2Flistinfo%2Fdev-security-policy

[Henri Sivonen]

On Tue, Apr 24, 2018 at 10:18 PM, Jeremy Rowley via
dev-security-policy <dev-secur...@lists.mozilla.org> 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]

I meant D 1. (1), D 1. (2) and D 1. (3).

[cbon...@trustwave.com]

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)). 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.

In addition, although Digicert has the technical capability to issue certificates with UTF-8 Organization Names, certain technical realities, such as client or server application software being unable to handle non-ASCII characters in certificate subject fields, would require that the Organization Name be represented in ASCII only.

[Henri Sivonen]

On Tue, Apr 24, 2018 at 11:03 PM, cbonnell--- via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Tuesday, April 24, 2018 at 4:33:24 PM UTC-4, Henri Sivonen wrote:

> 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?

[Peter Saint-Andre]

On 4/24/18 2:47 PM, Henri Sivonen via dev-security-policy wrote:

> On Tue, Apr 24, 2018 at 11:03 PM, cbonnell--- via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>> On Tuesday, April 24, 2018 at 4:33:24 PM UTC-4, Henri Sivonen wrote:

>> 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.

As noted in RFC 6365:

"Latin characters" is a not-precise term for characters
historically related to ancient Greek script as modified in the
Roman Republic and Empire and currently used throughout the world.
<RFC6365>

The base Latin characters are a subset of the ASCII repertoire and
have been augmented by many single and multiple diacritics and
quite a few other characters. ISO/IEC 10646 encodes the Latin
characters in including ranges U+0020..U+024F and U+1E00..U+1EFF.

Because "Latin characters" is used in different contexts to refer
to the letters from the ASCII repertoire, the subset of those
characters used late in the Roman Republic period, or the
different subset used to write Latin in medieval times, the entire
ASCII repertoire, all of the code points in the extended Latin
script as defined by Unicode, and other collections, the term
should be avoided in IETF specifications when possible.
Similarly, "Basic Latin" should not be used as a synonym for
"ASCII".

Peter