Closed Bug 348987 Opened 19 years ago Closed 15 years ago

Add Austrian ARGE DATEN root certificate

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: info, Assigned: hecker)

Details

(Whiteboard: information incomplete)

Attachments

(2 files)

A-CERT ADVANCED certificate hierarchy diagram
7.21 KB, image/png
Details
GLOBALTRUST certificate hierarchy diagram
17.68 KB, image/png
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Dear Mozilla Team, we, ARGE DATEN, would like to have our new root certificate included in the default Mozilla certificate store. We are a leading Austrian certificate authority, accredited by the Austrian control authority and in accordance with the EU signature directive. GLOBALTRUST Root Certificate: http://www.globaltrust.info/static/globaltrust2006.crt GLOBALTRUST CRL: http://www.globaltrust.info/static/globaltrust2006.crl GLOBALTRUST CP/CPS: http://www.globaltrust.info/static/globaltrust2006-certificate-policy-english.pdf Information about 3rd Party Audits: http://www.globaltrust.info/static/third-party-audits.pdf Reproducible: Always
Additional Information: In the CA hierarchy associated with the GLOBALTRUST CA certificate, certificates will be issued for purposes including - SSL-enabled servers, - digitally-signed and/or encrypted email, and - digitally-signed executable code objects.
I confirm that this is an enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The Austrian Government Agency the Telekom-Control-Kommission displays details about the new ARGE DATEN Root at the Control Authority's official Homepage: http://www.signatur.rtr.at/de/providers/services/argedaten-globaltrust.html Audit Confirmation by the Austrian Government Agency the Telekom-Control-Kommission http://www.a-cert.at/static/rtr-audit-2006-4.pdf
This CA is one of the 13+ root CAs now listed for inclusion in https://www.signatur.rtr.at/en/providers/providers.html Bug 346614 requests that all of those CAs be included.
Summary: Add ARGE DATEN root certificate → Add Austrian ARGE DATEN root certificate
QA Contact: ca-certificates
It is important to note that the certificates available at https://www.signatur.rtr.at/en/providers/providers.html (listed under 'Certificate in the supervisory authorities" directory') are NOT necessarily equivalent to the certificates actually in use by the listed CAs. The reason for this (in our case) is that we use a self-signed certificate instead of a certificate issued by the RTR (both certificates are issued for the same public key, of course) for the following technical and organizational reasons: -) The whole certificate chain to the end-user certificates is under our control. The CA certificate issued by the RTR is not issued directly from the RTR root certificate, so a mechanism is needed to supply the intermediary certificates to the end-user for certificate validation. As the RTR CA certificate does not contain the AIA extension or any other information on how to retrieve intermediary certificates, the construction of the certificate chain is problematic. -) The lifetime of the CA certificates issued by the RTR can not be controlled by the CA. It is very short (3 years), and together with the path validation as defined in RFC 3280 - "Note that mechanisms are not available for validating a certificate with respect to a time outside the certificate validity period." - is prone to create problems because end-user certificates with a longer validity period than the CA certificate have to be issued.
If you do decide to include all the certificates from the CAs listed at https://www.signatur.rtr.at/en/providers/providers.html, please include the following A-CERT ADVANCED certificate instead of the one found at the RTR directory for the same reasons: A-CERT ADVANCED Root Certificate: http://www.a-cert.at/static/a-cert-advanced.crt Audit Confirmation by the Austrian Government Agency the Telekom-Control-Kommission: http://www.a-cert.at/static/rtr-audit-2004-7.pdf
Priority: -- → P2
There are a large number of outstanding CA requests, and it will take me some time to work through them. I can tell you that I will need the following data for each request. If some of this data is missing, the request cannot proceed. 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. This means I can make everyone happier, quicker :-) Please give data in the following format, as a *plain text comment*. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates. 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: MD5 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-validated or EV): Certificate Policy URL: CPS URL: Requested Trust Indicators (email and/or SSL and/or code): Thanks for your help in this matter. :-) Gerv
CA Details ---------- CA Name: ARGE DATEN - Austrian Society for Data Protection Website: www.a-cert.at, www.globaltrust.info ARGE DATEN, the Austrian Society for Data Protection is a registered Society - a non-profit non-governmental organisation. ARGE DATEN maintains a privacy web service free of charge with about 40-80.000 visitors a month, issues a free privacy newsletter with about 4000 subscribers. ARGE DATEN has a very large media presence in Austria. ARGE DATEN is the Austrian market leader in issuing certificates for eBilling. Our certificates are sold all over Austria and in parts of Germany. The following subordinate CAs are currently operated: -) eBilling (A-CERT ADVANCED) -) SSL Server Certificates (A-CERT GLOBALTRUST) -) SSL Client Certificates (A-CERT CLIENT) -) Certificates issued for members of governmental institutions (A-CERT GOVERNMENT) -) Test certificates (A-CERT FREECERT) Both the A-CERT ADVANCED and the GLOBALTRUST root certificates have been accepted for inclusion into the Microsoft Windows trusted root certificate store. Audit Type (WebTrust, ETSI etc.): Audit by TKK - the Austrian governmental authority Auditor: Rundfunk und Telekom Regulierungs GmbH Auditor Website: www.rtr.at Audit Document URL(s): http://www.signatur.rtr.at/de/providers/services/argedaten-globaltrust.html, http://www.signatur.rtr.at/de/providers/services/argedaten-a-cert-advanced.html,http://www.globaltrust.info/static/third-party-audits.pdf Certificate Details ------------------- Certificate Name: A-CERT ADVANCED This root certificate issues both end-user certificates and CA certificates. The policy OID is 1.2.40.0.24.1.1.1.3. It is the current root certificate of ARGE DATEN. Certificate HTTP URL (on CA website): http://www.a-cert.at/static/a-cert-advanced.crt Version: X509v3 SHA1 Fingerprint: 29:64:B6:86:13:5B:5D:FD:DD:32:53:A8:9B:BC:24:D7:4B:08:C6:4D MD5 Fingerprint: B4:4A:DB:E8:59:16:46:1E:5A:D8:6E:DA:06:43:52:62 Modulus Length (a.k.a. "key length"): 2048 Valid From (YYYY-MM-DD):2004-10-23 Valid To (YYYY-MM-DD): 2011-10-23 CRL HTTP URL: http://www.a-cert.at/static/advanced.crl OCSP URL: http://ocsp.a-cert.at Class (domain-validated, identity-validated or EV): identity-validated Certificate Policy URL: http://www.a-cert.at/static/a-cert-certificate-policy-english.pdf CPS URL: http://www.a-cert.at/static/a-cert-certificate-policy-english.pdf Requested Trust Indicators (email and/or SSL and/or code): email and SSL and code Certificate Details ------------------- Certificate Name: GLOBALTRUST This root certificate will not directly issue end-user certificates. It is used to issue the subordinate CA certificates which in turn issue the end-user certificates. The policy OID is 1.2.40.0.24.1.1.8.1. This certificate is the logical successor to the A-CERT ADVANCED root certificate. Certificate HTTP URL (on CA website): http://www.globaltrust.info/static/globaltrust2006.crt Version: X509v3 SHA1 Fingerprint: 34:2C:D9:D3:06:2D:A4:8C:34:69:65:29:7F:08:1E:BC:2E:F6:8F:DC MD5 Fingerprint: DF:0D:BC:7C:C8:36:B7:76:99:A1:AB:F0:D2:0F:89:6A Modulus Length (a.k.a. "key length"): 4096 Valid From (YYYY-MM-DD): 2006-08-07 Valid To (YYYY-MM-DD): 2036-09-18 CRL HTTP URL: http://www.globaltrust.info/static/globaltrust2006.crl OCSP URL: Class (domain-validated, identity-validated or EV): identity-validated Certificate Policy URL: http://www.globaltrust.info/static/globaltrust2006-certificate-policy-english.pdf CPS URL: http://www.globaltrust.info/static/globaltrust2006-certificate-policy-english.pdf Requested Trust Indicators (email and/or SSL and/or code): email and SSL and code
Thank you for that information. Some questions: - Do you offer OCSP for certificates which chain back to the GLOBALTRUST root? - Could you explain a bit more about how the audits you have had done relate to the ETSI standards? Thanks, Gerv
Charlotte: It's been over three weeks; are you able to provide the requested information? Thanks, Gerv
(In reply to comment #10) Dear Gerv ARGE DATEN fulfills all the Requirements of The Directive 1999/93EC of the European Parliament and the Austrian Signature ACT which corresponds to ETSI TS 102 042 for issuing advanced certificates. This is mentioned in the "Positionpaper for advanced Signatures (2.b)" of the The RUNDFUNK UND TELEKOM REGULIERUNGS-GMBH (RTR-GMBH). http://www.signatur.rtr.at/de/repository/rtr-advancedsignature-10-20040413.html Ulrich Latzenhofer the auditor of RTR GmbH has confirmed this. OCSP is in the process of being implemented we will let you know as soon as we have completed the process of implementation Charlotte > Charlotte: It's been over three weeks; are you able to provide the requested > information? > > Thanks, > > Gerv >
Reassign all open CA bugs to me. Apologies for the bugspam. Gerv
Assignee: hecker → 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
The information on the CA root certificate request list concerning our CA is correct. Thank you very much for your efforts, Charlotte
I have begun this evaluation, and have some questions: - The A-CERT CRL is issued on a 2-weekly basis, which seems a bit long, but the GLOBALTRUST one is issued on a 6-monthly basis (nextUpdate is six months after thisUpdate). Are there any plans to change this? - Do you have a certificate hierarchy diagram anywhere? - Any news on OCSP for the GLOBALTRUST root? - My lack of German is hindering my understanding of the audit situation. You are claiming that you have been audited against ETSI TS 102042, is that right? For other ETSI-audited CAs, they have a certificate from the auditor confirming the successful completion of the audit. Is that what this http://www.signatur.rtr.at/de/providers/services/argedaten-globaltrust.html is? If so, where does it talk about ETSI? Thanks for any light you can shed, Gerv
Dear Gerv, Regarding your questions: - We of course issue new CRLs as soon as we have processed incoming revocation requests. We have not yet issued any GLOBALTRUST user certificates - as soon as the service goes "live", we will issue the CRL more frequently: it is planned to issue a new GLOBALTRUST CRL 2-weekly in the case that no revocation requests are received. As a reference, Verisign issues their EV CRL 2-weekly and their Class 3 CRL 3-monthly [1][2]. We have not found any provision that justifies shorter intervals between issuing CRLs when no revocations have taken place. - Please find attached our certificate hierarchy diagrams for the A-CERT ADVANCED and the (planned) GLOBALTRUST hierarchy. - The GLOBALTRUST OCSP service went online last week. It is accessible at http://ocsp.a-cert.at. It is planned to make it available also at http://ocsp.globaltrust.eu in the future. - The audit by the RTR is done based on the notification submitted to the RTR. The data from this notification is available at the URL you quoted. Our last notification to the RTR which explicitly includes ETSI TS 102 042 conformance in the CP is not online yet - you can find the updated CP at [3]. The data should appear on the RTR website shortly. kind regards, Charlotte [1] http://EVIntl-crl.verisign.com/EVIntl2006.crl [2] http://crl.verisign.com/pca3.crl [3] http://www.globaltrust.eu/static/globaltrust-certificate-policy-english.pdf
(In reply to comment #16) > the service goes "live", we will issue the CRL more frequently: it is planned > to issue a new GLOBALTRUST CRL 2-weekly in the case that no revocation > requests > are received. As a reference, Verisign issues their EV CRL 2-weekly and their > Class 3 CRL 3-monthly [1][2]. We have not found any provision that justifies > shorter intervals between issuing CRLs when no revocations have taken place. Are the referenced Verisign CRLs for end-entity certificates or for intermediates? It is OK to have longer periods for intermediates. It is not useful to increase issuing frequency only when revocations have taken place, because clients may well not check the CRL again until the nextUpdate date is reached. If that date is normally two weeks away, then if they have just obtained one, it could be that long before they notice the revocation, even if you publish a new CRL immediately. There are no requirements about CRL issuance frequency in our policy at the moment, but I would advise you to reconsider this approach. > - The audit by the RTR is done based on the notification submitted to the RTR. > The data from this notification is available at the URL you quoted. Our last > notification to the RTR which explicitly includes ETSI TS 102 042 conformance > in the CP is not online yet - you can find the updated CP at [3]. The data > should appear on the RTR website shortly. I would be happier when the RTR website explicitly states that you have been audited to ETSI TS 102 042. Assuming that "shortly" means "in a few days", please let me know when this has been done and I will complete the approval. Gerv
Dear Gerv, the requested document is now online on the RTR website. http://www.signatur.rtr.at/de/repository/csp-argedaten-cp-globaltrust-16-20070605.html http://www.signatur.rtr.at/repository/csp-argedaten-cp-globaltrust-16-20070605-de.pdf http://www.signatur.rtr.at/de/repository/csp-argedaten-cp-acertadvanced-15-20070605.html http://www.signatur.rtr.at/repository/csp-argedaten-cp-acertadvanced-15-20070605-de.pdf it is stated in these documents that we are audited by the Control Authority according to ETSI 102 042. We very much hope that our approval will be completed now. Charlotte
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 ARGE DATEN, 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]. ARGE DATEN appears to provide a service relevant to Mozilla users: they are an Austrian NGO issuing certificates to the general public. Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Section 7 [Validation]. ARGE DATEN 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), ARGE DATEN verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate. (See section IV.D.2 in both A_CERT CP v1.5 and GLOBALTRUST CP v1.5.) * SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), ARGE DATEN verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See section IV.D.2 in both A_CERT CP v1.5 and GLOBALTRUST CP v1.5.) * Code: The Code Signing EKU (1.3.6.1.5.5.7.3.3) is not specifically mentioned in their documents; however, for all certificates issued, ARGE DATEN verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (See section IV.D.2 in both A_CERT CP v1.5 and GLOBALTRUST CP v1.5.) Section 8-10 [Audit]. ARGE DATEN has successfully completed an audit using the ETSI TS 101 042 criteria. The auditors were Rundfunk Und Telekom Regulierungs GmbH. The audit is currently valid. Section 13 [Certificate Hierarchy]. ARGE DATEN has multiple intermediate CAs under two roots - A-CERT and GLOBALTRUST. Each intermediate is used for a different type of end entity certificate. Other: ARGE DATEN issues CRLs (on a 2-weekly 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
(In reply to comment #5) Charlotte Schönherr <info@a-cert.at> wrote: > It is important to note that the certificates available at > https://www.signatur.rtr.at/en/providers/providers.html (listed under > 'Certificate in the supervisory authorities" directory') are NOT necessarily > equivalent to the certificates actually in use by the listed CAs. > > The reason for this (in our case) is that we use a self-signed certificate > instead of a certificate issued by the RTR (both certificates are issued for > the same public key, of course) for the following technical and organizational > reasons: > -) The whole certificate chain to the end-user certificates is under our > control. The CA certificate issued by the RTR is not issued directly from the > RTR root certificate, so a mechanism is needed to supply the intermediary > certificates to the end-user for certificate validation. As the RTR CA > certificate does not contain the AIA extension or any other information on how > to retrieve intermediary certificates, the construction of the certificate > chain is problematic. The existing standards for TLS, S/MIME and JAR signing all require that the signer (or the TLS server) send (or include with its signature) a complete cert chain up to, but not including the root CA cert. So, for TLS servers, the burden is on the TLS server administrator to include the relevant intermediate CA certificates, so that they are sent to clients that verify the server certs. This relieves the relying party of any need to fetch additional intermediate CA certificates using AIA extensions. In light of this, I wonder how to interpret the above quoted statement. Charlotte, for WHOM is the construction of the certificate chain thought to be problematic? It is not a problem for browser users, because the TLS server sends out a complete chain. Perhaps it is a problem for server administrators, but surely it is not difficult to instruct them on how to install and configure intermediate CA certificates into the servers, is it? Are we to understand that ARGE DATEN issues all EE certificates directly from its root CA certificate, and not through any intermediate CA certificate? > -) The lifetime of the CA certificates issued by the RTR can not be controlled > by the CA. It is very short (3 years), and together with the path validation as > defined in RFC 3280 - "Note that mechanisms are not available for validating a > certificate with respect to a time outside the certificate validity period." - > is prone to create problems because end-user certificates with a longer > validity period than the CA certificate have to be issued. Have to be? EE Certificates with long validity periods are problematic for revocation checking - they make CRLs grow to become quite large. What are the maximum validity periods for EE certificates now being issued?
Gerv, In light of comment #5, I think it behooves Mozilla (and you :-) to verify that the public keys in the root CA certs that the CA wishes to include in Mozilla has the same public key as the cert that was issued by RTR to attest to their successful audit (or whatever they do).
(In reply to comment #22) >In light of this, I wonder how to interpret the above quoted statement. >Charlotte, for WHOM is the construction of the certificate chain thought to >be problematic? >It is not a problem for browser users, because the TLS server sends out a >complete chain. >Perhaps it is a problem for server administrators, but surely it is not >difficult to instruct them on how to install and configure intermediate CA >certificates into the servers, is it? You are right that construction of the certificate chain is not problematic for users of TLS servers. It is problematic for other uses of digital signature involving end-user to end-user communications (e.g. secure email), where the user is often the same person as the system administrator. We want the end-user experience to be as seamless as possible (for many users, digital signatures are already too complicated!), without requiring our end-users to do unnecessary configuration. >Are we to understand that ARGE DATEN issues all EE certificates directly from >its root CA certificate, and not through any intermediate CA certificate? No, this is not the case. Please have a look at the certificate hierarchy diagrams in comments #17 and #18. >Have to be? EE Certificates with long validity periods are problematic for >revocation checking - they make CRLs grow to become quite large. What are >the maximum validity periods for EE certificates now being issued? The maximum validity period for EE certificates issued by us is 4 years.
Following some careful analysis from Mozilla community members, some important questions have been raised about this application. The following is my summary of those concerns, as I understand them (which may be incorrect). Comment 20 points to some documents which purport to prove that RTR has done an ETSI 102 042 audit of ARGE DATEN, but those documents are in fact provided by ARGE DATEN. They are not statements from RTR. The RTR site explicitly says that ARGE DATEN isn't "voluntary accredited" nor issues "qualified certificates". The link in comment 11 leads eventually to: http://www.signatur.rtr.at/repository/rtr-advancedsignature-10-20040413-de.pdf In this document there is indeed a reference to ETSI, but it only says that the verification methods may be lesser than that of "qualified certificates" and refer for comparison to the ETSI standard. It does not state that ARGE DATEN has received an ETSI audit from RTR. To summarise: 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. Have you been subject to such an audit? If so, we need to see a clear statement from the auditor (not from you) to that effect. http://www.mozilla.org/projects/security/certs/policy/ Gerv
Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program. Gerv
Assignee: gerv → hecker
Whiteboard: In pending list - complete?
Nelson has asked me to summarise the missing information for this application. The answer is that the audit situation is still unclear, which is why no audit information appears on http://www.mozilla.org/projects/security/certs/pending/#ARGE%20DATEN Gerv
Whiteboard: In pending list - complete? → information incomplete
There has been no activity in this bug for over a year. Is this request obsolete?
Dear Mozilla Team, we maintain our request to have our root certificate included in the default Mozilla certificate store. In 2009 we signed a Certification Authority Agreement with Microsoft. Microsoft has recognised the application of Austrian Signatur Law (SigG 1999) based on the EU Digital Signature Directive (1999/93/EG) and therefore excepted our present audits and a three-year-period for renewing audits. We expect equal treatment by Mozilla. This would be beneficial for Mozilla as well because many of our leading certificate customers (ie. the Austrian Energy-Control-Authority or the Foreign Office) would no longer have to advise their visitors to avoid Mozilla because of this unjustified warning. We can forward our Contract with Microsoft on demand to Frank Hecker, but we cannot publish it in this bug this would breach confidence. Charlotte Schönherr
Did Microsoft except audits or accept audits? I don't think Mozilla should make any exceptions to its policies merely because of actions by Microsoft. Once an exception is made, it becomes difficult to deny other exceptions. More important, Microsoft is not an example of good security practices.
Please see comment #25, which explains what is needed in regards to the audit. If the request in comment #25 cannot be met by the CA, then I will close this bug.
Closing this bug. If the CA wishes to re-request inclusion, a representative of the CA may open a new bug as per https://wiki.mozilla.org/CA:How_to_apply and provide all of the information listed here: https://wiki.mozilla.org/CA:Information_checklist
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
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: