Closed Bug 392024 Opened 12 years ago Closed 11 years ago

add new TC TrustCenter root certificates

Categories

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

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Lindemann, Assigned: kwilson)

References

Details

(Whiteboard: Approved)

Attachments

(5 files)

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.class2-ii.trustcenter.de/
Actual Results:  
"unknown or untrusted CA"

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

1. Certificate Name: 					TC TrustCenter Class 1 CA
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. Details are described in http://www.trustcenter.de/cpd. This Root is only being used to issue certificate for Email Security and SSL-Client-Authentication

Version: 						v3
SHA1 Fingerprint:					72:0f:c1:5d:dc:27:d4:56:d0:98:fa:bf:3c:dd:78:d3:1e:f5:a8:da 
Modulus Length (a.k.a. "key length"):			RSA 1024 Bit
Valid From (YYYY-MM-DD):				09.03.1998 11:59:59 GMT 
Valid To (YYYY-MM-DD):					01.01.2011 11:59:59 GMT  
CRL HTTP URL:						http://www.trustcenter.de/crl/v2/tcclass1.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:						http://ocsp.tcclass1.trustcenter.de/
Class (domain-validated, identity/organisationally-validated or EV): domain-validated
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
URL of website using certificate chained to this root (if applying for SSL): - 


2. Certificate Name:					TC TrustCenter Class 2 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. Details are described in http://www.trustcenter.de/cpd. This Root is being used to issue all types of certificate, e.g. Email Security, SSL-Client-Authentication, SSL-Server, CodeSigning

Version:
SHA1 Fingerprint:					ae:50:83:ed:7c:f4:5c:bc:8f:61:c6:21:fe:68:5d:79:42:21:15:6e  
Modulus Length (a.k.a. "key length"):			RSA 2048 bit
Valid From (YYYY-MM-DD):				12.01.2006 14:38:43 GMT 
Valid To (YYYY-MM-DD):					31.12.2025 22:59:59 GMT  
CRL HTTP URL:						http://www.trustcenter.de/crl/v2/tc_class_2_ca_II.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:						http://ocsp.tcclass2-ii.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally-validated
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.class2-ii.trustcenter.de/

3. Certificate Name:					TC TrustCenter Class 3 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. Details are described in http://www.trustcenter.de/cpd. This Root is being used to issue all types of certificate, e.g. Email Security, SSL-Client-Authentication, SSL-Server, CodeSigning
Version:
SHA1 Fingerprint:					80:25:ef:f4:6e:70:c8:d4:72:24:65:84:fe:40:3b:8a:8d:6a:db:f5  
Modulus Length (a.k.a. "key length"):			RSA 2048 bit
Valid From (YYYY-MM-DD):				12.01.2006 14:41:57 GMT
Valid To (YYYY-MM-DD):					31.12.2025 22:59:59 GMT  
CRL HTTP URL:						http://www.trustcenter.de/crl/v2/tc_class_3_ca_II.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:						http://ocsp.tcclass3-ii.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally-validated
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.class3-ii.trustcenter.de/

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/

5. Certificate Name:					TC TrustCenter Universal I
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 is minimum requirement. Details are described in http://www.trustcenter.de/cpd. This Root is being used to issue all types of certificate, e.g. Email Security, SSL-Client-Authentication, SSL-Server, CodeSigning
Version:
SHA1 Fingerprint:					6b:2f:34:ad:89:58:be:62:fd:b0:6b:5c:ce:bb:9d:d9:4f:4e:39:f3  
Modulus Length (a.k.a. "key length"):			RSA 2048 bit
Valid From (YYYY-MM-DD):				22.03.2006 15:54:28 GMT 
Valid To (YYYY-MM-DD):					31.12.2025 22:59:59 GMT 
CRL HTTP URL:						http://www.trustcenter.de/crl/v2/tc_universal_root_I.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:						http://ocsp.tcuniversal-i.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): at least domain validated
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-i.trustcenter.de/

6. Certificate Name:					TC TrustCenter Universal 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 is minimum requirement. Details are described in http://www.trustcenter.de/cpd. This Root is being used to issue all types of certificate, e.g. Email Security, SSL-Client-Authentication, SSL-Server, CodeSigning
Version:
SHA1 Fingerprint:					8c:c4:30:7b:c6:07:55:e7:b2:2d:d9:f7:fe:a2:45:93:6c:7c:f2:88    
Modulus Length (a.k.a. "key length"):			RSA 4096 bit
Valid From (YYYY-MM-DD):				22.03.2006 15:58:34 GMT    
Valid To (YYYY-MM-DD):					31.12.2030 22:59:59 GMT
CRL HTTP URL:						http://www.trustcenter.de/crl/v2/tc_universal_root_II.crl
CRL issuing frequency for end-entity certificates: one week
OCSP URL:						http://ocsp.tcuniversal-ii.trustcenter.de
Class (domain-validated, identity/organisationally-validated or EV): at least domain validated
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-ii.trustcenter.de/
Mr Lindemann,

Thank for you for this information. Some questions:

- I note you have emailed me an audit document. However, we require that the auditor publicly state the audit results, perhaps by placing the document on their website. Is this already true, or can it be arranged?

- The audit document you have sent me appears to apply only to the "TC TrustCenter Class 2 CA", which does not exactly match the name of any of the certificates you have submitted. Do you have a similar document for your other certificates? Or does the audit apply to your entire operation? If so, how do you explain that part of the audit certificate?

- Please supply HTTP download URLs for all the certificates.

- Please confirm that all the certificates are X.509 version 3.

- Which of the two current CPSes at
http://www.trustcenter.de/en/about/repository.htm
apply to each root? Or does it depend on circumstances?

- One of your roots is only 1024 bit. NIST recommend that all such roots by phased out by the end of 2010, yet this root expires at the end of 2011. What is your current end-of-life plan with regard to this root?

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Hi Gerv,

thanks for your response. Here are the answers:
a) The audit report will be published. I'll send you the URL once i know it.

b) The Name "TC TrustCenter Class 2 CA" as mentioned in the audit report refers to the current "TrustCenter Class 2 CA" (see OU field) and the second generation Class 2 CA "TC TrustCenter Class 2 II". Since all the CAs are operated on the same platform (the operational environment (i.e. data center, network infrastructure, PKI platform, HSMs, vetting team, ...) is the same for all CAs) and the security of the CAs is the same the audit report covers the entire operation. The only difference of the CAs is the vetting. Vetting for Class 3 and Class 4 is even more strict then vetting for Class 2.
All other CAs provide the same level of security and thus also meet the ETSI requirements. 

c) Download-URLs of the (DER encoded) certificates are:
1. TC TrustCenter Class 1 CA: http://www.trustcenter.de/certservices/cacerts/tcclass1-2011.der
2. TC TrustCenter Class 2 II: http://www.trustcenter.de/media/class_2_ii.der
3. TC TrustCenter Class 3 II: http://www.trustcenter.de/media/class_3_ii.der
4. TC TrustCenter Class 4 II: http://www.trustcenter.de/media/class_4_ii.der
5. TC TrustCenter Universal I: http://www.trustcenter.de/media/Universal_CA-I.der
6. TC TrustCenter Universal II: http://www.trustcenter.de/media/Universal_CA-II.der


e) All root certificates are X.509 v3.

f) The CPS (http://www.trustcenter.de/media/cps-en_July-5-2007.pdf) applies to all roots.

g) The TC TrustCenter Class 1 CA expiring beginning of 2011 will be effectively replaced by TC Universal I. TC TrustCenter Class 2 II and TC TrustCenter Class 3 II will replace the TC TrustCenter Class 2 and TC TrustCenter Class 3 roots. We'll phase out the 1024 bit roots before end of 2010.

a) The URL for the ETSI report is: https://www.secure.trusted-site.de/certuvit/pdf/6706UE.pdf
Severity: normal → enhancement
Whiteboard: EV
"All other CAs provide the same level of security and thus also meet the ETSI
requirements."

I'm sure you assert this; but did the audit actually confirm it?

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/
(Note: it may be a few hours before this updates.)

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 at the top of the 
entry, please feel free to provide one. Note: these paragraphs are not 
supposed to be marketing statements :-)

Gerv

The ETSI audit was performed based on the CPS (http://www.trustcenter.de/media/cps-en_July-5-2007.pdf) which is the same for all CAs. The auditors checked that the PKI system actually matches the CPS.
If it helps we can provide you with a letter from the auditors that the only difference between the CAs is the registration procedure. Please let me know.

The URL of the ETSI reports (102 042 and 101 456) is: http://www.tuvit.de/XS/c.020400&zerttyp=18/r.020400/sprache.EN/SX/

The information provided on http://www.mozilla.org/projects/security/certs/pending/#TC%20TrustCenter is correct.
The URL of the ETSI reports (102 042 and 101 456) has changed and now is:
http://www.tuvit.de/41097.asp?zerttyp=18&sprache=EN
Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv
Assignee: gerv → hecker
Making EV root cert requests have uniform summaries.
Summary: Please add new TC TrustCenter root certificates → add new TC TrustCenter EV root certificates
Only the "TC Class 4 II" Root Certificate is an EV Root; the other Root certificates are "normal" root certificates. 
Should we split this "bug" to make it more clear and do not block the insertion of the non-EV root certificates by potential issues with the EV insertion?
According to 
http://www.mozilla.org/projects/security/certs/pending/#TC%20TrustCenter
the information in this request is "probably complete".  It is awaiting 
confirmation on some details.  (Sorry, I don't know more)
Whiteboard: EV → EV - PROBABLY complete
What exactly is missing here? This ticket is pending quite a long time now.
I'm assigning this bug to Kathleen Wilson, who will be gathering information related to the request.
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
Mr. Lindemann,

As Frank mentioned, I will be gathering information for requests that he assigns to me. I have a specific list of information that I will be gathering and verifying for each CA.

I have reviewed the information presented in this request, and I would greatly appreciate your help in answering the following questions.

A) For the TC TrustCenter Class 4 II CA, the EV guidelines have language in section 26(a) about the maximum time until OCSP responders are updated to reflect end-entity revocation. Would you please confirm compliance with this section, and provide the max time?

B) For the TC TrustCenter Class 4 II CA, please provide the EV Policy OID.

C) For each of the CA’s in this request, would you please provide: 1) List subordinate CA’s operated by your organization, 2) List of subordinate CAs operated by third parties, 3) List of any other root CAs that have issued cross-signing certificates for this root CA.

D) I have reviewed the CPS (http://www.trustcenter.de/media/cps-en_July-5-2007.pdf), and I can clearly see that it covers Class 1, Class 2, and Class 3.  However, I do not see mention of Class 4, Universal I, or Universal II.  Perhaps there is another document or an updated version of the CPS that discusses these new roots?

E) I apologize, but I have been unable to download the audit report from the TUVIT site. Perhaps the url needs to be updated? I would greatly appreciate any assistance in getting a publicly available url with the audit report that I can download.

Thanks,
Kathleen
Here are the answers.

