Closed Bug 373174 Opened 17 years ago Closed 17 years ago

Add Austrian Telekom-Control Commission CA certificate

Categories

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

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ulrich.latzenhofer, Assigned: gerv)

References

()

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: all builds

CA Details
----------
(To be completed only once, for the CA)

CA Name: Telekom-Control-Kommission Top 1
Website: http://www.signatur.rtr.at/
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
The Telekom-Control Commission (German: Telekom-Control-Kommission, acronym: TKK) is the Austrian supervisory authority for electronic signatures. Its responsibility includes supervision of all certification service providers established in Austria. The state-owned Rundfunk und Telekom Regulierungs-GmbH (RTR) is the office of the TKK. On behalf of the TKK, RTR maintains a PKI-based directory of all Austrian certification services. For every CA key used by an Austrian certification service provider, the TKK issues a certificate to the certification service provider. Based on these certificates, all certificates issued by supervised Austrian certification service providers can be verified.

There are five subordinate CAs:
- Accredited Certification Services 1 (issues certificates to CAs accredited under the Austrian accreditation scheme)
- Qualified Certification Services 1 (issues certificates to non-accredited CAs issuing qualified certificates)
- Secure Timestamping Services 1 (issues certificates to secure timestamping services within the meaning of the Austrian Electronic Signatures Act)
- Certification Services 1 (issues certificates to any other supervised CA)
- RTR Services 1 (issues certificates to internal services of RTR)

Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: Secure Information Technology Center - Austria (German: Zentrum für sichere Informationstechnologie - Austria, acronym: A-SIT)
Auditor Website: http://www.a-sit.at/
Audit Document URL(s): https://bugzilla.mozilla.org/attachment.cgi?id=204776

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

Certificate Name: Telekom-Control-Kommission Top 1
Summary Paragraph, including the following:
  - End entity certificate issuance policy, i.e. what you plan to do with
    the root
The TKK issues certificates to certification service providers who are supervised according to the Austrian Electronic Signatures Act (policy documents see below). The corresponding private keys of certification service providers are used for issuing certificates to end entities (signatories). Certificates issued by the TKK may be used for validating CA signing keys of certification service providers.

Certificate HTTP URL (on CA website): http://www.signatur.rtr.at/currenttop.cer
Version: X.509 v3
SHA1 Fingerprint: 914929eec7a021b5da491a35a5984c2cf25bc755
MD5 Fingerprint: 4a0b3f80520265788a64d603fa6753f1
Modulus Length (a.k.a. "key length"): 2048 bit
Valid From (YYYY-MM-DD): 2005-09-13
Valid To (YYYY-MM-DD): 2010-09-13
CRL HTTP URL: http://www.signatur.rtr.at/current.crl
OCSP URL: n. a.
Class (domain-validated, identity/organisationally-validated or EV):
Certificate Policy URL: http://www.signatur.rtr.at/de/repository/tkk-cp-10-20020909.html
CPS URL: http://www.signatur.rtr.at/de/repository/tkk-cps-14-20060612.html
Requested Trust Indicators (email and/or SSL and/or code): email and SSL and code

Reproducible: Always
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Summary: Electronic signatures and SSL/TLS authentication data based on Austrian certificates can be verified more easily if the top certificate of the Telekom-Control Commission is included by derfault. → Add Austrian Telekom-Control Commission CA certificate
Ulrich,

Thank you for that information.

What type of certificates are issued below this root? Domain-validated, organisationally-validated, Extended Validation or some combination?

Thanks,

Gerv
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
I confirm that the information about the Telekom-Control Commission and their CA certificates is correct.

The CRL is indirect, i.e. certificate and CRL issuers are not necessarily the same (cf. RFC 3280, section 5.3.4). This might be the reason why the CRL does not work with Firefox.

Best regards,
Ulrich Latzenhofer
Mr Latzenhofer,

I'd like to get to the bottom of the relationship between the TKK and other Austrian certificate service providers. You say:

"For every CA key used by an Austrian certification service provider, the TKK issues a certificate to the certification service provider. Based on these certificates, all certificates issued by supervised Austrian certification service providers can be verified."

This implies to me that the TKK holds the root, and all accredited CSPs in Austria have intermediate certificates signed by that root. This idea is reinforced by what was said in bug 346614. So we would only need to include your root for certificates issued by all of them to work.

However, I have also received separate applications from various Austrian certificate authorities. For example:

a.trust (bug 373746) seem confused as to whether including your root will make their certificates work.

ARGE DATEN (bug 348987) say that, while they are accredited by you, they don't chain back to your root.

Could you perhaps explain the situation to me?

Thanks,

Gerv
Mr Latzenhofer: have you been able to consider my questions? Without some clarity on the situation, it is difficult to make progress on this application or that of other CAs that the TKK has audited (such as a.trust, bug 373746).

Gerv
Dear Gerv,

Your understanding of our CA is essentially correct. However, certificates are not only issued to accredited CSPs because accreditation is voluntary (pursuant to the Electronic Signatures Directive 1999/93/EC). Certificates are also issued to CSPs who are supervised under Austrian law (i.e. all CSPs established in Austria).

Although the specific arguments of A-Trust (bug 373746) and Arge Daten (bug 348987) for exclusively using their own certificate hierarchy are perfectly in line with legal requirements, there are eleven other active CSPs who are supervised under Austrian law. It is for the benefit of all holders of Austrian certificates that RTR has applied for including the TKK certificate with Mozilla software.

Best regards,
Ulrich Latzenhofer
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
I have begun this evaluation. I don't speak German, and pushing text through Google Translate takes time, so please could you answer the following questions?

Which exact section of the CP or CPS says:

a) that, for certificates issued for email signing use, you verify that the applicant has control of the email address in question;

b) that, for certificates issued for SSL use, you verify that the applicant has control of the domain in question;

c) that, for certificates issued for code signing, you verify the identity of the applicant.

In each case, "you verify" could be replaced with "you contractually oblige your sub-CAs to verify".

Further questions:

- Your audit report is four years old. How often do you get re-audited?

- Your audit report is for an organisation called "Rundfunk und Telekom Regulierungs-GmbH". How can I confirm that this is the same thing as the Telecom Control Commission?

- Do you publish a certificate hierarchy diagram?

That'll do for now :-)

Gerv
Ulrich: are you able to answer my questions above? Please comment soon, or this bug will be closed.

Gerv
Dear Gerv,

The CPS of the Telekom-Control Commission lays down the requirements only for certificates issued by the Telekom-Control Commission. The registration process (in particular, verification of identity) is described in chapter 3. However, the Telekom-Control commission does not issue certificates for signing e-mails or for code signing, and the only SSL certificates issued by the Telekom-Control Commission are those for the directory servers www.signatur.rtr.at and ldap.signatur.rtr.at.

The CPS does not lay down requirements for certification service providers ("sub-CAs") because these requirements are given by law. An English version of the Austrian Electronic Signature Act is available at http://www.ris.bka.gv.at/erv/erv_1999_1_190.pdf.

The Telekom-Control Commission is an authority of last instance. The Electronic Signature Act does not provide for an additional authority supervising the supervisory authority. For that reason, the CPS requires only internal audits which are performed by an "independent" head of department who is not organizationally linked to the staff operating the PKI. The audit requirements are given in section 2.7 of the CPS. The frequency of internal audits is at least one per year. Coordination with a designated body (within the meaning of Art. 3(4) of Directive 1999/93/EC) is only required in case of changes in the policy or in the technical infrastructure.

Rundfunk und Telekom Regulierungs-GmbH is the office (operative arm) of the Telekom-Control Commission. For details on the relation between Rundfunk und Telekom Regulierungs-GmbH and the Telekom-Control Commission please refer to http://www.signatur.rtr.at/en/supervision/tkk.html, http://www.signatur.rtr.at/en/supervision/rtr.html, and http://www.rtr.at/web.nsf/englisch/Ueber+Uns?OpenDocument.

A certificate hierarchy diagram can be found on page 12 of the CPS. Please let me know if you need a larger version.

Best regards,
Ulrich Latzenhofer
OK, so let me have another go at understanding this.

Austrian CSPs are audited by the TKK/RTR to ETSI standard. If they pass, their keys are signed by the TKK to bring them into the hierarchy.

Therefore, by admitting the TKK's roots, we are in fact starting to trust certificates issued by a number of different CSPs, all of which have been audited by the TKK/RTR.

Is that about right?

If so, then I suppose what we would need is:

- Evidence that the TKK has a requirement for ETSI or other Mozilla-approved auditing before bringing a CSP into the hierarchy.

- Details of the requirements on validation of information which are put on these CSPs (are these in the law?).

Gerv


Following some careful analysis from Mozilla community members, my current view is that the TKK root cannot be included in the Mozilla store.

The reason for this is that TKK signing does not have a uniform meaning (e.g. ETSI audited). The Austrian Electronic Signature Act governs which CSPs have their keys signed, but this Act does not lay down audit requirements (comment 11, paragraph 2). So some signed CAs may be correctly audited and others may not. This means that, by including the TKK root, we would be enabling CAs which do not meet our policies.

As far as we are aware, it would be technically possible to include the intermediate certs for qualifying CAs in the root store. If a CA with such a certificate applied, we would consider this.

Gerv
Accordingly, resolving WONTFIX.

Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.