Closed Bug 892390 Opened 11 years ago Closed 10 years ago

Add T-Systems Root CA Certificate

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bernd.nakonzer, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Approved - in FF 29)

Attachments

(5 files)

      No description provided.
I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
Whiteboard: Information incomplete
The answers and additions in the document are highlighted green.
I'll try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: Information incomplete → Information confirmed complete
I am now opening the first public discussion period for this request from T-Systems to include the “T-TeleSec GlobalRoot Class 2” root certificate, and turn on the Websites and Email trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

The discussion thread is called “T-Systems Request to Include Renewed Root”.

Please actively review, respond, and contribute to the discussion.

A representative of T-Systems must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to include the “T-TeleSec GlobalRoot Class 2” root certificate, and turn on the Websites and Email trust bits. This SHA-256 root will eventually replace the “Deutsche Telekom Root CA 2” root certificate that was included via Bugzilla Bug #378882.  

Section 4 [Technical]. I am not aware of instances where T-Systems has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Section 6 [Relevance and Policy]. T-Systems appears to provide a service relevant to Mozilla users. It is part of Deutsche Telekom Group, which is serving more than 50 million customers worldwide and about 160.000 business customers. T-Systems Trust Center is the organizational unit issuing certificates, and their focus is mainly Western Europe, especially Germany, but there are some international customers as well.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the ServerPass CPS and the Shared-Business-CA CPS.

Document Repository: http://www.telesec.de/pki/roots.html 
ServerPass CPS (German): http://telesec.de/serverpass/cps.html 
ServerPass CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=555341 
Shared-Business-CA CPS (German): http://telesec.de/sbca/cps.html  
Translations of some sections of the Shared-Business-CA CPS: 
https://bug892390.bugzilla.mozilla.org/attachment.cgi?id=801757  

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

* SSL: According to the ServerPass CPS sections 3.2.2 and 3.2.5, T-Systems verifies the organization, the authority of the certificate subscriber to request the certificate, and that the customer owns the domain or has been given the exclusive right to use the domain to be included in the certificate. Official directories and Whois are checked.

** Shared-Business-CA CPS section 3.2.5.2: The customer notifies T-Systems of the domains for which certificates are to be issued so that T-Systems can check them, include them in the client’s PKI configuration as “permitted Internet domains” and maintain them. … The T-Systems registration authority employee checks for each entry whether the customer (client) has the legitimate right to use the relevant domain. This involves querying the online database of the country-specific NIC unit (e.g., Denic eG for Germany) for geographic ccTLDs or the online database of the WhoIs for gTLDs. To check an IP address, adequate online databases are queried.

* Email: According to the Shared-Business-CA CPS section 4.2.1, the RA has to verify the email address to be included in the certificate by using a challenge response procedure where the end user is requested proactively to verify the existence of the e-mail address.

* Code: Not applicable. Not requesting the code signing trust bit.

Section 18 [Certificate Hierarchy]
T-Systems allows for both internally and externally operated subordinate CAs. 
There is one externally-operated subordinate CA, Deutsches Forschungsnetz (DFN), that will eventually be migrated from “Deutsche Telekom Root CA 2” root to this new “T-TeleSec GlobalRoot Class 2” root. DFN has a separate ETSI-Audit and operates a sub-CA for the Global security level certificates that are described in their CP. DFN’s subordinate CAs are operated in-house by DFN, as described in policy documentation. Within the DFN hierarchy allowable domains are whitelisted, and the process to add a new domain involves direct contact with DFN-CA and demonstration of administrative control over the domain, especially in terms of WHOIS.

* EV Policy OID: Not applicable. Not requesting EV treatment for this root.

* CRL 
http://pki.telesec.de/rl/GlobalRoot_Class_2.crl 
http://crl.serverpass.telesec.de/rl/GlobalCA_Class_2.crl 
ServerPass CP/CPS section 4.9.7: …of end entities, is updated once a day and published by the repository.

* OCSP
http://ocsp.telesec.de/ocspr 
http://ocsp.serverpass.telesec.de/ocspr
CPS section 4.9.9: T-Systems maintenance a OCSP responder signed by the Root-CA to validate issued Sub-CA certificates. OCSP responses are valid for three (3) days. The OCSP repository is updated within 24 hours in cases a certificate is revoked.
Sub-CA Requirements: Sub-CAs must maintain an OCSP responder to validate issued certificates. OCSP responses must have a maximum expiration time of ten (10) days. The OCSP repository must be updated at least every four (4) days. 

Sections 11-14 [Audit]. 
Annual audits are performed by Ernst & Young, according to the WebTrust criteria.
https://cert.webtrust.org/SealFile?seal=1531&file=pdf  
http://telesec.de/downloads/TSI13WebTrust-RootCAs_BaselineReport_final.pdf 

Based on this assessment I intend to approve this request to include the “T-TeleSec GlobalRoot Class 2” root certificate, and turn on the Websites and Email trust bits.
Whiteboard: In public discussion → Pending Approval
As per the summary in Comment #8, and on behalf of Mozilla I approve this request from T-Systems to include the following root certificate:

** “T-TeleSec GlobalRoot Class 2” (websites, email)

I will file the NSS bug for the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Depends on: 935687
I have filed bug #935687 against NSS for the actual changes.
Whiteboard: Approved - awaiting NSS → Approved - in FF 29
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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: