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

[Henri Sivonen via dev-security-policy]

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

[Henri Sivonen via dev-security-policy]

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

[Henri Sivonen via dev-security-policy]

On Sun, Apr 15, 2018 at 6:47 PM, Ryan Sleevi <r...@sleevi.com> wrote:
>
> On Sun, Apr 15, 2018 at 9:13 AM Henri Sivonen via dev-security-policy
> <dev-security-policy@lists.mozilla.org> 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=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-querya

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

[Henri Sivonen via dev-security-policy]

(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=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)

[Henri Sivonen via dev-security-policy]

(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

[Henri Sivonen via dev-security-policy]

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

[Henri Sivonen via dev-security-policy]

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