Regarding A) 
The EV Guideline requires:
(1) For EV Certificates or Subordinate CA Certificates issued to entities
not
controlled by the entity that controls the Root CA:
(A) CRLs MUST be updated and reissued at least every seven days, and the
nextUpdate field value SHALL NOT be more ten days; or
(B) OCSP. If the CA provides revocation information via an Online
Certificate Status Protocol (OCSP) service, it MUST update that service at
least every four days. OCSP responses from this service MUST have a
maximum expiration time of ten days.

TC CPS states:
CRLs are issued at least once a day, but will in general be updated several
times a day, even if no changes have occurred since the last issuance. At a
minimum, a CRL entry identifying a revoked certificate remains on the CRL
until the end of the certificate’s validity period. A certificate is also
put on the CRL during its suspension period.

The certificate status can be checked on-line from the certificate
repository. Any changes committed to the repository are immediately
available to any subscriber and / or relying party.

==> the EV requirements are fulfilled.

Regarding B)
The policy OID is: 1.2.276.0.44.1.1.1.4

Regarding C)
The intermediate CAs are described here: http://www.trustcenter.de/en/infocenter/root_certificates.htm
Additionally we may issue intermediate CAs for customers. All intermediate CAs have to operate in compliance with our CPS. They either directly refer to our CPS or are at least as strict as our CPS.

Is that level of detail sufficient for you?
What exactly is the purpose of that list of subordinate CAs?


Regarding D) 
I'll send you the updated CPS by end of next week.

Regarding E)
please use the links:
- https://www.secure.trusted-site.de/certuvit/pdf/6706UE.pdf and
- https://www.secure.trusted-site.de/certuvit/pdf/6705UE.pdf
I just tried these links and they work.
Thank you for your quick response.

Regarding A) 
Thanks for the info, but I was really wondering if you have a service level agreement or something that specifies the maximum OCSP response time in case something does not work as expected. This is in regards to the EV Guidelines: “OCSP responses from this service must have a maximum expiration time of ten days.” 
Can you confirm that your operations requirements meet this?

Regarding B)
Thanks.

Regarding C)
Based on the info in
http://www.trustcenter.de/en/infocenter/root_certificates.htm

Please Confirm: TC TrustCenter Class 4 II does not have subordinate CA’s. There are no other root CAs that have issued cross-signing certificates for this root CA.

Question: Do your practices allow this EV CA to have sub-CAs either internally or third-party?
The concern is that a sub-CA may not be truly EV-certified.

Please Confirm: TC TrustCenter Class 2 II and TC TrustCenter Class 3 II have subordinate CAs:
2.6 TC Class 2 II SubCA IV (Intermediate Certificate) 
2.7 TC Class 3 II SubCA IV (Intermediate Certificate) 
These are internally-operated. The operation of these sub-CAs is addressed by the CPS. 

Question: Did the audit cover the operation of these sub-CAs?

Question: Are any of the CA’s listed in the “Other Certificates” list sub-CAs of the CAs in this request?
Installation of TC TrustCenter CA for Adobe I Certificate 
Installation of TC TrustCenter LRA CA Certificates 
Download of TC TrustCenter WTLS CA Certificates 
Download of TC TrustCenter European Bridge L1 CA Certificates 
Qualified Certificates 
BNetzA Root Certificates 

RE: “Additionally we may issue intermediate CAs for customers. All intermediate CAs have to operate in compliance with our CPS. They either directly refer to our CPS or are at least as strict as our CPS.”

Question: Are these third parties just acting as Registration Authorities, or do they actually have ownership/control of the sub_CA key pair and CA cert?

If the sub-CAs are truly controlled by the third-party, which of the CA’s in this request can be used for such sub-CA’s? Do you have contractual agreements that require them to follow the procedures that are at least as strict as in your CPS? What audit arrangements are in place regarding the subordinates? Do you have technical agreements such as name constraints and not allowing them to create their own subordinates?


Regarding D) 
Thanks.

Regarding E)
Again, I apologize for not being able to download using these links.  When I try to download these I get an error that the site’s cert expired on 4/27/08. Followed by the object not found error.

Thanks,
Kathleen
Hi Kathleen,

i appreciate the quick turn-around.

our answer regarding A)
The CPS states:
CRLs are issued at least once a day, but will in general be updated several
times a day, even if no changes have occurred since the last issuance. Each
CRL has a maximum validity period of one week.
If the CA provides revocation information via OCSP, that service is updated
at least once every day. OCSP responses have a maximum expiration time
identical to the validity of the associated CRL.

Hence, OCSP responses have a validity of at most seven days.

our answer regarding C)
> 
> Question: Do your practices allow this EV CA to have sub-CAs 
> either internally or third-party?
> The concern is that a sub-CA may not be truly EV-certified.
> 

TC TrustCenter’s Certification Authorities are organized in a hierarchical
structure, i.e. CAs may issue certificates to other certificate issuing
entities. Such a Subordinate CA (Sub-CA) must at a minimum fulfill the
requirements of the superior CA. This applies especially to the requirements
on identification and authentication: when registering applicants, Sub-CAs
are allowed to perform additional or more extensive checks than the superior
CA; they must not drop below the requirements of the respective superior CA.

> Please Confirm: TC TrustCenter Class 2 II and TC TrustCenter 
> Class 3 II have subordinate CAs:
> 2.6 TC Class 2 II SubCA IV (Intermediate Certificate)
> 2.7 TC Class 3 II SubCA IV (Intermediate Certificate) These 
> are internally-operated. The operation of these sub-CAs is 
> addressed by the CPS. 

Confirmed

> 
> Question: Did the audit cover the operation of these sub-CAs?

These Sub-CAs have been generated after the previous audit and hence could not have been directly covered by it.
The next audit is scheduled for August 2008.

> 
> Question: Are any of the CA’s listed in the “Other 
> Certificates” list sub-CAs of the CAs in this request?
> Installation of TC TrustCenter CA for Adobe I Certificate 
> Installation of TC TrustCenter LRA CA Certificates Download 
> of TC TrustCenter WTLS CA Certificates Download of TC 
> TrustCenter European Bridge L1 CA Certificates Qualified 
> Certificates BNetzA Root Certificates 

No.

> RE: “Additionally we may issue intermediate CAs for 
> customers. All intermediate CAs have to operate in compliance 
> with our CPS. They either directly refer to our CPS or are at 
> least as strict as our CPS.”
> 
> Question: Are these third parties just acting as Registration 
> Authorities, or do they actually have ownership/control of 
> the sub_CA key pair and CA cert?

Some of them actually have ownership/control of the sub_CA key pair and CA cert.
Is this an issue?

> 
> If the sub-CAs are truly controlled by the third-party, which 
> of the CA’s in this request can be used for such sub-CA’s? Do 
> you have contractual agreements that require them to follow 
> the procedures that are at least as strict as in your CPS?

Any of the CA's in this request could be used to sign such sub-CA's.
If TC TrustCenter issues a Sub-CA certificate to a third party then there
are contractual agreements in place requiring the third party to adhere to the
requirements of the applicable CPS.

> What audit arrangements are in place regarding the 
> subordinates? Do you have technical agreements such as name 
> constraints and not allowing them to create their own subordinates?

the entry "Path length" in the "Basic contstraints" extension (marked as critical) is set to 0. So they cannot use their own subordinates.


our answer regarding E)
Please use "tuvit" instead of "secure.trusted-site".
E.g. https://www.tuvit.de/certuvit/pdf/6706UE.pdf and http://www.tuvit.de/certuvit/pdf/6705UE.pdf work.
It seems that they recently changed the structure of their website.

Best regards,
  Rolf
Hi Rolf,

Thanks again for your quick and thorough response.

The reason I have asked all the questions about sub-CA’s is because part of the info I’m supposed to gather for these requests is described in:
http://wiki.mozilla.org/CA:Problematic_Practices
There is a section which says:
“Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities.”

My job as info-gatherer is to make sure the sub-CA’s have been listed and to ensure it has been specified how the sub-CA’s are controlled in regards to contractual agreements and audits.

I believe that there is even greater concern about sub-CA’s for EV roots, but my job is to make sure the info is available for review, and others will make the determination.


In regards to updating the CPS and getting the new audit in August for Class 4, Universal I, and Universal II… My understanding is that there needs to be a completed WebTrust audit for EV roots.


Thank you for the updated links to the audit documents for the Class 1, 2, and 3.  I’ll update the pending list to reflect.

Thanks,
Kathleen
Hi Kathleen,

we agree that EV roots have to be treated separately.

But regarding "TC Universal I" and "TC Universal II" i think you should already have that information, since all the CAs are
operated on the same platform (the operational environment (i.e. data center,
network infrastructure, PKI platform, HSMs, vetting team, ...) is the same for
all CAs) and the security of the CAs is the same the audit report covers the
entire operation. The only difference of the CAs is the vetting. Vetting for
Class 3 and Class 4 is even more strict then vetting for Class 2.
All other CAs provide the same level of security and thus also meet the ETSI
requirements. 
So even though we recently issued additional Sub-CAs chaining to the TC Universal root all security measures audited by TÜV-IT still apply to the roots.

Keeping all this in mind would it then make sense to split our request for root insertion into two parts (one for non-EV roots and one for the EV-root)?
Just to avoid potential delay on the non-EV root insertion?

Best regards,
  Rolf
Yes, I think it would be best to separate the EV Class 4 into its own request.

Please note that a CA will not be approved for EV until its WebTrust EV audit is completed and published. Is this audit also scheduled for August?

Thanks,
Kathleen
Hi Kathleen,

then i will remove the request to insert "TC Class 4 II" from this ticket and create a new one for it. 
Can you please adjust all other settings (if required)?

Best regards,
  Rolf
Hi Kathleen,

i filed a new bug (436467) which now only covers the EV root certificate (exclusively). 
This bug does now only covers non-EV root certificates:
1. TC TrustCenter Class 1 CA
2. TC TrustCenter Class 2 II
3. TC TrustCenter Class 3 II
4. TC TrustCenter Universal I
5. TC TrustCenter Universal II

Best regards,
  Rolf
Updating the bug summary to reflect that the EV root has been moved into a separate bug.
Summary: add new TC TrustCenter EV root certificates → add new TC TrustCenter root certificates
The information for the Class 1, Class 2, and Class 3 CAs is complete.

The information for the Universal I and Universal II CAs is almost complete. Pending CPS update to include them, and pending audit.

The attached document summarizes the information for these CAs.

Whiteboard: EV - PROBABLY complete → PROBABLY complete
Reassigning to Frank so that the Class 1, Class 2, and Class 3 CAs can enter the discussion phase.
Assignee: kathleen95014 → hecker
Status: ASSIGNED → NEW
Does this mean that Class 1, Class 2 and Class 3 CAs will be included in the FireFox 3.0 release?
No. At this point no further CAs will be included in the initial Firefox 3.0 release (scheduled for next Tuesday, June 17). Our goal is instead to consider new root CAs for inclusion in future Firefox 3 security updates, beginning with the Firefox 3.0.1 release later this year.

What Kathleen meant is that we now have enough information to start the official public comment period regarding including the TC TrustCenter root CAs referenced in this bug. I now have to determine where this request is located in the overall queue of similar requests from other CAs.
Status: NEW → ASSIGNED
According to https://wiki.mozilla.org/CA:Schedule this request is in the queue to begin public discussion the first week of March. Since I did the information gathering six months ago, I'll need to gather updated information where necessary before starting the public discussion.

Please:
1) Provide links to the updated CP/CPS's that include the Universal I and Universal II CAs.
2) Provide links to the 2008 audit statements for all of these roots.
3) Review the updated potentially problematic practices at https://wiki.mozilla.org/CA:Problematic_Practices and provide details for the ones that apply.
Assignee: hecker → kathleen95014
Regarding 1)
The CP/CPS can be found at
CPS: http://www.trustcenter.de/media/CPS-TCTrustCenter-080904-en.pdf
CP:  http://www.trustcenter.de/media/CPD-TCTrustCenter-061023-en.pdf

The CPS now explicitly mentiones the root certificates in section 1.3.1.

Regarding 2)
The new ETSI certificate is attached to this case (id=361978).
Here our statement regarding "Problematic CA Practices"

1) Long-lived DV certificates

TC TrustCenter currently does not issue certificates based solely on a domain validation.
TC TrustCenter not only verifies that the domain name in the CN attribute is registered to the organization named in the O field of the certificate. TC TrustCenter always performs additional vetting, e.g. verification of the domain holder’s registration with official (governmental) authorities and verifying the identity and authorization of the requesting person to apply for a certificate on behalf of the organization under consideration (see CPD). 


2) Wildcard DV SSL certificates

As mentioned above TC TrustCenter currently does not issue SSL certificates relying only on domain validation. TC TrustCenter always performs additional vetting for all attributes in the certificate.


3) Delegation of Domain / Email validation to third parties

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.


4) Issuing end entity certificates directly from roots

TC TrustCenter issues end entity certificates to the public from subordinate CAs only. 


5) Allowing external entities to operate unconstrained subordinate CAs

If TC TrustCenter issues a CA certificate to an external CA, this CA must present a CPS and other documentation fulfilling TC TrustCenter’s requirements. Furthermore this CA must sign a contractual agreement to adhere to all requirements specified in their CPS.
In addition, TC TrustCenter reserves the right to perform audits at this CA’s site or to claim a third party audit equivalent to the Root CA’s audit.
CA certificate to an external CA contain the entry "Path length" entry in the "Basic contstraints" extension (marked as critical) set to 0. So they cannot generate their own subordinates.


6) Distributing generated private keys in PKCS#12 files 

In general, subscribers must generate their own key pairs.
In cases where this is not possible or not practical, TC TrustCenter prefers to generate subscriber keys on smartcards or other cryptographic tokens. These tokens are then delivered to the subscriber.
If the use of cryptographic tokens is not possible, TC TrustCenter may generate subscriber’s key pairs.
For encryption keys subscribers may enter into a contractual agreement for key escrow or key recovery. TC TrustCenter will then store subscriber’s key pair in encrypted form in such a way that decryption is only possible under dual control.
TC TrustCenter will not store subscriber’s private keys without subscribers consent and not without having informed the subscriber about the possible risks.
PKCS#12 files are never transmitted through unsecured channels. In most cases TC TrustCenter informs the subscriber about a download location where the subscriber can download the key pair via encrypted channel (e.g. SSL). 


7) Certificates referencing hostnames or private IP addresses 

TC TrustCenter may issue certificates containing domain names or IP addresses not reachable from the public internet. Such certificates always contain the name of the organization (in the O attribute). Even if two organizations use the same internal hostnames and/or internal IP addresses the certificates can easily be distinguished because the O attribute differs. 
TC TrustCenter verifies that the IP address is either (a) non-routable private (e.g. 192.168.x.y) or (b) is registered to the requestor.


8) OCSP Responses signed by a certificate under a different root 

TC TrustCenter’s OCSP responders always sign their responses with an OCSP Signing Certificate that is issued by the CA in question.


9) CRL with critical CIDP Extension 

TC TrustCenter makes full CRLs available for download. TC TrustCenter currently does not use CIDP extensions.
Hi Kathleen,

i think we now should have addressed all topics now.
Please let me know if there is anything i can do to support this process.

Best regards,
  Rolf
Hi Rolf,

Thank you for your thorough response. After reviewing the updated information, I have the following questions.

Would you please provide a current class hierarchy diagram for these roots and a description of the subordinate CAs and end-entity certificates that are issued to these roots?

The serial numbers of the CAs listed in the new audit certificate do not match these roots:
http://www.trustcenter.de/media/class_2_ii.der
http://www.trustcenter.de/media/class_3_ii.der
Were these roots audited?

Is the new audit certificate also available on the TUVIT website? If so, can you provide that url?

Is there a new audit for TC TrustCenter Class 1?  Are you still requesting inclusion of the Class 1 root in NSS?

Is there an audit for TC TrustCenter Universal I and Universal II?
I could not find very much information about Universal I and Universal II in the CPS and none in the CPD. I could not gather what the sorts of certificates would be issued through these Universal roots, and what the verification/validation procedures are for certificates in their hierarchy. Unless this information is available, my recommendation is to not include the Universal roots in this current request.

Is it still the case that these roots have not issued subordinate CAs that are operated by third parties?

Thanks,
Kathleen
Attached file TC CA Hierarchy
Hi Kathleen,

1) Root Hierarchy
The class hierarchy is now attached to this case (id=362215).
TC Class 2 CA and TC Class 3 CA are already included in NSS.

Certificates chained to TC Class 1 CA are used for email security or SSL client authentication (not for SSL server certificates!).

TC Universal CA I has been introduced to reduce the number of root certificates in the trusted root stores in midterm.
“Class 1”, “Class 2”, “Class 3” and “Class 4” represent the registration strength. Over time we’ll expect to get more “TC Class x” Sub-CA certificates issued by the “TC Universal I” root.

2) Roots covered by the Audit
The roots submitted for inclusion have been audited.
The serial numbers of the CAs listed in the new ETSI certificate are referring to the L1 Sub-CA certificates audited by TÜV-IT. Given the fact that we do not issue end entity certificate off the root (but off Sub-CA only) and it doesn’t make much sense to audit the Sub-CA issuance by a root TÜV-IT decided to audit the end entity certificate issuance off a representative and active Sub-CAs chained to the roots covered by this audit. The covered roots are identified by their CN (see second line: “TC TrustCenter Class 2 CA II”, “TC TrustCenter Class 3 CA II“, “TC TrustCenter Universal CA I”).
Additionally the ETSI certificate also references the CPS version (i.e. 1.9.1).
The CPS v1.9.1 lists the root certificates covered by that CPS with serial numbers and some more details. Please compare the root certificates submitted for inclusion with these.

3) The ETSI certificate can be downloaded from the TÜV-IT website:
	http://www.tuvit.de/english/47347.asp
or
http://www.tuvit.de/certuvit/pdf/6707UE_s.pdf

4) TC Class 1 inclusion
The TC Class 1 root is covered by the CPS (see section 1.3.1). Please also include this root certificate. Lots of customers are using certificates chained to the TC Class 1 root for secure email with Thunderbird. Currently it’s a burden to manually import the root.
We are not issuing SSL server certificates off that root.

5) “TC Universal CA I” and “TC Universal CA II” inclusion
“TC Universal CA I” has been audited, see item 2. 
“TC Universal CA II” is not yet operational. The purpose is similar to “TC Universal CA II”.

6) Subordinate CAs operated by third parties.
We did not issue any subordinate CAs operated by third parties off the “TC Class 2 CA II”, “TC Class 3 CA II”, “TC Universal CA I” and “TC Universal CA II” roots.


Best regards,
  Rolf
Attached is the completed Information Gathering document.

I have also updated the entry on the pending list at
http://www.mozilla.org/projects/security/certs/pending/#TC%20TrustCenter

Please review both the document and the entry on the pending list for accuracy and completeness, and let me know if any changes are needed.
Hi Kathleen,

Please remove "TC Universal CA II" from this request.
We reviewed the document and the entry of the pending list - they are both ok.

Best regards,
  Rolf
Re comment #32:

For item #1, the issue is not about how you validate ownership of a domain but the lifetime of the site certificate.  Please respond to the lifetime issue.  

For item #3, how do you verify that external RAs are adhering to your CPS?  Yes, you have contracts with them.  However, how do you assure yourself that the provisions in those contracts are actually followed?  

For item #5, have you actually audited any external CA?  Have you audited all external CAs?  How often?
David, concerning item #5 I think it's not relevant how a CA audits itself (or sub CAs external to their infrastructure). The Problematic Practices addresses that very clearly:

"Some CAs authorize external entities to operate their own CAs as subordinate CAs under the original CA's root. This raises concerns relating to whether or not such external entities are audited in a manner equivalent to the root CA, as well as what legal and technical arrangements constrain the external entities."

CAs can't provide third party attestation about itself.
Response to Comment #39

1. Please respond to the lifetime issue.
We limit the maximum lifetime of our SSL server certificates to 3 years. We use organizational vetting. We think that a maximum validity period of 3 years is a good balance between security and usability. Please note that in certain environments (especially in large organizations) changing an SSL server certificate requires a huge overhead and good planning.

2. How do you verify that external RAs are adhering to your 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

Our response regarding item#5 will follow.
Here is our response to item#5

We have a right to audit any subordinate that is signed by our root. This is part of the legal agreement that is entered between our company and the organization we contract with. In each case, we review the CPS of the subordinate and have the right to examine data at any time. In addition, before we enter into an agreement with a subordinate, they have to pass certain "tests" including net worth, insurance, type of CA software used, type of HSM used, and CPS compliance to insure us of their reputation and security practices. We do not sign subordinates for public SSL provider use. 
The root can only be used by Enterprises that pass our tests and plan to issue for internal, corporate purposes, typically S/MIME and authentication. 
To date, we have not encountered any problems with our subordinates.
You state:  "We have a right to audit any subordinate that is signed by our root."  

My question is:  Have you ever actually done such an audit or engaged a third-party audit?  If so, how many and how recently?
Our internal policy team has audited our client's policies and procedures
by reviewing the client's CPS. We have a very small number of root signing
clients and have not performed any third party audits to date
I am now opening the first public discussion period for this request from TC TrustCenter to add four root certificates to Mozilla: TC TrustCenter Class 1 CA, TC TrustCenter Class 2 CA II, TC TrustCenter Class 3 CA II, TC TrustCenter Universal CA I.

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

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-tech-crypto

Please actively review, respond, and contribute to the discussion.
Whiteboard: PROBABLY complete → In Public Discussion
There was the question what the relationship of this root insertion request to our Class 0 certificate is:

TC Class 0 certificates are used for testing purposes only.
TC TrustCenter intentionally did not ask for insertion of the "TC Class 0" root certificate.
The "TC Universal" roots have not been used and will not be used to issue Class 0 sub CA certificates.

For this reason we think that TC Class 0 certificates are not related to this root insertion request.
It is planned to phase out the "TC Class 2 CA" and "TC Class 3 CA" 1024 bit root certificates - which are already been included in Mozilla - before end of 2010.

There is not yet a schedule for phasing out the "TC Class 2 CA II" and "TC Class 3 CA II" root certificates. 
We'll continue to use them for the next years.
The "TC Class 1 CA" root certificate will be phased out until end of 2010.
There are a large number of certificates chained to that root which are
being used for secure email.
So I think there is value for Thunderbird to have that root pre-installed.
>The comment from https://bugzilla.mozilla.org/show_bug.cgi?id=392024#c42 
>and further in comment 44 suggests that there *are* external sub 
>ordinate CA certificates. Do we know how many and if they were included 
>in the audits? Also will they be part of the audits or are only the 
>controls of the CA audited?
>I'm not sure if there are explicit provisions in the CPS concerning the 
>requirements to external entities having their own (sub) CA at their 
>premises and their audit requirements (beyond internal controls of the 
>CA). Can we get some more information on that?


There are a small number of external CAs that have been signed by our root.
They are not part of a formal audit but our Director of Security does audit and review their CPS'. 
There are no requirements for the external entities to undergo third party audits unless we decide that it is necessary. We have the right to impose this requirement in our contract with the external entities.
Here our statement regarding the SubordinateCA checklist requirements:

There are only two subordinate CAs issued by the root certificates related to this request.
Both Sub-CAs are operated by a third party for internal use only.

Regarding Sub-CA 1, which is chained to “TC Class 2 CA II”

Because the CA is for internal use only, the company operating the subordinate CA does not make the applicable CP/CPS publicly available.

According to Mozilla's SubordinateCA checklist (https://wiki.mozilla.org/CA:SubordinateCA_checklist) we have to provide and make publicly available the following information when our root signs subordinate CAs for enterprises/companies who operate the sub-CA for their own use:

1. General description of the sub-CAs operated by third parties.
--> This sub-CA 1 is used to issue certificate to company internal devices. All relying parties are company internal.

2. The CP/CPS that the sub-CAs are required to follow.
--> The sub-CA 2 is required to follow the TC TrustCenter CPD and CPS.

3. Requirements (technical and contractual) for sub-CAs in regards to whether or not sub-CAs are constrained to issue certificates only within certain domains, and whether or not sub-CAs can create their own subordinates.

--> This is covered by TC TrustCenter's CPD and CPS.
In addition, third party sub-CA 1 cannot create its own subordinates due to path length constraint in the sub-CA certificate.
Furthermore, all certificates issued by the CA in question are company internal device certificates; see below.

4. Requirements (typically in the CP or CPS) for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy.

--> This is covered by TC TrustCenter's CPD and CPS.


	* domain ownership/control

--> Certificates are issued only company internal and all relying parties are only company internal, so domain ownership/control needs not to be verified.


	* email address ownership/control

--> Certificates are issued to company internal devices and all relying parties are only company internal.


	* digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate

--> There is no signing of code objects.


5. Description of audit requirements for sub-CAs (typically in the CP or CPS)
          * Whether or not the root CA audit includes the sub-CAs.
          * Who can perform the audits for sub-CAs.
          * Frequency of the audits for sub-CAs. 

These requirements apply to the Root and are covered by TC TrustCenter's
CPS.


Regarding Sub-CA 2, which is chained to „TC Class 1 CA“.

1. General description of the sub-CAs operated by third parties.
--> This Sub-CA 2 is used to issue certificates to company internal email users. The certificates may only be used to secure the internal email communication.

2. The CP/CPS that the sub-CAs are required to follow.
--> The sub-CA 2 is required to follow the TC TrustCenter CPD.

3. Requirements (technical and contractual) for sub-CAs in regards to whether or not sub-CAs are constrained to issue certificates only within certain domains, and whether or not sub-CAs can create their own subordinates.

--> The sub-CA 2 cannot create its own subordinates due to path length constraint in the sub-CA certificate.
Furthermore, all certificates issued by the sub CA 2 in question are for company internal email users; see below.

4. Requirements (typically in the CP or CPS) for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificates chaining up to the root, as per section 7 of our Mozilla CA certificate policy.

--> This is covered by TC TrustCenter's CPD and CPS.


	* domain ownership/control

--> Certificates are for secure email purpose only, not for SSL servers.


	* email address ownership/control

--> Certificates are issued to company internal email users for company internal use.


	* digitally signing code objects -- entity submitting the certificate signing request is the same entity referenced in the certificate

--> There is no signing of code objects.


5. Description of audit requirements for sub-CAs (typically in the CP or CPS)
          * Whether or not the root CA audit includes the sub-CAs.
          * Who can perform the audits for sub-CAs.
          * Frequency of the audits for sub-CAs. 

These requirements apply to the Root and are covered by TC TrustCenter's
CPS.
The open questions about externally operated sub-CAs are (Hope I got all):
a) Can you explain into more depth how exactly the relying parties remain company internal?
b) Does this apply to all sub CAs which potentially may appear in the future?
c) How are the CA certificates protected?
d) Can this CA potentially issue to any other entity beyond the company internal usage?
e) How do you make reasonably sure that the sub-CAs follow the TC TrustCenter CPD and CPS?
f) Do the sub-CAs have to follow the CPD and CPS in regards to verification of domain and email address ownership/control? Please explain how this is controlled.
g) What are the audit requirements for the sub-CAs?

Here is our response:
Regarding a)
The devices are operated company internal. The device certificates are not used to protect external access to these devices. The device certificates are not used to access external resources.

Regarding b)
No, this does not necessarily apply to all sub CAs which might appear in the future. In the future we might also get customers which want to use such certificates externally.
We’ll add the requirement to publish the applicable CP/CPS in our root signing contract.

Regarding c)
The CA certificate protection is done according to the Web Trust / ETSI requirements. In particular this customer uses a FIPS 140-2 Level 4 HSM.

Regarding d)
Technically this is possible. But their policy and our contract forbid this.

Regarding e)
Our internal policy team has audited our client's policies and procedures by reviewing the client's CPS.
As part of this audit we had intense face to face discussions with our client.

Regarding f)
This particular client is not allowed to issue SSL server certificates, so verifying the domain play a completely different role here.
The certificates are device certificates and the device name and the email address belong to a company internal domain.
So the ownership is guaranteed.

Regarding g)
Our current requirements include an in-depth CP and CPS review and intense discussions of the procedures with our customers.
There are no requirements for the external entities to undergo third party audits unless we decide that it is necessary. We have the right to impose this requirement already defined in our contract with the external entities.
The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA 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 TC TrustCenter’s request to add four root CA certificates to the Mozilla root store:
* The recommendation is to not include the TC TrustCenter Class 1 CA root, which will be phased out before the end of 2010.
* The following information pertains to the other three roots: TC TrustCenter Class 2 CA II, TC TrustCenter Class 3 CA II, and TC TrustCenter Universal CA I.
* The request is to enable all three trust bits for these three roots.

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.

The certificate policies for TC TrustCenter are published on their website and listed in the entry on the pending applications list. Of primary interest are the Certification Practice Statement (CPS) and the Certificate Policy Definitions (CPD). Both of these documents have been provided in English.

http://www.trustcenter.de/media/CPS-TCTrustCenter-080904-en.pdf
http://www.trustcenter.de/media/CPD-TCTrustCenter-061023-en.pdf

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. 

* 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. A domain registration may be checked in advance. When the certificate is issued the domain check must not be more than twelve months old.

* Code: TC TrustCenter’s CPS and CPD describe reasonable measures to verify the identity and authorization of the certificate requester.

Section 8-10 [Audit]. Section 8-10 [Audit].  These roots have been audited by TÜV-IT, a German inspection agency focused on assessing, testing and certifying IT products, systems and processes. The most recent ETSI 102 042 certificate was issued on 2009-02-11 and is posted on the TÜV-IT website.

Section 13 [Certificate Hierarchy].  
* The TC TrustCenter Class 2 CA II root has two internally-operated subordinate CAs which issue certificates for SSL, email, and code signing.  
* TC TrustCenter Class 2 CA II root also has an externally-operated subordinate CA which is used to issue device certificates and email certificates for internal use only. The device name and the email address belong to a company internal domain, so the ownership is guaranteed.
* The TC TrustCenter Class 3 CA II root has one internally-operated subordinate CA which issues certificates for SSL, email, and code signing.   
* The TC TrustCenter Universal CA I root has been introduced to reduce the number of root certificates in the trusted root stores. This root will have internally-operated subordinate CAs for each registration strength: “Class 1”, “Class 2”, “Class 3” and “Class 4”. This root currently has one Class 3 subordinate CA, and over time this root will have more “TC Class x” subordinate CA certificates. 

Other: 
* The CRLs generated by TC TrustCenter are issued at least once a day, but they may be updated several times a day, even if no changes have occurred since the last issuance. 
* OCSP is also provided.

Potentially problematic practices: 
* 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.
* There is an externally-operated subordinate CA chaining to the TC TrustCenter Class 2 CA II root, which is used to issue device certificates and email certificates for internal use only. The device name and the email address belong to a company internal domain, so the ownership is guaranteed.

It is requested that TC TrustCenter do the following two action items before signing future externally-operated subordinate CAs:
1) Add statements in the TC TrustCenter CP/CPS and in the relevant sub-CA CP/CPS that require that the sub-CA CP/CPS be published when the sub-CA is allowed to issue certificates outside of their company/organization.
2) Audit the externally-operated sub-CAs against the same criteria as the TC TrustCenter CAs annually. Consider including the externally-operated sub-CAs in the annual audit that a third-party performs against the TC TrustCenter CAs.

Based on this assessment I recommend that Mozilla approve the request to add the following three root certificates to NSS, and enable all three trust bits: TC TrustCenter Class 2 CA II, TC TrustCenter Class 3 CA II, and TC TrustCenter Universal CA I.
To Kathleen: Thank you for your work on this request.

To Mr. Lindemann and other representatives of TC TrustCenter: Thank you for your cooperation and your patience.

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

I have reviewed the summary and recommendation in comment #52, and on behalf of the Mozilla project I approve this request from TC TrustCenter to add the following root certificates to NSS, with trust bits set as indicated:

* TC TrustCenter Class 2 CA II (email, SSL, code signing)
* TC TrustCenter Class 3 CA II (email, SSL, code signing)
* TC TrustCenter Universal CA I (email, SSL, code signing)

Kathleen, could you please do the following:

1. File the necessary bug against NSS.
2. Mark this bug as dependent on the NSS bug.
4. When that bug is RESOLVED FIXED, change the status of this bug to RESOLVED
FIXED as well.

Thanks in advance!
Whiteboard: In Public Discussion → Approved
Depends on: 486759
I have filed bug 486759 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.