342503 - Add City of Vienna CA certificate

Status: RESOLVED INCOMPLETE

(CA Program :: CA Certificate Root Program, task, P3)

Description

[Thomas Uttner]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Magistrat Wien; .NET CLR 1.1.4322)
Build Identifier: Firefox

CA operated by the government of the City of Vienna region of Austria. CPS and CPs (in German) can be found at

  http://www.signatur.rtr.at/de/providers/providers/wien.html

The root CA certificate data can be found at

  http://www.wien.gv.at/ma14/zertifikate.html

Note that only the certificate at

  https://www.wien.gv.at/ca-top-2035/ext/cacert/cacert.crt 

is a true root certificate; the certificate at

  https://www.wien.gv.at/ca-signer-2015/ext/cacert/cacert.crt 

is for an intermediate CA under the root CA. According to our policies only the
root CA certificate will be considered for inclusion.



Reproducible: Always

Comment 1

[Frank Hecker]

As noted in our CA certification policy <http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html>, "We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits ... of such inclusion to typical users of those products." In the past I've approved including CA certificates for CAs operated by national governments (e.g., for the Netherlands and Taiwan), if those CAs issue certificates to the general public, because in my opinion doing this was of benefit to typical users of Mozilla-based products.

However I agree with timeless's comment (in private email) that it is hard to justify including root CA certificates for CAs operated by municipal governments (or in general CAs operated by any regional government), given the large number of such governments and the relatively small populations served by each one.

Unless someone has compelling arguments to the contrary, I'm inclined to reject this request, at least for Mozilla in general. (If we had an easy way to maintain different root lists for different localized versions of Mozilla products, I'd be willing to consider having this CA certificate included for the de-AT versions of Firefox, Thunderbird, etc.)

Comment 2

[David E. Ross]

Note that residents of Vienna are free to install the city's root and intermediate certificates into their own browser configurations.  However, what is the policy regarding installing local certificates into localized versions of Mozilla products?  

Comment 3

[Frank Hecker]

(In reply to comment #2)
> However, what
> is the policy regarding installing local certificates into localized versions
> of Mozilla products?  

I presume you're referring to the idea of shipping localized versions of Firefox, etc., that have slightly different root lists than the US-English version. There are multiple issues with this, and multiple groups that would have to work together to resolve those issues.

I think the first (and most important) issue with this is technical: Right now all the root certs are stored in a single C-language source file (certdata.c IIRC), and that file gets built into a single shared library shipped as part of NSS. I'm not sure it would be workable for localization teams to maintain their own modified versions of certdata.c and ship their own versions of the NSS shared library. Maybe a better approach would be to split certdata.c into two parts, a core list and a set of region-specific lists supplementing the core list, with two resulting shared libraries. That way localizers could just ship the additional library needed for the relevant local CAs, and not mess with the core list. I'd welcome any comments from NSS developers on how we might address this issue.

The next issue relates to the localizers themselves, and whether they think it's a good idea to do this. One issue is that not all of the localized versions match up one for one with particular countries or even regions. For example, we have a Spanish version of Firefox localized for Spain (es-ES) and one localized for Argentina (es-AR), but to my knowledge we don't have localized versions for other Spanish-speaking countries. So if we had a CA that we only wanted to pre-load for use in (say) Mexico, which version(s) should we put it in? All the Spanish versions?

The third issue relates to the trademark policy and the desirability of shipping localized versions that are modified to have pre-loaded CA certs not present in the US English version. For Firefox and Thunderbird it's really the Mozilla Corporation that needs to consider that question and make a decision one way or the other.

The final issue is with regard to the CA certificate policy itself. I think this is actually the most straightforward issue: If we wanted to pre-load CAs just for a particular country or region, we wouldn't be relaxing our policy requirements in terms of what the CA has to comply with. We'd simply be modifying the part of the policy I quoted above about including a CA cert having to be of benefit to typical users.

The bottom line is that allowing addition of truly "localized" CAs might not be a bad idea; however there are three other groups we'd need to have agree with the Foundation on this question.

Comment 4

[Benjamin Smedberg]

It is a terrible idea for the root certificates to change in different languages of the browser: there is no direct correspondence between what language people speak and what websites they might wish to visit.

Comment 5

[Frank Hecker]

(In reply to comment #4)
> It is a terrible idea for the root certificates to change in different
> languages of the browser: there is no direct correspondence between what
> language people speak and what websites they might wish to visit.

OK, fair enough. So given that you favor our having a single worldwide root list, with no variations, what's your opinion on the original question here: Should we reject requests to include CAs like this one that are extremely local in nature (which is my current position), or should we consider including them?

Comment 6

[Gervase Markham [:gerv]]

bsmedberg: do you have an opinion on comment #5?

Gerv

Comment 7

[Gervase Markham [:gerv]]

As you may know, the mozilla.org CA certificate policy:
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
states: "We require that all CAs whose certificates are distributed with our software products provide some service relevant to typical users of our software products."

Both bug 295474 and bug 342503 are on hold, pending the formulation of a policy on whether certificate authorities who deal with a constituency smaller than a country meet this requirement. Without limitation, possible resolutions include shipping the roots to everyone, shipping them only in a subset of builds, and deciding not to ship them at all.

I will post in this bug again when we've decided what to do. Thank you for your patience.

Gerv

Comment 8

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 9

[Gervase Markham [:gerv]]

We have decided that applications from sub-country governmental organisations
will be considered after all the others have been processed.

Please could you provide data about your CA and certificates in the following
format, as a *plain text comment* in this bug. This will help me do whatever
evaluation is necessary, and then will be part of a public record describing
the Mozilla default root certificates. Even if all of it is already present
somewhere in the bug or the materials provided, it will speed up your
application if you provide it again.

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, 
                   academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy, 
   i.e. what you plan to do with the root
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity/organisationally-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):
URL of website using certificate chained to this root (if applying for SSL):

Thanks for your help in this matter. :-)

Gerv

Comment 10

[Gervase Markham [:gerv]]

Information has not been provided - resolving INCOMPLETE.

Gerv