Add City of Vienna CA certificate

RESOLVED INCOMPLETE

Status

NSS
CA Certificate Root Program
P3
enhancement
RESOLVED INCOMPLETE
12 years ago
a year ago

People

(Reporter: Thomas Uttner, Assigned: gerv)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
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

12 years ago
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.)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 2

12 years ago
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

12 years ago
(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

12 years ago
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

12 years ago
(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?

QA Contact: ca-certificates
bsmedberg: do you have an opinion on comment #5?

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
Priority: -- → P3
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
Status: ASSIGNED → NEW
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
Information has not been provided - resolving INCOMPLETE.

Gerv
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE

Updated

a year ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.