Closed Bug 436467 Opened 16 years ago Closed 13 years ago

Enable EV for new TC Universal III Root certificate

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Lindemann, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: EV - In FF4Beta )

Attachments

(6 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6)
Gecko/20070725 Firefox/2.0.0.6
Build Identifier: 

CA Details
----------

CA Name: TC TrustCenter GmbH
Website: http://www.trustcenter.de
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
TC TrustCenter is a commercial CA and has several accreditations, incl. German
Signature Act, SISAC, ETSI. 
We are based in Germany and have customers in all major regions of the world.
TC TrustCenter offer a variety of products and services including SSL Server
certificates and Email certificates.


Audit Type (WebTrust, ETSI etc.):       ETSI
Auditor:                                TÜV-IT Germany
Auditor Website:                        http://www.tuevit.de/
Audit Document URL(s):                  i can send the PDF version of the
reports by email.

URL of certificate hierarchy diagram:  
http://www.trustcenter.de/en/infocenter/root_certificates.htm

Reproducible: Always

Steps to Reproduce:
visit https://testserver.class4-ii.trustcenter.de/
Actual Results:  
"unknown or untrusted CA"

Expected Results:  
no additional warning appears, web site is being displayed instead.

4. Certificate Name:                                    TC TrustCenter Class 4
II
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):
Verification that the email address is accessible by the applicant and vetting
of the organization and vetting of the applicant according to EV guidelines.
This Root is being used to issue all types of certificate, e.g. Email Security,
SSL-Client-Authentication, SSL-Server, CodeSigning
Version:
SHA1 Fingerprint:                                      
a6:9a:91:fd:05:7f:13:6a:42:63:0b:b1:76:0d:2d:51:12:0c:16:50
Modulus Length (a.k.a. "key length"):                   RSA 2048 bit
Valid From (YYYY-MM-DD):                                23.03.2006 14:10:23 GMT 
Valid To (YYYY-MM-DD):                                  31.12.2025 22:59:59 GMT 
CRL HTTP URL:                                          
http://www.trustcenter.de/crl/v2/tc_class_4_ca_II.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:                                              
http://ocsp.tcclass4-ii.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): EV
Certificate Policy URL:                                
http://www.trustcenter.de/cpd
CPS URL:                                               
http://www.trustcenter.de/cps
Requested Trust Indicators (email and/or SSL and/or code): Email and SSL and
CodeSigning
URL of website using certificate chained to this root (if applying for SSL):
https://testserver.class4-ii.trustcenter.de/

Download-URL of the (DER encoded) certificates is:
http://www.trustcenter.de/media/class_4_ii.der

The ETSI report can be found at:
https://www.tuvit.de/certuvit/pdf/6706UE.pdf and
http://www.tuvit.de/certuvit/pdf/6705UE.pdf

Reproducible: Always
Component: Security: UI → CA Certificates
Product: Core → mozilla.org
Version: unspecified → other
This bug now contains the insertion request of the EV root certificate previously contained in bug 392024.
Whiteboard: EV - PROBABLY complete
This request is pending two things:

1) Updated CPS to reflect this root

2) WebTrust EV Audit
Assignee: kaie → hecker
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: ui → ca-certificates
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
Whiteboard: EV - PROBABLY complete → EV
Whiteboard: EV → EV - information incomplete
This is the new information:

The following root certificate should be included to the NSS root store and be marked as EV
Certificate Name:			TC TrustCenter Universal CA III
Version:				x509v3
SHA1 Fingerprint:			96:56:cd:7b:57:96:98:95:d0:e1:41:46:68:06:fb:b8:c6:11:06:87
Modulus Length (a.k.a. "key length"):		RSA 2048 bit
Valid From (YYYY-MM-DD):			2009-09-09 08:15:27 GMT
Valid To (YYYY-MM-DD):				2029-12-31 23:59:59 GMT
CRL HTTP URL:					http://crl.tcuniversal-III.trustcenter.de/crl/v2/tc_universal_root_III.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:	http://ocsp.tcuniversal-iii.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): EV
Certificate Policy URL:	http://www.trustcenter.de/cpd
CPS URL:		http://www.trustcenter.de/cps
Requested Trust Indicators (email and/or SSL and/or code): Email and SSL and CodeSigning
URL of website using certificate chained to this root (if applying for SSL): https://testserver.universal-iii.trustcenter.de/

The TC Policy OID for EV certificates is: 1.2.276.0.44.1.1.1.4. 
EV certificates will be issued off the L1 sub-CA "TC TrustCenter Class 4 Extended Validation CA I".

TC TrustCenter has passed the ETSI EV audit (ETSI TS 102042 v2.1.1). This audit type has been accepted the CA/B Forum.
The Audit report is now available at: http://www.tuvit.de/english/47347.asp
Clarification: 
The "TC TrustCenter Class 4 Extended Validation CA I" will be used to issue EV certificates only.
The "TC Universal CA III" root certificates will be used to issue DV, OV and EV certificates (using different Sub-CAs).
Summary: add new TC TrustCenter EV root certificate → Enable EV for new TC Universal III Root certificate
The attached document summarizes the information that has been gathered and verified as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.
here our responses to the questions raised in the information gathering document:

regarding 1) relation to "TC Universal CA I": they will both co-exist. 
regarding 2) relation to "TC Universal CA II": the "TC Universal CA II" will
effectively being replaced by the "TC Universal CA III". We had to generate
a new key (supervised by the auditor) to be compliant with the CA/B Forum
guidelines.

regarding 3) The "TC Universal CA III" will not have a "TC Class 0" Sub-CA.

regarding 4) Testservers: see https://bugzilla.mozilla.org/show_bug.cgi?id=436467#c8

regarding 5) No concrete plans yet. We might issue a "TC Class 3 L1 CA xx", "TC
Class 2 L1 CA yy" or ""TC Class 1 L1 CA zz" from this "TC Universal CA III"
in the future.

regarding 6) It might be possible to have externally operated sub-CAs chained to
this root. We'll follow the Mozilla policy for that. Such externally
operated sub-CAs would be limited to certificate policy OID different from
our EV certificate policy. 
The company operating it would either use it for
internal purposes or have an appropriate ETSI or WebTrust audit.

regarding 7) It is not planned to have the EV-Sub-CAs externally operated.

regarding 8) You are right, DV certificates are not yet included in the CPS. 

regarding 9) 
a) Long Lived DV certificates: not planned.
b) Wildcard DV SSL certificates: not planned.
c) Delegation of Domain / Email verification to third parties:
Same answer as for our other root certificates
(https://bugzilla.mozilla.org/show_bug.cgi?id=392024#c32): TC TrustCenter’s
external RAs are contractually bound to adhere to the
procedures specified in TC TrustCenter’s CPS and other relevant policies.
RAs are not allowed to use their own procedures and deviate from TC
TrustCenter’s policies.
How we verify that external RAs are adhering to our CPS:
- We distinguish between Local Registration Officers and External
Registration Officers.
- The Local Registration Officers are limited regarding their tasks. They
cannot vet organizations and domains. They can only perform personal vetting
for a limited and previously named set of organizations. Local Registration
Officers have been empowered by all affected organizations to perform that
role.
- External Registration Officers are allowed to vet organizations and
Domains.
They have to undergo a special training on the procedures. 
- Both, Local Registration Officers and External Registration Officers are
contractually bound to adhere to our CP/CPS.
- We perform random checks and we perform checks in case of abnormalities

d) Issuing end entity certificates directly from the root: Not planned. Will use intermediate CAs.
e) Allowing external entities to operate unconstrained subordinate CAs: not
planned.

f) Distributing generated private keys in PCKS#12 files: planned. PKCS#12
files are encrypted in our system. User can choose to receive the password
for the PKCS#12 PSE as an SMS (instead of an email). The PKCS#12 file is not attached to the email but must be downloaded from a URL with password protection.
This approach is particularly convenient for customers asking for key recovery (e.g. for email encryption certificates).

g) Certificates referencing hostnames or private IP addresses: 
for EV certificates: All EV certificates must have a name resolvable using DNS.
In general: Private IP addresses and unqualified host names (e.g. myserver) are not allowed.

h) OCSP responses signed by a certificate under a different root: not
planned

i) CRL with critical CIDP extension: not planned
This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: EV - information incomplete → EV - Information confirmed complete
I am re-reviewing this request in preparation for the upcoming public
discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Are these the current CPD and CPS that I should refer to?
CPS: http://www.trustcenter.de/media/CPS-TCTrustCenter-en.pdf
CPD: http://www.trustcenter.de/media/CPD-TCTrustCenter-en.pdf

My notes indicate that this request is also for enabling EV for this new TC TrustCenter Universal CA III” root certificate.  However, I am not able to find information about verification/issuance policies for EV certificates issued under the TC TrustCenter Universal CA III root. In the CPS the only reference to EV is in regards to Class 4 certificates. In the CPD I did not find reference to EV, and the only instance of Class 4 that I can find is: "Within the process of reorganization of the certificate class structure, the issuance of Class 4 certificates has been ceased..."
There is a dedicated CPD for EV certificates. The German version is available at:
http://www.trustcenter.de/media/CPD_TCTrustCenter_EV-de.pdf

The English version is currently being translated and will be published approx. last week of June.

The TC Universal III root is relevant for EV. The EV certificates are issued off the "TC TrustCenter Class 4 Extended Validation CA I" intermediate CA.

This relationship is also mentioned in the audit report (http://www.tuvit.de/certuvit/pdf/6711UE_s.pdf)
Thanks for the clarification. Please post the link to the English translation of the CPD for EV in this bug when it's available.
Attached file EV Certificate CPD (obsolete) —
Attached file EV Certificate CPD
Attachment #455641 - Attachment is obsolete: true
I will post a comment in this bug when I start the discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Attachment #415681 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from TC TrustCenter to add the “TC TrustCenter Universal CA III” root certificate.

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.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “TC TrustCenter Root Inclusion Request”

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

A representative of the CA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Information confirmed complete → EV - In Public Discussion
This request has been evaluated as per the Mozilla 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 from TC TrustCenter to add the SHA256 “TC TrustCenter Universal CA III” root certificate, enable all three trust bits, and enable EV.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by TC TrustCenter, 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]. TC TrustCenter appears to provide a service relevant to Mozilla users: It is a commercial company based in Germany, with customers in major regions of the world.

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 CPS and CPD, which are in English.

CPS: http://www.trustcenter.de/media/CPS-TCTrustCenter-en.pdf
CPD: http://www.trustcenter.de/media/CPD-TCTrustCenter-en.pdf
CPD for EV: https://bugzilla.mozilla.org/attachment.cgi?id=455642

Section 7 [Validation]. TC TrustCenter appears to meet the minimum requirements for subscriber verification, as follows:

* Email: TC TrustCenter’s CPS and CPD state that they confirm that the e-mail address stated in the certificate existed at the time of application and that the owner of the public key had access to this e-mail address. If an e-mail address is contained in the certificate, its correctness is verified by an access test. (CPS section 3.2.4, CPD sections 4.3 and 4.4)

* SSL: TC TrustCenter’s CPD states that for server certificates it is checked if the domain name in the certificate is registered to the organization applying for the certificate.  (CPD sections 4.3 and 4.4)

* Code: TC TrustCenter’s CPS and CPD describe reasonable measures to verify the identity and authorization of the certificate requester. (CPS section 3.2, CPD section 4.4)

* EV Policy OID: 1.2.276.0.44.1.1.1.4
** CPD for EV section 3.7 provides the details about how TC TrustCenter verifies that the Applicant is a registered holder of the domain name to be included in the EV Certificate, or has exclusive control of the domain name. The steps include contacting the registered domain holder using the information obtained from WHOIS or through the domain registrar. Section 3.6 of the CPD for EV describes the steps taken to verify the organization.

Section 13 [Certificate Hierarchy]. 
* This new root will co-exist with the “TC TrustCenter Universal CA I” root that is currently included in NSS. 
* This root will eventually have an internally-operated subordinate CA for each registration strength; “Class 1”, “Class 2”, “Class 3” and “Class 4 EV”. This root currently has one Class 4 EV subordinate CA, “TC TrustCenter Class 4 Extended Validation CA I”, which will only issue EV certificates. 
* TC TrustCenter has no current plans to issue external sub-CAs under this root. 

Other: 
*TC TrustCenter issues CRLs with NextUpdate 7 days for end-entity certs.
* OCSP is provided, with maximum expiration time of 7 days.

* TC TrustCenter’s external RAs are contractually bound to adhere to the procedures specified in TC TrustCenter’s CPS and other relevant policies. RAs are not allowed to use their own procedures and deviate from TC TrustCenter’s policies. According to the CPS:
** TC TrustCenter distinguishes between Local Registration Officers and External Registration Officers.
** The Local Registration Officers are limited regarding their tasks. They cannot vet organizations and domains. They can only perform personal vetting for a limited and previously named set of organizations. Local Registration Officers have been empowered by all affected organizations to perform that role.
** External Registration Officers are allowed to vet organizations and Domains. They have to undergo a special training on the procedures. 
** Both, Local Registration Officers and External Registration Officers are contractually bound to adhere to TC TrustCenter’s CP/CPS. TC TrustCenter performs random checks and they perform checks in case of abnormalities.

Section 8-10 [Audit]. 
TC TrustCenter is audited annually by TÜV-IT Germany (http://www.tuvit.de/) according to the ETSI TS 102042 criteria, and the ETSI certificates are posted on the TÜV-IT website: 
ETSI TS 102 042 V2.1.1 certificate: 
http://www.tuvit.de/certuvit/pdf/6707UE_s.pdf
ETSI TS 102 042 V2.1.1 policy EVCP certificate: 
http://www.tuvit.de/certuvit/pdf/6711UE_s.pdf

Based on this assessment I intend to approve this request to add the “TC TrustCenter Universal CA III” root certificate, enable all three trust bits, and enable EV.
To the representatives of TC TrustCenter: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #20, and on behalf of the Mozilla project I
approve this request from TC TrustCenter to include the following root certificate in Mozilla:

* TC TrustCenter Universal CA III (web sites, code signing, email), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.
Whiteboard: EV - In Public Discussion → EV - Approved - awaiting NSS and PSM
Depends on: 593063
Depends on: 593067
I have filed bug 593063 against NSS and bug 593067 against PSM for the actual
changes.
Whiteboard: EV - Approved - awaiting NSS and PSM → EV - In FF4Beta - awaiting PSM
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: EV - In FF4Beta - awaiting PSM → EV - In FF4Beta
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

Created:
Updated:
Size: