Closed Bug 373746 Opened 17 years ago Closed 17 years ago

Add a.trust CA Certificate to builtin certificates

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 530797

People

(Reporter: sabet, Assigned: gerv)

References

Details

Attachments

(1 file)

required documentation concerning the CA certificates
6.56 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

we at a.trust get a lot of requests from our customers, why our CA Certificate 
are only included in MS Internet Explorer.

a.trust (founded in February 17, 2000) is the only accredited Trust Center in 
Austria issuing smartcard based qualified certificates for Austrian citizen 
used in eGovernment, etc.

In March 11, 2002 A-Trust has been accredited according to § 17 of the 
Austrian Signature Law by Telekom-Control-Kommission, the Austrian supervisory 
body.

A-Trust’s product range comprises user certificates, developer certificates 
and corporate certificates as well as consultation services and support with 
the development of e commerce and signature applications in accordance with 
the Directive 1999/93/EC.

OCSP : http://ocsp.a-trust.at
CPS: http://www.a-trust.at/docs/cps/a-sign-Premium
Audit: Telekom Control Commission
       http://www.signatur.rtr.at/en/providers/providers/atrust.html
       http://www.signatur.rtr.at/en/providers/services/atrust-asign-
premium.html

-----
The CP and CPS are german, but our Auditor's pages are English and German
http://www.signatur.rtr.at/en/providers/providers/atrust.html
----
The chain of Trust we are referring to is the following:

according to the Austrian supervisory authority Telekom-Control-Kommission 
a.trust is a accredited Trustcenter:
http://signatur.rtr.at/en/providers/providers/atrust.html


According to the European Signature Directive:
http://europa.eu.int/information_society/eeurope/2005/all_about/security/esigna
tures/index_en.htm in Austria the Telekom-Control-Kommission is responsible 
for Accreditation and supervision.


Our Policy http://www.a-trust.at/docs/cp/a-sign-premium 
confirms the compliance with ETSI TS 101 456 (Page 4) 
-----
The required file will be attached as a plain text file.
-----
Problem has already been reported as https://bugzilla.mozilla.org/show_bug.cgi?id=252610, but since there was no response for a VERY long time, i was asked to report this issue again.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
That bug seems to be active to me. I'm going to assume that this bug is in response to Comment #6 of that bug. and triage it to that component as such.
Assignee: nobody → hecker
Status: UNCONFIRMED → NEW
Component: Security → CA Certificates
Depends on: 252610
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → mozilla.org
QA Contact: firefox → ca-certificates
Hardware: PC → All
Version: unspecified → other
Mr Sabet: some questions concerning your application.

You say in your initial comment that "Our Policy http://www.a-trust.at/docs/cp/a-sign-premium 
confirms the compliance with ETSI TS 101 456 (Page 4)". Was it the Telekom-Control-Kommission who audited your compliance with this standard? If so, that might present a problem, as the Kommission itself is a CA, applying for inclusion in the Mozilla root certificate store in bug 373174, rather than a firm of auditors.

You gave the CP/CPS of the 'most used' intermediate certificate. However, presumably each intermediate is only signed by one of the four roots. Which root signed the "asign-premium" intermediate? Do you have CPs/CPSes for the 'most used' intermediate for each of the other three? Do you have a diagram of your certificate hierarchy?

Does your website have a page listing all of the CPs and CPses for each of the intermediate roots?

Thanks,

Gerv

First, thanks for the very fast response.

------------------------------------------------------------
All Certification Practice Statements:
   https://www.a-trust.at/docs/cps
All Certificate Policies:
   https://www.a-trust.at/docs/cp
------------------------------------------------------------
Telekom-Control-Komission is our Auditor, they are listed in http://www.fesa.eu/country-at.html and

According to the European Signature Directive:
http://europa.eu.int/information_society/eeurope/2005/all_about/security/esigna
tures/index_en.htm in Austria the Telekom-Control-Kommission is responsible 
for Accreditation and supervision.

Additional they have a CA, which is only used to sign the intermediate certificates of the CAs they have audited.
------------------------------------------------------------
Hierarchy:
an overview of all our CAs can be found at https://www.a-trust.at/docs/CA-Hierarchy_v10.pdf
------------------------------------------------------------

Regards,
  ramin
Thank you for this additional information. However, I still don't quite have an answer to my question. I understand that the TCK is your auditor; what audit criteria did they use for doing the audit? ETSI or something else?

> Additional they have a CA, which is only used to sign the intermediate
> certificates of the CAs they have audited.

Then surely that mean you do not need your own roots included, because certificates you issue would chain back to the TCK root?

Gerv
Hello,

The Audit was performed according to our policy, which states, that we are ETSI compliant.

We are the CA which issues user certificates, so we are responsible eg. to inform you if one of our CA-Certificates is going to expire, we cannot rely on someone else, who might forget this fact, since no end-user will call the TelekomControlCommision, but all our user will send us complains if Mozilla shows warnings again.

Our end-user-certificates contain the extension AuthorityKeyIdentifier with a http-link to our intermediate certificate, will such a certificate validate in Mozilla if the according root does not exist?

regards
   Ramin
I must admit that the idea of a CA acting as the auditor for any 
subordinate CAs to whom it issues certs seems very sensible to me.  
And conversely, it seems sensible for auditors to act as superior 
CAs, issusing subordinate CA certs to the CAs they audit, thereby 
proclaiming their audit results in the certs they sign.  
The duties of the Telekom-Control Commission are described here:
http://www.signatur.rtr.at/en/supervision/tkk.html

The fact that they are also a CA opens an optional second chain of trust. Our certificates include an http-AuthorityInformationAcces pointing to our intermediate certificates (as described in our policy). As far as i understand it, this allows only one chain of trust.

Regads
   Ramin
Severity: normal → enhancement
Priority: -- → P2
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
OK.

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration.

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv
Status: NEW → ASSIGNED
wow this are good news.

just checked the data, looks fine.

regards,
   Ramin
Ramin,

You are going to have to help me here. There are a large number of documents at:
https://www.a-trust.at/html/download_area_show_pub.asp?dir=cps

You issue certificates for all sorts of reasons. I am concerned only with those which permit email signing, SSL server security or code signing.

Which documents in that list cover such certs? Are the documents available in English?

Gerv

The problem I noted in comment #13 seems to be reasonably common with European CAs; so I have written an extended explanation, which might be useful here. It is as follows:

Your CP/CPS and/or other documents are not in English. Assuming they are not available in English (please let me know if they are), then I have to have particular parts translated. As having documents translated and reading approximate translations is a tedious task, I hope you will be able to help me in narrowing down which parts to read.

When I read a CP/CPS, I am looking to see if the practices of the CA satisfy the criteria in our CA Certificate Policy:
http://www.mozilla.org/projects/security/certs/policy/

Specifically, I look for:

- Which exact section contains an undertaking to confirm that the applicant has control of the email address before issuing them an email certificate?

- Which exact section contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate?

- (If applicable) Which exact section contains an undertaking that the applicant's identity is strongly validated before issuing them a code signing certificate?

Can you point me at the correct sections for each of these cases?

Gerv
Hello, here the link to the German document and the two desired sections (3.1.7 and 3.1.8) translated:

Hope this helps !

Regards,
   Ramin

http://www.a-trust.at/docs/cps/a-sign-corporate/a-sign-corporate_cps.pdf


3.1.7 Authentication of Organisations

To order an a.sign corporate certificate, the organisation has to be validated. If the organisation can be found in the Austrian Commercial Register or the European Business Register, then the company is validated via an online request to one of the registers. In this case the number in the corresponding register is part of the application.
[...]
The domain name or email address is verified by the registration authority using the databases of the responsible organisations (eg.: www.nic.at, www.denic.de, etc.). If this is not possible, then the owner of the domain name has to add a written confirmation that the applying person/organisation is allowed to use the domain name. If a server certificate is issued with an IP Address in the common name, then the applicant has to add an approval of his ISP that he is in possession of the IP Address.


3.1.8 Authentication of Individuals 

The following persons are authenticated during the process of applying for an a.sign corporate certificate:
 * A Signatory i.e. the person with technical responsibility (e.g. the system or server administrator) who is in sole possession of the key
 * A person with organisational responsibility who has the authority to sign within the applying organisation.


A copy of a valid legal photo document of identification must be conveyed by both persons specified in the request to a.trust. The following documents of identification are permissible: 
 * an internationally valid passport in German and/or English language  
 * a list of further accepted documents of identification can be found on the a.trust website


If the person with organisational responsibility is not found in the Austrian Commercial Register or the European Business Register, an approval by someone authorised to sign for the applying organisation is required.

It is possible that the two roles (of technical and organisational responsibility) are combined in one person, in which case only one set of documents is required.

Ramin,

Thanks for that. It's certainly helpful. Some follow-up questions:

- Does this CPS
http://www.a-trust.at/docs/cps/a-sign-corporate/a-sign-corporate_cps.pdf
cover all certificates which are issued from the roots you are asking us to trust? (I notice is has "Corporate" in the name.) If not, do the other relevant CPS documents have similar sections?

- You say: "The domain name or email address is verified by the registration authority using the databases of the responsible organisations (eg.: www.nic.at, www.denic.de, etc.)."

I see how this works for domain names, but how is this possible for email addresses? How can you check I own gerv.markham@gmail.com in this way?

- Do you have a certificate hierarchy diagram?

- At what interval do you issue CRLs for end entity certificates?

Gerv

Hello,

the cps quoted is valid for SSL and 'mail-signing' certificates (companies sending out lots of signed emails. In this case the email address must be within the domain owned by the requesting company. (hence a @gmail.com address only be issued to someone from google, or with permission of google).
One possible application is a company (www.testcompany.com) sending out their bills via signed email. Then they request a certificate for eBilling@testcompany.com, we verify the owner of the domain.

All other cps contain the section "3.1.8 Authentication of Individuals"

- All CRLS are issued every two hours and are valid for six hours

- CAs: http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf
I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at: http://www.mozilla.org/projects/security/certs/policy/ .

Here follows my assessment. If anyone sees any factual errors, please point them out.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by A-Trust, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. A-Trust appears to provide a service relevant to Mozilla users: they issue smartcard-based certificates to Austrian citizens. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

Section 7 [Validation]. A-Trust appears to meet the minimum requirements for subscriber verification, as follows:

* Email: For certificates with the E-mail Protection EKU (1.3.6.1.5.5.7.3.4), A-Trust verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See section 3.1.7 of CPS v1.0.9.) They then only issue email certificates for that domain to the domain owner (who is deemed to have control of email addresses within that domain).

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), A-Trust verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See section 3.1.7 of CPS v1.0.9.)

* Code: For certificates with the Code Signing EKU (1.3.6.1.5.5.7.3.3)
A-Trust verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (See section 3.1.8 of Corporate CPS v1.0.9, and the equivalent section in other CPSes.)

Section 8-10 [Audit]. A-Trust has successfully completed an audit using the WebTrust for CAs criteria. The auditors were The Austrian Telekom Control Commission. The audit is currently valid.

Section 13 [Certificate Hierarchy]. A-Trust has an extensive hierarchy with four roots, each with between one and nine sub-CAs. 
http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf

Other: A-Trust issues CRLs (on a 2-hour schedule) and also has an OCSP responder.

I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks.

Gerv

Hi Ramin,

Eddy Nigg, a member of our communitym raised some questions in our newsgroup about your certificates, and the links between certificates and policies. They seem very good questions to me. Please can you address them?

I would like to see a clear statement on your website listing your roots, and the CP and CPS which applies to each (or the set of CP/CPSes which can apply, and the conditions under which each apply). At a minimum, this list would include all the roots you are applying to have included, but ideally it would include all the roots you control.

Gerv

2.) The links under the section "documents" point to various CA policies and practices:

http://www.a-trust.at/docs/cp
http://www.a-trust.at/docs/cps

But it seems to be impossible for me to establish a direct path between the requested roots in question to any of the CA policies.

3.) The same is true for the information provided by http://signatur.rtr.at/en/providers/providers/atrust.html . When examining the various entries I can't establish a connection between the *4* roots requested for inclusion. The CA certificates from that page and following pages and entries are signed by  Telekom-Control-Kommission. The document http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf doesn't help either...

4.) There are 19 different CA certificates on http://signatur.rtr.at/en/providers/providers/atrust.html some of them marked as active, about each one seem to have very different qualifications and minimum requirements! All of them are issued by Telekom-Control-Kommission. But when examining the issuer of https://www.a-trust.at/certs/A-Trust-Qual-01a.crt (a-sign-corporate-light-01) it says A-Trust-nQual-01. When checking the corresponding entry of a-sign-corporate-light at http://signatur.rtr.at/en/providers/providers/atrust.html it says something else (i.e. issued by Telekom-Control-Kommission).

5.) In the original bug at https://bugzilla.mozilla.org/show_bug.cgi?id=373746#c4 it says to be in compliance with ETSI TS 101 456 (this refers to the policy document only), but I can't find any audit requirements to that standard nor any audit confirmation whatsoever. More than that, the Austrian Signature Act doesn't require any either (as far as I could see). At the overview ( http://signatur.rtr.at/en/legal/overview.html ) and other pages one can read:

/Die Aufnahme und Ausübung der Tätigkeit eines Zertifizierungsdiensteanbieters bedürfen keiner gesonderten Genehmigung. Der Anbieter muss die Aufnahme der Tätigkeit lediglich der Aufsichtsstelle anzeigen. Ein Anbieter, der sichere elektronische Signaturverfahren bereitstellt, kann sich aber vor der Aufnahme der Tätigkeit von der Aufsichtsstelle akkreditieren lassen./

Which freely translated means, that a CA in Austria doesn't require any special permission. A CA only has to notify the supervisor (assuming to be Telekom-Control-Kommission). Such a provider *can* be accredited by the supervisor (it's not a requirement).

Maybe someone can shed some light about this? 

Eddy
The comment period has ended, but further investigation is being done. This application is not yet approved.

Gerv
https://bugzilla.mozilla.org/show_bug.cgi?id=373746

ad2) There is a CPS for each intermediate CA and at least one CP for each. For some closed user groups we have special CPs to some intermediate CAs- Eg. for a-sign-premium (cn=a-sign-premium-sig-xx and
cn=a-sign-premium-enc-xx) has one CPS and one CP:
- http://www.a-trust.at/docs/cp/a-sign-Premium/
- http://www.a-trust.at/docs/cps/a-sign-Premium/ 

Which CP and CPS is used for a single end-user-certificate is defined by the policy extension in the certificate. And http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf shows which root issues which intermediate.


ad 3) I thought (hoped) http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf would clearify the situation. There are 4 roots (nQual,Qual,etc with gray background) and below each root are the intermediae certificates which issue end-user-certificates.

ad 4) We issue our own certifcates, hence the issuer in the intermdiate certificates is always A-Trust. We send a certificate signing request for each intermediate to Telekom Control Kommission, and if the service is approved, they issue a certificate based on that csr.

ad 5) You are right ETSI TS 101 456 is not a requirement of Telekom Control Kommission. But they audit is performed according to the CP/CPS, wether every point statd in the CP/CPS is valid.

Ramin: regarding your point 5. I'm sure the audit confirms the points in the CP/CPS, but the Mozilla Foundation does not have the manpower to confirm the WebTrust or ETSI equivalence of various audit regimes, or to audit your procedures ourselves. Therefore, we require a valid ETSI or WebTrust audit before admitting CAs into our root store.

To summarise, then: we need an audit to one of the sets of criteria in policy section 8, performed by an auditor which meets the criteria in policy sections 9 and 10, and who is willing to state publicly that they have performed such an audit, and that you passed. If you have not been subject to such an audit, then we must sadly decline your application.
http://www.mozilla.org/projects/security/certs/policy/

Gerv

Hello,

of course i unserstand, that you do not perform the Audit, but i thought, the 
Austrian Telekom-Control Commission (https://bugzilla.mozilla.org/show_bug.cgi?id=373174) who performed our Audit and clearly states this on their website was an organisation entitled to perform such audits.

regards,
   ramin
To quote comment #22, the TCC is indeed "an auditor which meets the criteria in policy sections 9 and 10", but the problem is that it doesn't do (or you haven't proved that it does) "an audit to one of the sets of criteria in policy section 8".

Gerv
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Is there any new progress on this bug? there are several e-government-applications which users are complaining about the additional security warnings and manual steps necessary to use them with Firefox.
Robert, 

this is NOT a bug. A-Trust simply refuses to undergo a proper audit (ETSI or WebTrust) required to be allowed to include CAs into the root store.
still nothing new about this?
It is for a.trust to make the next move.

Gerv
this may be a duplicate Bug - A-Trust certificates have already been included in FF 6.0.2 -> https://bugzilla.mozilla.org/show_bug.cgi?id=530797
Resolution: WONTFIX → DUPLICATE
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: