Introduction: I have been reviewing the inclusion requests of Austrian CAs which are inter-related to each other and I think to have gathered enough information in order to make a recommendation. This report was compiled by the documentation made available by the requesters on Bugzilla and other web sites, mainly that of RTR. The review I performed could be described as extensive and this report is my conclusion on the subject which includes only the most important points, but anything not known to me as of this writing might change various aspects of this report. I have a good knowledge in PKI and master the German language natively.
Under consideration for inclusion are three requests: Austrian TCC: http://www.mozilla.org/projects/security/certs/pending/#Austrian%20TCC ARGE DATEN: http://www.mozilla.org/projects/security/certs/pending/#ARGE%20DATEN A-Trust: http://www.mozilla.org/projects/security/certs/pending/#A-Trust Relevant Bugzilla entries are: Austrian TCC: https://bugzilla.mozilla.org/show_bug.cgi?id=373174 ARGE DATEN: https://bugzilla.mozilla.org/show_bug.cgi?id=348987 A-Trust: https://bugzilla.mozilla.org/show_bug.cgi?id=373746 General Information: 1.) Telekom-Control Commission was established under the Telecommunications Act (TKG) of 1997 as the regulatory authority for the Austrian telecommunications market. The Telekom-Control Commission was also assigned responsibility as supervisory authority for electronic signatures in Austria. In carrying out its supervisory activities, the Telekom-Control Commission uses the Services of RTR GmbH which is responsible for maintaining Austria's directories of certification-service-providers. RTR as performed an ETSI based audit in 2002 which was performed by "Secure Information Technology Center - Austria". I have no information available about the auditor. TCC has one root certificate and five intermediate certificates which are used for the issuing of (intermediate) certificates to service providers in Austria. TCC doesn't issue end user certificates. 2.) There are no minimal verification requirements placed on CAs except notification to TCC, which doesn't have any special meaning beyond that. TCC however issues intermediate certificates to the CAs and provides a list of them at their web site: http://www.signatur.rtr.at/en/providers/services.html References: From http://signatur.rtr.at/en/legal/overview.html and http://www.ris.bka.gv.at/erv/erv_1999_1_190.pdf (Austrian Electronic Signature Act) find the following statements: From Overview: "The admission and practice of the activity of a certification service tenderer do not require separate permission. The service provider (CA) must only notify the activity to the supervision place." From Electronic Signature Act, Section 3.6: "Certification service providers shall require no special permit to establish and exercise their activities." From Bugzilla (Representative of TCC) https://bugzilla.mozilla.org/show_bug.cgi?id=373174#c7: "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)." 3.) The Electronic Signature Act has provisions for "voluntary accreditation" and "qualified certificates". The voluntary accreditation ( http://signatur.rtr.at/en/legal/sigg17.html ) has some technical safety requirements ( http://signatur.rtr.at/en/legal/sigg18.html ). CAs which have been accredited and issue "qualified certificates" as outlined in the Electronic Signature Act (Section 3.7-8) are marked accordingly on http://www.signatur.rtr.at/en/providers/services.html Intermediate CA certificates for accredited and "qualified" CAs are issued from the Sub-root of TCC marked "Accredited Certification Services 1" 4.) http://www.signatur.rtr.at/en/providers/services.html provisions the revocation of intermediate CA certificates under the circumstances outlined in Section 3.9 5.) RTR requests the inclusion of its root on behalf of TCC. ARGE DATEN created their own (self-signed) roots with the same public key as issued by TCC, however with longer validity. They request the inclusion of these certificates, instead of the ones issued by TCC. ( https://bugzilla.mozilla.org/show_bug.cgi?id=348987#c5 ) (Note: The root labeled "GLOBALTRUST" shall be used for the issuing of intermediate CA certificates ( https://bugzilla.mozilla.org/show_bug.cgi?id=348987#c8 ), however their CPS/CP doesn't state such usage, only the issuance to end users) A-Trust created four different CA roots without any relation to TCC. The four roots however signed the same public keys of their intermediate certificates, some of which were also signed by TCC ( see http://www.a-trust.at/DOCS/CA-Hierarchy_v10.pdf ). They request to include the four roots. (Note: There are intermediate CA certificates under the four roots which are not listed on the RTR list, clarification has been requested) 6.) ARGE DATEN and A-Trust claim to have undergone an audit based on ETSI by TCC, however no such information exists neither in the Electronic Signature Act nor on the web site of RTR. No audit statements have been provided either. (See bugs) 7.) Page about Accreditation on http://www.signatur.rtr.at/en/providers/properties/accredited.html explains further: "Therefore, the fact that a certification-service-provider is accredited does not necessarily mean that all of the provider's certification services comply with the same quality standards." ARGE DATEN has _not_ undergone "voluntary accreditation" or "qualified certificates": http://www.signatur.rtr.at/en/providers/services/argedaten-globaltrust.html and http://www.signatur.rtr.at/de/providers/services/argedaten-a-cert.html A-Trust has one active intermediate CA under "voluntary accreditation" or "qualified certificates": http://www.signatur.rtr.at/de/providers/services/atrust-asign-premium.html The others are not "accredited". Also it has intermediate CAs which issue code signing certificates upon email verification and phone callback only: http://www.signatur.rtr.at/de/providers/services/atrust-asign-light.html 8.) The Austrian Electronic Signature Act is currently not an acceptable criteria for CA operations of the Mozilla CA policy (Section 8, http://www.mozilla.org/projects/security/certs/policy/ ) Preliminary summary: 1.) TCC has undergone an ETSI audit in 2002 and assuming the auditor to be acceptable by Mozilla, could be considered for inclusion (provided also that the audit is considered valid). However different aspects aren't compatible with the Mozilla CA policy. 2.) The purpose of the TCC root is to issue intermediate CA certificates to service providers in Austria. 3.) The Austrian Electronic Signature Act doesn't obligate CAs to minimal verification methods, as outlined in the Mozilla CA policy http://www.mozilla.org/projects/security/certs/policy/ section 7. 4.) TCC doesn't control the various service providers nor their implementations CP/CPS. The statement by the TCC representative confirms this at https://bugzilla.mozilla.org/show_bug.cgi?id=373174#c11 : "The CPS does not lay down requirements for certification service providers ("sub-CAs") because these requirements are given by law." Recommendations: 1.) The TCC root CA should not be included, because it doesn't control the service providers (and their policies) to whom it issues the certificates and the Austrian Electronic Signature Act doesn't obligate CAs to minimal verification methods. 2.) The roots of ARGE DATEN should not be included, because no audit statement has been provided nor are their CA services marked by RTR as accredited or qualified. 3.) The roots of A-Trust should not be included, because the intermediate CAs issued under those roots have different qualifications, including at least one which could be considered with insufficient verification methods (for code). Additionally the majority are not accredited or qualified by RTR except one (active). 4.) Under consideration for inclusion could be the intermediate CA certificate of TCC labeled "Accredited Certification Services 1" (issues certificates to CAs accredited under the Austrian accreditation scheme) since TCC has some control over them according to the Austrian Electronic Signature Act. The lifetime of this (intermediate) root (expiry date) should be checked however. 5.) Alternatively under consideration could be any intermediate CA certificate issued to A-Trust which is marked as "voluntary accredited" and qualified certificate" ( http://www.signatur.rtr.at/de/providers/services/atrust-asign-premium.html ). All other intermediate CA certificates issued by TCC to A-Trust should not be included. 6.) In order for A-Trust and ARGE DATEN to have their roots included, I recommend that they provide an explicit audit statement according to one of the criterion acceptable by the Mozilla CA policy. TCC could be _considered_ by Mozilla as an acceptable auditor even so they act as a super CA (requires further discussion?) Summary: The inclusion recommendations of #4 and #5 are not strictly roots certificates, but intermediate CA certificates issued by TCC. But in light of the special situation of CAs in Austria I recommend considering inclusion of those as an acceptable compromise, instead of rejecting the requests altogether. Feel free to challenge my assessment and I'm glad to provide additional information not included in this report. Also as noted in the introduction, additional information provided by the requesting CAs might provide a different result than presented here. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
