The default bug view has changed. See this FAQ.

Add Deutsche Telekom CA cert for T-system Trust Center

RESOLVED FIXED

Status

mozilla.org
CA Certificates
P2
enhancement
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: Lothar Eickholt, Assigned: Kathleen Wilson)

Tracking

Details

(Whiteboard: Approved)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

Please so all required Informations in the E-Mail we sent to Mr Gervase Markham [gerv@mozilla.org]

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

10 years ago
Request for root embedding into mozilla firefox 3.0 and other Mozilla related software products. 
(Reporter)

Comment 2

10 years ago
URL for T-Systems service internet sites is http://pki.telesec.de/service/certificates/index.html
Mr Eickholt,

Please place the necessary information in this bug, in the following order of preference for method:

- URLs (for certificates, audit documents, CPs, CPSes etc.)
- Plain text comments (for the form I sent you, short covering notes etc.)
- As individual attachments (not ZIP files)

Thanks,

Gerv
Mr. Eickholt: 
Which cert, or certs, exactly, are you requesting be added to mozilla's list?

I visited an English translation of the web page cited above in comment 2.
<http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=de_en&url=http%3A%2F%2Fpki.telesec.de%2Fservice%2Fcertificates%2Findex.html>

It says:
> T-system trust center operates the PKI of the German Telekom with the root 
> certificates "Deutsche Telekom Root CA 1" and "Deutsche Telekom Root CA 2".
It shows information about those two roor CA certs, and it also shows two 
subordinate CA certs issued to "T-TeleSec trust center".

Are you requesting the inclusion of the "Deutsche Telekom Root CA" certs?
Or the "T-TeleSec trust center" cert? or something else?
Summary: Root embedding in Mozilla Firefox 3.0 → Add CA cert for T-system Trust Center
(Reporter)

Comment 5

10 years ago
We are requesting for the inclusion of "Deutsche Telekom Root CA 2" in the important first step. The next steps would be to request for inclusion of the two new roots "T-TeleSec GlobalRoot Class 2" and "T-TeleSec GlobalRoot Class 3" planned for new service later on in 2007.
Kind regards.
This bug is waiting for T-System to provide the necessary information, as requested in comment #3.

Gerv
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

10 years ago
URL for CPS is http://pki.telesec.de/service/DT_ROOT_CA_2/cps.pdf
URL for certificate is http://wwwca.telesec.de/cgi-bin/caservice/Common/InstallRoot/DT-Root-CA-2.cer

"Deutsche Telekom Root CA 2" is inside Windows certificate store
by default (and therefore inside MSIE) - it must be possible to have 
"Deutsche Telekom Root CA 2" inside Mozilla products, please.

<michael
Michael: This bug is still waiting for T-System to provide the necessary information, as requested in comment #3.

Our store policy is not to just "include everyone Microsoft includes". If it were, my life would be a whole lot more simple, but there are downsides as well.

Gerv

Updated

10 years ago
OS: Other → All
Priority: -- → P2
Hardware: Other → All
The bug filer has not responded in the past month; resolving INCOMPLETE.

Gerv
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 10

10 years ago
Hello Gerv,

we would like ro continue this bug report with a full qualified request for a root embedding:

T-Systems Enterprise Services GmbH  hereby requests Root embedding in Mozilla related sofware Products (especially Firefox and Thunderbird in current versions) for the following root certificate of Deutsche Telekom AG:

"Deutsche Telekom Root CA 2"

Certificate: http://wwwca.telesec.de/cgi-bin/caservice/Common/InstallRoot/DT-Root-CA-2.cer
CP: http://pki.telesec.de/service/DT_ROOT_CA_2/T-Systems-Root-CP-deutsch-v11.pdf
CPS: http://pki.telesec.de/service/DT_ROOT_CA_2/cps.pdf 
(T-Systems is addressing the German speaking market. Thus CP and CPS are written in German)

The CA issues certs for Sub Cas that issue certificates for SSL enabled servers, signed and encrypted emails and documents and digitally signed executable code

More information can be found at the following website: http://pki.telesec.de/service/certificates/index.html

T-Systems is a 100% subsidiary of Deutsche Telekom AG and acts on behalf of DTAG. "T-Telesec" is a registered brand of DTAG.
The Trustcenter of Deutsche Telekom AG owns a certificate of compliance according to ETSI TS 101 456:2005 (see http://pki.telesec.de/service/documents/ETSI_101456_Certificate_of_Compliance.pdf)

Besides that the Trustcenter is currently undergoing a certification according to AICPA/CICA WebTrust Program for Certification Authorities, 

Find below addititional informations as requested:

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

CA Name:		Deutsche Telekom Root CA 2
Website:  		http://pki.telesec.de/service/certificates/index.html
One Paragraph Summary of CA, including the following: 
  - General nature (e.g., commercial, government, academic/research, nonprofit) 	commercial
  - Primary geographical area(s) served	Germany 
  - Number and type of subordinate Cas 	4 CA's (MailPass Advanced, Open Limit, Signet, DFN)
Audit Type (WebTrust, ETSI etc.):		ETSI 101456
Auditor:							Karl-Werner Schröder, Dep. Head of Certification Body
Auditor Website:					http://www.t-systems-zert.com/
Audit Document URL(s):				http://pki.telesec.de/service/documents/ETSI_101456_Certificate_of_Compliance.pdf

Certificate Details
-------------------
Certificate Name:					see above
Summary Paragraph, including the following:
  - End entity certificate issuance policy,
    i.e. what you plan to do with the root	no end entity certificates issued from the Root CA
Certificate HTTP URL (on CA website):		see above
Version:							V3
SHA1 Fingerprint:					85 a4 08 c0 9c 19 3e 5d 51 58 7d cd d6 13 30 fd 8c de 37 bf
Modulus Length (a.k.a. "key length"):	RSA(2048 Bits)
							99 32 0e 08 48 56 5b 6a fb da e1 58 58 01 49 5f 72 41 3c 15 06 01 8e 5d ad aa b8 93 b4 cd 9e eb a7 e8 6a 2d 52 34 db 3a ef 5c 75 51 da db f3 31 f9 ee 71 98 32 c4 54 15 44 0c f9 9b 55 ed ad df 18 08 a0 a3 86 8a 49 ee 53 05 8f 19 4c d5 de 58 79 9b d2 6a 1c 42 ab c5 d5 a7 cf 68 0f 96 e4 e1 61 98 76 61 c8 91 7c d6 3e 00 e2 91 50 87 e1 9d 0a e6 ad 97 d2 1d c6 3a 7d cb bc da 03 34 d5 8e 5b 01 f5 6a 07 b7 16 b6 6e 4a 7f 02 03 01 00 01
Valid From (YYYY-MM-DD):				(1999-07-09) 
Valid To (YYYY-MM-DD):				(2019-07-10)
CRL HTTP URL:						ARL http://pki.telesec.de/service/certificates/index.html
OCSP URL:						no OCSP 
Class (domain-validated, identity/organisationally-validated or EV):	domain-validated, identity/organisationally-validated
Certificate Policy URL:				http://pki.telesec.de/service/certificates/index.html
CPS URL:							http://pki.telesec.de/service/certificates/index.html
Requested Trust Indicators (email and/or SSL and/or code): Identity Card for Signet CA, Commercial Registry for MailPass Advanced, Identity Card for 								OpenLinmit, verification against companies registry for DFN
URL of website using certificate chained to this root (if applying for SSL): 


Kind Regards 

T-Systems Enterprise Services GmbH
CSS PS&S, Security Solutions 
Wolfgang Pietrus 
Senior IT-Architekt 
Pallaswiesenstr. 182, D-64293 Darmstadt 
+49 6151 818-6113 (Tel) 
+49 6151 818-652 (Fax) 
E-mail: Wolfgang.Pietrus@t-systems.com 
http://www.t-systems.com 

T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert Henn,
Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*,
Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
(Reporter)

Comment 11

10 years ago
Hello Gerv,

we have some questions about this request?

1. we would like to request a preliminary determination according to chapter 12 of Mozilla CA Certificate Policy. It is crucial for us to know, whether you will accept the certification of the "competent" party or not.

2. Can you give us feedback about your next internal stages to a final decision? Can we support this process?

3. If we finally succeed with our request: How will the certificate be published in the Mozilla software products?

4. We can imagine that the processing of CA requests is not your top priority, but we would appreciate some information about typical timeframes for this process, so that we can adjust some of our projects related to that issue.

Best Regards 

T-Systems Enterprise Services GmbH
CSS PS&S, Security Solutions 
Wolfgang Pietrus 
Senior IT-Architekt 
Pallaswiesenstr. 182, D-64293 Darmstadt 
+49 6151 818-6113 (Tel) 
+49 6151 818-652 (Fax) 
E-mail: Wolfgang.Pietrus@t-systems.com 
http://www.t-systems.com 

T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert Henn,
Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*,
Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG



Thank you for all that information. Some is still missing:

- Please provide an HTTP URL to the CRL for your root certificate.

- Please also let me know with what frequency you issue CRLs which list revoked end entity certificates.

- Can I confirm that you are applying for all of email, SSL and code-signing capabilities? And that your CP and CPS cover the issuance process for all three types?

> we have some questions about this request?
> 
> 1. we would like to request a preliminary determination according to chapter 12
> of Mozilla CA Certificate Policy. It is crucial for us to know, whether you
> will accept the certification of the "competent" party or not.

My preliminary determination is that it will not, because the auditor is required to be an independent party (policy section 10) - and your auditor appears to be part of the same company as you.

However, you say you are also undergoing a WebTrust audit. That would make life considerably simpler. Do you know when that might be completed and published?

> 2. Can you give us feedback about your next internal stages to a final
> decision? Can we support this process?

I ask you questions; you provide answers :-)

> 3. If we finally succeed with our request: How will the certificate be
> published in the Mozilla software products?

How? Or when?

How: by the certificate being checked into the NSS (Network Security Services) module root store, and then at some point after that, a version of Firefox and Thunderbird being published which uses that version of NSS.

When: depends how quickly we move :-) We are currently attempting to put new certificates into Firefox 2 security updates, rather than waiting for Firefox 3.

> 4. We can imagine that the processing of CA requests is not your top priority,
> but we would appreciate some information about typical timeframes for this
> process, so that we can adjust some of our projects related to that issue.

It takes as long as it takes. I started working on the backlog in February; the first certificates made it into NSS in early June; the Firefox release containing them will probably appear in July. However, now that we have the process defined, subsequent ones might well be quicker.

Gerv

Comment 13

10 years ago
Hello Gerv,

thanks for your feedback.

Find below some answers to your questions & comments.

1. For the issue of the independent auditor: I assume that your concerns about the independence come from the point that the names of both units involved contain the Brand T-Systems. The the following link contains a statement and certificates of the auditor about this issue (http://pki.telesec.de/service/documents/ETSI_Third_Party_Statement.zip). If you still have any doubts feel free to contact Dr. Kersten of T-Systems GEI directly.

2. As for the Webtrust Audit:  Unfortunately we can't afford to wait for the Webtrust audit to be completed for "Deutsche Telekom Root CA 2" due to some obligations. We were told by the auditor only lately that they intend to monitor the Trustcenter operations for at least 2 months after the initial audit before they will issue the final certificate of compliance. This will take until early October. We intend to use Webtrust for applying for embedment of two more Root CAs later this year.

3 .######  Please provide an HTTP URL to the CRL for your root certificate.

Find the http URL of the ARL on	 http://pki.telesec.de/service/certificates/index.html
or directly http://pki.telesec.de/cgi-bin/service/af_DownloadARL.crl?-crl_format=X_509?-issuer=DT_ROOT_CA_2


4. #####- Please also let me know with what frequency you issue CRLs which list revoked end entity certificates.

Find below a translated extract of the CPS of  DT CA 2:
"4.9.7 Frequency of the publishing from revoked information (CRL)
The CRL will we published and offered in standardised form every 6 months. If there is a relevant revoking related this CRL within these 6 months, it will generate a new CRL to this event.
 
4.9.8 Maximum latency of the revocation lists
the latency of the revocation list is at least 12 hours."

For end entities please see e.g. CPS of T-TeleSec MailPass Advanced:

"2.3.5 Publishing of Certification Revocation List 
The CRL is generated and published at least every 24h. The crl is generated with a latency of 4h."

Documents about MP Advanced can be found on:
http://dir.mailpass.de/caservice/MailPass_advanced/Dokumente/index.html

In general: All sub CA have to comply to ETSI which requires regular updates within 24h

5. ####Can I confirm that you are applying for all of email, SSL and code-signing capabilities? And that your CP and CPS cover the issuance process for all three types?

Yes we apply for all of email, SSL and Code-Signing. 
Chapter 1.3.3 (Once again we have to refer to the German CP and CPS:-( )of the CP descibes in in general that certificate requestors have to authenticate themselves personally to receive any type of certificate.


As you can see we are trying to support the process very hard;-)

Best regards

Wolfgang Pietrus

Comment 14

10 years ago
Hello Gerv,

to me it looks that all of your questions have
been answered by Mr Pietrus from T-Systems but
there's hasn't been a feedback yet from Mozilla's
side.

Is there still something missing? It would really
be nice if we could have "Deutsche Telekom Root CA 2"
beeing trusted by Firefox in the very near future.

Kind regards
  Michael
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

Comment 16

10 years ago
Hello Gerv,

I can confirm that the information for our CA are correct.

Regards,
 Axel

Comment 17

10 years ago
Hello Gerv,

http://www.mozilla.org/projects/security/certs/pending/#T-Systems
is still displayed in "yellow".

What is missing to get it into "green"?

Best wishes
  Michael
I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv
Michael: apologies for that; it should turn green next time I check in, which will be today. I hope that someone will be able to look at your application soon.

In the mean time, there is one problem. We are starting to be more strict about audits, and confirming that the auditor is making an explicit statement about the audit. Consequently, we are no longer happy about self-hosted audit certificates. Can you please ask your auditor to place your ETSI certificate somewhere on _their_ website, so as to confirm that they issued it and stand by it?

Thanks,

Gerv

Comment 20

10 years ago
Hi Gerv,

you can also find the ETSI certificate on the website from the auditor:

http://www.t-systems-zert.com

or the direct link to the document

http://www.t-systems-zert.com/pdf/ein_03_sig_zda/zf_03a180_e.pdf

Regards,
 Axel

Comment 21

10 years ago
Hello Gerv,

I hope you had a relaxing vacation?!

We have killed time by translating the CP and CPS to the English language :-)

You can find them under the following links:

http://pki.telesec.de/service/documents/T-Systems-CPS-CA-2-English-v11.pdf

http://pki.telesec.de/service/documents/T-Systems-Root-CP-English-v12.pdf

We expect this to be helpful for further examination.

Two more issues:

1. You mentioned earlier that Mozilla considers the possibility to issue certificates via patches: Do you have any news about that?

2. What time do you typically plan for the Public discussion/inclusion phase of the process? (This question may annoy you, but I have to make an estimation for my management whether we will make it until the end of the year or not. I promise we won't nail you down on that issue:-)

Best regards

Wolfgang Pietrus



Comment 22

10 years ago
(In reply to comment #19)
> Michael: apologies for that; it should turn green next time I check in, which
> will be today. I hope that someone will be able to look at your application
> soon.

Hi Gerv,

http://www.mozilla.org/projects/security/certs/pending/#T-Systems
still isn't in Green - what exactly is stopping the process?

Greetings
  Michael

Comment 23

10 years ago
Hello Gerv,

we have been thinking about other informations we can provide to enable a proper decision on your side. What we have seen in the logs of other CA requests is that you are concerned about the registration process as part of the RA functionality.

For this find in the following an excerpt from a form that shows what data requestors have to provide (Once again: We address the German market, so those docs are in German also. Google translation may help you to decide whether this doc is helpful or not. If so please tell us and we will provide English translation asap.)

Checks of those data (e.g. the conformity with the entry in the puplic company register) are being done during the phase of contractual negotiations (performed by our legal department) and during the processing of the technical request. 

Excerpt from the form:
****************************************************************
Sehr geehrte Kundin, sehr geehrter Kunde,

bitte füllen Sie den nachfolgenden Zertifizierungsauftrag aus. Die mit Sternchen (*) gekennzeichneten Felder stellen Pflichtfelder dar. Anhand der Angaben wird ihr Zertifikat im 
T-Systems Trust Center erstellt. Das T-Systems Trust Center wird beauftragt ein CA-Zertifikat zu generieren. Das CA-Zertifikat wird zur Signatur von Client Zertifikaten, SSL-Zertifikaten und Sperrlisten eingesetzt. Die CA wird im Folgenden als „     “ bezeichnet (dies entspricht dem Common Name im Subject des CA-Zertifikats).

1	Auftraggeber (Organisation)

Firma*:	
Postanschrift*:	
	
Land*:	
Vertragsnummer*:	


2	Vertreten durch; (diese Person muss den Vertrag unterschreiben, 
Weiterhin vertreten durch)
Name*, Vorname*:	
Funktion*:	
Name, Vorname:	
Funktion:	



3	Für die technische Abwicklung verantwortlicher Ansprechpartner
Name*, Vorname:	
Funktion*:	
Straße*:	
Postleitzahl, Ort*:	
E-Mail*:	
Mobil-Rufnummer*.:	
Telefon*:	
Faxnummer:	


4	Sperrpasswort
Legen Sie hier das mindestens 8-stellige Sperrpasswort für dieses Zertifikat fest 

Sperrpasswort*
nur Ziffern (mind. 8-stellig)	0
0
0
0
0
0
0
0
0
0
0



5	Laufzeit des CA Zertifikats
0	Erstbeauftragung	0	Zertifikatserneuerung

Zertifikatsgültigkeit:	0  3 Jahre      0  5 Jahre    0 Jahre

Die Gültigkeit des CA Zertifikats darf die Gültigkeit des Root CA Zertifikats nicht überschreiten.


6	PKI Hierarchie  und  Zertifikatsinhalte
6.1	Übersicht
Das Zwischenstellenzertifikat soll in der folgenden Hierarchie stehen (bitte skizzieren):








 

6.2	Deutsche Telekom Root CA 2

Das Root-Zertifikat enthält folgende Informationen:
Zertifikatsfeld	Inhalt
Version	X.509 Version 3
Schlüsselalgorithmus	SHA-1/RSA
Schlüssellänge	2048
Aussteller des Zertifikats	C=DE
O= Deutsche Telekom AG
OU= T-TeleSec Trust Center 
CN=Deutsche Telekom Root CA 2
Eigentümer des Zertifikats	C=DE
O=Deutsche Telekom AG
OU=T-TeleSec Trust Center
CN= Deutsche Telekom Root CA 2 
Gültigkeitsdauer	Von: 09. Juli 1999 12:11:00 (UTCTime)
Bis: 09. Juli 2019 23:59:00  (UTCTime)
Seriennummer	0x26 (hexadezimal)
	subject key id	31:C3:79:1B:BA:F5:53:D7:17:E0:89:7A:2D:17:6C:0A:B3:2B:9D:33
Signatur	Digitale Signatur der Deutsche Telekom CA 2

Das Root-Zertifikat Deutsche Telekom Root CA 2 zeichnet sich dadurch aus, dass ihr Zertifikat mit dem eigenen privaten Schlüssel signiert wurde (self signed root). Zur Prüfung der Authentizität des „Deutsche Telekom Root CA 2“ Zertifikats kann folgender Fingerprint des Zertifikats herangezogen werden:

SHA-1:	85A4:08C0:9C19:3E5D:5158:7DCD:D613:30FD:8CDE:37BF

6.3	      CA-Zertifikat

Legen Sie hier die Rahmenbedingungen für das zu erstellende Zertifizierungsstellen-Zertifikat fest. Das „     “ Zertifikat wird gemäß Standard X.509 v3 wie folgt erzeugt:

Zertifikatsfeld	Inhalt	Bemerkungen
Version	v3	
SerialNumber 	<Seriennummer>	
Signature Algorithm Identifier	SHA1 mit RSA	
Issuer
Country	DE	
Organization Name	O=Deutsche Telekom AG	
	Organizational Unit Name	OU=T-TeleSec Trust Center	
Common Name	CN= Deutsche Telekom Root CA 2	
Validity
	Not Before	                                                (UTCTime)
	Not After	                                                (UTCTime)
Subject
	Country	DE	
	Organization Name		
	Organizational Unit 1		
	Common Name		
SubjectPublicKeyInfo
	Algorithm 	<ID für RSA>	Algorithmus, mit dem der Schlüssel verwendet wird, hier RSA
	subjectPublicKey	<Schlüssel>	öffentlicher Schlüssel der CA, 
Schlüssellänge 2048
Extensions
Authority key id	non critical	KeyId:<key identifier>	Inhalt ist gleich mit dem Inhalt der Extension "subject key identifier" des Root Zertifikats; wird für das sog. "Chaining", also das Überprüfen der Zertifikatshierarchie verwendet.
key usage	critical		

subject key id	non critical	<wird bei Zertifikatserstellung errechnet>	Hash des Wertes des ASN.1 kodierten BIT STRING "subjectPublicKey" (ausgenommen Tag, Länge und unused bits); dient dazu, schneller das "richtige" Zertifikat zu finden, wenn mehrere Zertifikate für denselben Subject DN vorliegen.
BasicConstraints	critical	CA; path length 2	Wichtig: Wird vom Trust Center vorgegeben! path length 2.
CRL distrib.point	non critical	http://
Distrib.Point name Full NameURL	gibt an, wo eine Anwendung per http und/oder LDAP  die ARL (Authority Revocation List) beziehen kann. 
Certificate Policies	non critical	Policy OID
CPSURL
weitere	Abgeleiteter Object Identifier für die Policy aus einem registrierten Object Identifier.  URL gibt an, wo eine Anwendung z.B. das CPS beziehen kann.

7	Request
Der PKCS#10- Requset, der für die die Erstellung des Zertifikats verwendet wird:













8	Erstellung und Management des CA-Zertifikats
Das T-Systems Trust Center wird bevollmächtigt, das „     “ Zertifikat zu generieren. Die Key-Ceremony des CA Zertifikats erfolgt auf einem stand-alone Rechner ohne jede Netzanbindung/ offline in sicherer Umgebung des T-Systems Trust Centers.


9	Veröffentlichung des  Zertifikats
Wählen Sie ob und wie ihr CA Zertifikat öffentlich zur Verfügung gestellt werden soll. 

0 Veröffentlichung per LDAP Verzeichnis

0 Veröffentlichung per http Webserver

0 keine Veröffentlichung


10	Teilnahme an der T-Systems Key Ceremony 
Sie können persönlich bei der Generierung ihres CA Zertifikats im T-Systems Trust Center teilnehmen. Die entstehenden Kosten für die Anreise sind selbst zu tragen. Eine Terminabstimmung ist erforderlich

0	Ja, wir möchten persönlich teilnehmen	

0	Nein, wir nehmen nicht teil

11	Zertifikatsrollout
Wählen Sie bitte wie wir Ihnen das Zertifikat zustellen sollen.

0 	Persönliche Übergabe

0 	Zusendung per Compact Disc (CD) auf dem Postweg

0 	Zusendung per E-Mail

12	Zusatzinformationen
Certificate Policy (CP) und Certification Practice Statement (CPS)  
http://pki.telesec.de/service/certificates/index.html /

Rufnummer der Sperr-Hotline:
01805 268202


 

13	Unterschrift  
Ich bestätige die Korrektheit der Angaben. 


Ort:


Datum: 				Unterschrift:


14	T-Systems Freigabe zur Produktion 
Die Freigabe zur Produktion erfolgt durch die Unterschrift des zuständigen 
T-Systems Produkt Verantwortlichen.


Ort:


Datum: 				Unterschrift:


*********************************************************

We are looking forward to more questions... :-)

Best Regards

Wolfgang Pietrus

> 1. You mentioned earlier that Mozilla considers the possibility to issue
> certificates via patches: Do you have any news about that?

Yes. New certificates have been and are being included in security updates for Firefox 2.0. So once your certificate is approved, and checked into NSS, it should make it into a subsequent security release of Firefox 2.

> 2. What time do you typically plan for the Public discussion/inclusion phase of
> the process? (This question may annoy you, but I have to make an estimation for
> my management whether we will make it until the end of the year or not. I
> promise we won't nail you down on that issue:-)

When we reach that point, the public discussion phase takes 2 weeks, unless discussion continues after the time or issues are raised which need to be resolved.

(I'm afraid I have not yet had time to begin an evaluation here.)

Gerv

Comment 25

10 years ago
Dear Mr. Markham,

We, the German aerospace center (DLR), together with other institutions in the German science community, use the trust center of the DFN-Verein, which is the prime non profit network-provider of the German research institutions and universities. The trust established by the DFN-CA, which operates under the Deutsche Telekom Root CA 2 is vital to a number of scientific programs in Europe wide computing-, storage- and info-grids crossing many organizational boundaries. As most scientists use Firefox as the preferred browser, the inclusion of the Telekom Root CA as a trusted certificate in Firefox would certainly simplify the setting up of trusted relationships within the German and European scientific community.

Best regards 
Falk Rühl

Comment 26

10 years ago
Hello Gerv,

http://www.mozilla.org/projects/security/certs/pending/#T-Systems
is since weeks displayed in "green".

With Firefox security release 2.0.0.8 just being rolled out, it 
seems though that Deutsche Telekom Root CA 2 is still missing from 
the Firefox certificate store. Any idea when we can expect some
progress in this issue? 

Best wishes
  Michael

Comment 27

10 years ago
It was mentioned in comment #10 that a WebTrust audit is/was in progress, according to comment #13 the audit should be finished around october. Is there any progress on that? I don't know if it would speed up progress on this bug, but I hope that the CA certificate will be included soon...

Comment 28

10 years ago
Thorsten,

the Webtrust Audit is currently in the phase of 'observation', which means that the auditors monitor our activities for about 2 months. This phase will end in week 46. After that we expect to recieve the certificate of compliance.

Still we consider the ETSI standard to be equal to Webtrust.

We certainly all share your hope in this case :-)

Best Regards

Wolfgang Pietrus

Michael,

Frank Hecker (hecker@mozillafoundation.org) is taking over control of the Mozilla root program. I hope he will be in touch soon.

Gerv

Comment 30

10 years ago
Are there any estimates when this bug will go forward?

Thorsten

Comment 31

10 years ago
The certificate of compliance issued by T-Systems Zert mentions:

"This certificate [...] is valid until July 31, 2007.
According to the rules of the certification scheme of T-Systems, the
validity may be prolonged by annual re-assessments."

Has there been a re-assessment yet?

Comment 32

10 years ago
Hello Frank,

now that Gerv has given responsibility to you we would like to continue the process of evaluation with news about our process of obtaining a Webtrust Certification:

The auditor has committed all steps of evaluation with no resulting obligations on our side. Since the audit was performed by a German branch of a well known American consulting group we have to wait for the certificate from the US. We expect to receive the certificate within the next three weeks. 

We would like to know what we can do to support the evaluation process in the meantime. Do you have any questions about the informations we delivered to Mozilla?!

We guess you might have other urgent obligations but we would appreciate a statement from your side about your plannings for the evaluation process in common and for our request in particular, if possible.

Best regards

Wolfgang

Comment 33

9 years ago
Hello Frank,

we have some good news (at least we consider them good):

We have finally managed to retreive a certification according to Webtrust standard in addition to our ETSI ceritification:

https://cert.webtrust.org/ViewSeal?id=701
https://cert.webtrust.org/SealFile?seal=701&file=pdf

Now that Firefox is in the late Beta we wonder whether we will make it into the final release. Can you give us some feedback about the timetable for Firefox (what will be the last possible date to get into the final release?)or how Mozilla will proceed with the evaluation of requests for root integration in the future?

Best regards and merry X-Mas 

Wolfgang


Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv
Assignee: gerv → hecker
Status: REOPENED → NEW

Comment 35

9 years ago
Hello Frank,

is there still any information missing that prevents this bug from going forward?

Thorsten

Comment 36

9 years ago
(In reply to comment #35)
> is there still any information missing that prevents this bug from going
> forward?

I do not know, I will have to double-check. I am currently devoting all my time to review requests from CAs offering Extended Validation certificates; after I complete that task (probably at the end of January) I will look at your requests and others. I apologize for the delay.
Status: NEW → ASSIGNED

Comment 37

9 years ago
Hello Frank,

looks like you are making significant progress with the evaluation of EV related requests which gives me hope that we will talk about our request very soon (I have to do this as a reminder, since we all have impatient superiors; so no offense meant:-))

Gerv used to ask all other requestors about their verification process for email certificates (How they verify that the requestor owns the email address).

To answer that question: We do not give certificates to private (single) persons with one exception: certificates for qualified signatures according to the German Signature Act. Those certificates contain no email addresses or domain information, so there is no prove required for those data.

All other certicates are being issued to enterprise customers (we provide CA functions as a managed service or dedicated PKI environments that comply to our policies) In both cases the customer has to prove as a minimum that 

1. he owns the domain
2. complies to our CPs (by signing a contract and the assured readiness to allow audits whenever we consider them necessary)(audits for customer location are being performed before dedicated PKI Environments can go live) 
3. his internal processes ensure a proper mapping of employees and enterprise identities as part of the RA function (by providing documents and allowing audits).

We consider this to be sufficient to prevent people from impersonating others.
(At least nobody should be able to request successfully a certificate for bill.gates@microsoft.com or george.bush@whitehouse.gov). Still there can't be no absolute certainty within enterprise domains, since typically to many systems and people have access to the IT based identity and ressources of employees)

As soon as you get to work on our request we would like to get some feedback about that issue (we allways like to improve our services)

Best regards

Wolfgang 





According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	
Whiteboard: Information confirmed complete

Comment 39

9 years ago
Well, it has been a month that this request was moved to "Information confirmed complete". Any progress on this? I wonder why this takes so much time... Other requests were submitted early this year and seem to have made it already into the browser (or at least into the test builds)... When will steps 2, 3 and 4 (test build of NSS with new certificate, check in into NSS store, inclusion in Mozilla products) take place?

Regards, Olaf Gellert

Comment 40

9 years ago
Olaf,

the status was changed to Information confirmed complete about six month ago. In the meantime the CA has passed a WebTrust audit (see comment #33), which, according to Gerv Markham in comment #12, "would make life
considerably simpler". Which obviously it does not if if the request does not get processed at all. For a start the page 
http://www.mozilla.org/projects/security/certs/pending/#T-Systems
should get updated to reflect the fact that there has also been a WebTrust audit.

The problem is the shift of focus in mozillas CA program to try to include as many EV-enabled root certificates with firefox 3. So almost nothing happens on the non-EV-front these days. I have the impression that mozilla is currently a bit understaffed when it comes to evaluating CA requests, and I hope they will be able to solve that problem. I think many people, both from T-Systems but also from the scientific community in Germany are willing to help if they are asked, as you can see from the long list of CC'ed persons on this bug. But the problem is that we cannot evaluate the request for mozilla. We have to wait - and hope that this bug will get resolved before his first birthday (which is really very soon...)

Regards
Thorsten

Comment 41

9 years ago
Frank,

since some time has passed by since your last action we would like to receive an update about your schedule. Do you have any idea how long it will take to process all EV requests and then continue with the 'lesser' requests?

Will it be useful if we raise an request for integration of an EV-CA Cert of T-Systems (We intended to do this after a successful integration of our first root), so that you can handle them together? 

We understand that Mozilla has no unlimited resources to work on such issues, but we don't do this request just because we like the idea to be integrated in all important browsers but for business reasons.

T-Systems is part of Deutsche Telekom Group, which means that we have more than 50 million customers worldwide and about 160.000 business customers that receive ICT services from us. Being able to provide secure and convenient services to our customers on the Mozilla platform would help not only us but also Mozilla on its goal to address the business market as well.

For this we would like to receive some signs from Mozilla when the evaluation will continue, so that we can prioritize some of our other tasks.

Kind Regards 

Wolfgang

T-Systems Enterprise Services GmbH
ITO, CSS,  Professional Services & Solutions 
Wolfgang Pietrus 
Senior IT-Architekt 
Pallaswiesenstr. 182, D-64293 Darmstadt 
+49 6151 818-6113 (Tel) 
+49 6151 818-652 (Fax) 
E-mail: Wolfgang.Pietrus@t-systems.com 
http://www.t-systems.com 

Summary: Add CA cert for T-system Trust Center → Add Deutsche Telekom CA cert for T-system Trust Center

Comment 42

9 years ago
I'm assigning this bug to Kathleen Wilson, who will be collecting any other needed information relating to this request.
Assignee: hecker → kathleen95014
Status: ASSIGNED → NEW

Comment 43

9 years ago
Hi,

the Mozilla Firefox 2.x Version shows on
http://www.dfn.de/dienstleistungen/dfnpki/
or
https://www.pki.dfn.de/

a window with the information
"Website zertifiziert von unbekannter Zertifizierungsstelle". Please accept this certificate.

But the Mozilla Firefox Version 3.x only shows a blank page. The user gets no information to accept this certificate. So nobody can work with certificates, signed by the "Deutsche Telekom Root CA 2" due to this Mozilla Firefox bug.

We are one of the 160.000 business customers an it's realy a big problem. The only way to work with this certificates is to recommend our users to work with other browsers than the Mozilla Firefox. And that is not the solution we are searching for.

Comment 44

9 years ago
(In reply to comment #43)
Well, using "firefox 3.0 RC2" on Linux, I cannot see this bug. I get a clear error message (if I do not have the "Deutsche Telekom Root CA 2"):

Secure Connection Failed
www.pki.dfn.de uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is not trusted.
(Error code: sec_error_untrusted_issuer)

But still: It seems a bit funny that the new person "will be collecting any other needed information relating to this request". This request is listed as "Information confirmed complete" since more than three months (see comment #38).
I hope that this issue will come to a happy end very soon... sigh.

Regards, Olaf Gellert

-- 
Olaf Gellert
Universitaet Hamburg
Regionales Rechenzentrum
Kommunikationsnetze
Schlueterstrasse 70
20146 Hamburg
This bug exists since 2004 and the whole german educational sites wait for solving this bug. I wonder, how often you assign this bug another person. Please accept the certs from t-systems (you yourself said, all is complete) or all German Universities and Educational sites can't use Firefox browser anymore which we all don't want.

Regards
Wolfgang Baumgartner
--
Wolfgang Baumgartner
Hochschule Weihenstephan
Rechenzentrum
Am Weihenstephaner Berg
85354 Freising
(Assignee)

Comment 46

9 years ago
Created attachment 324317 [details]
InfoGathering document created on 6/9/2008

Hi,

Attached is the InfoGathering document that I have created for this request. This is based on a template that I am using to gather/verify information for requests that Frank assigns to me.

As per the attached document, I have the following questions.

1) Does the Deutsche Telekom Root CA 2 have (now or in future) subordinate CAs that are operated by third-parties?  If yes, what controls are in place to ensure that the third-party follows the same practices as the root?  For instance, is there contractual obligation to follow the CPS, are there audits, are the technical constraints in regards to the third-party’s ability to issue their own subordinate CAs?

2) In the English version of the CP and CPS I was not able to find text stating that the domain name referenced in the certificate is verified to be owned/controlled by the subscriber.  Would you please tell me which section to look in?

3) The English version of the CPS says: “Unverified end subscriber information is information that is included in the certificate without being checked and includes:  the organizational unit (OrgU)”
Is it accurate to say that the value of the Organization attribute is not verified to be that associated with the subscriber, so it is not OV?

4) Would you please provide the url to a website (can be a test site) that uses a cert that chains up to this root?

5) I see comment #37 about verifying that the email address for an email-cert is owned by the subscriber. However, this is still not clear to me.  One of the things I’m supposed to find in the CPS is text that states that when a cert is to be used for email, that the email address is owned by the subscriber of the cert.  I was not able to find this in the CPS.  Will there be end-entity email-certs that chain up to this root?

Thanks,
Kathleen

Comment 47

9 years ago
Dear Kathleen,

I try to answer those of your questions that I have answers for. I can offer some more answers for the Deutsche Forschungsnetz (DFN, German Research Network), but not for all possible other subordinate CAs, so this is left to the Deutsche Telekom.

(In reply to comment #46)
> 1) Does the Deutsche Telekom Root CA 2 have (now or in future) subordinate CAs
> that are operated by third-parties?  If yes, what controls are in place to
> ensure that the third-party follows the same practices as the root?  For
> instance, is there contractual obligation to follow the CPS, are there audits,
> are the technical constraints in regards to the third-party’s ability to
> issue their own subordinate CAs?

I only know one of the subordinate CAs, so: Yes, subordinate CAs exist. In the CPS of the Deutsche Telekom, section 1.3.1.1 states that the subordinate CAs have to follow the CP of the Deutsche Telekom. Comment #37 states that contracts and audits are in place...

> 3) The English version of the CPS says: “Unverified end subscriber
> information is information that is included in the certificate without being
> checked and includes:  the organizational unit (OrgU)”
> Is it accurate to say that the value of the Organization attribute is not
> verified to be that associated with the subscriber, so it is not OV?

OU (= organizational unit) entries are not O (= organization) entries. Usually OU entries are just the names of internal departments or working groups (which usually cannot be validated by anyone outside the company anyways).

> 4) Would you please provide the url to a website (can be a test site) that uses
> a cert that chains up to this root?

https://www.pki.dfn.de/

> 5) I see comment #37 about verifying that the email address for an email-cert
> is owned by the subscriber. However, this is still not clear to me.  One of the
> things I’m supposed to find in the CPS is text that states that when a cert
> is to be used for email, that the email address is owned by the subscriber of
> the cert.  I was not able to find this in the CPS.  Will there be end-entity
> email-certs that chain up to this root?

Yes, end-entity email-certificates exist. Again I cannot answer this for all Telekom customers. In the German Research Network, personal identification of each user and validation of email address is required (and it's in the CP of the DFN). The Telekom CP and CPS are not clear on this point (as far as I have seen).

Regards, Olaf
(Assignee)

Comment 48

9 years ago
Created attachment 324512 [details]
Completed InfoGathering

The attached document is the completed summary of the info gathered and verified.
(Assignee)

Comment 49

9 years ago
The info-gathering phase of this request is complete. 

Assigning back to Frank so he can proceed with the discussion phase for this request. 
Assignee: kathleen95014 → hecker

Comment 50

9 years ago
Hi Kathleen,

thanks for your work. Where does this discussion take place and where do we get information about this discussion and the decision?

Thanks in advance,

Winfried

P.S.: The Firefox 3 problem reported in comment #42 is solved now.

Comment 51

9 years ago
Sorry, a typo. The Firefox 3 problem reported in comment #43 is solved now.

Comment 52

9 years ago
Hello Kathleen, hello Frank

sorry for my late answer, but I was on the road for the last three days.

Since Mr. Gellert did answer to some of your questions, there is not much more to say. Nevertheless we want to make some official statements from the requestors side:

a. The only persons, who are authorized to make statements on behalf of T-Systems as the original requestor is me and my deputy, Mr. Lothar Eickholt. Others may be able to give senseful input (many people are eager to see this request making progress), but we are the only persons at that time, who can make general statements and can be held liable for them.

For this we will answer your questions in general, even if they tell the same story.

b. If Mozilla comes to the conclusion, that our CP needs more details in some points (we will blame our Webtrust Auditor for that:-), we will start our change process as decribed in the CP. Since we already do all the work, you mentioned in your questions, we see no problem in making tighter statements in the CP.

c. Find below our answers to your questions

1) Does the Deutsche Telekom Root CA 2 have (now or in future) subordinate CAs that are operated by third-parties?  If yes, what controls are in place to
ensure that the third-party follows the same practices as the root?  For instance, is there contractual obligation to follow the CPS, are there audits,
are the technical constraints in regards to the third-party’s ability to issue their own subordinate CAs?

The CA currently has 2 subordinate CAs that are operated by third parties, one of them serving the community of the the German Research Network (Deutsches Forschungsnetz, DFN ). There are certainly contractual obligations to meet at least the standard of the CP of the Root. Those contracts include the right to perform audits on the subordinate Ca (with full on-site access). Those audits are performed regularly (once a year) or on purpose (See chapter 8: Audits and other assessment criteria). Those rules will apply to all other possible future SubCAs as well.

2) In the English version of the CP and CPS I was not able to find text stating that the domain name referenced in the certificate is verified to be
owned/ controlled by the subscriber.  Would you please tell me which section to look in?

Section 3.2 of the CP describes the evaluation of involved parties. DT Root CA 2 is being used for Enterprise Services exclusively, which means that DT Root CA 2 issues no EE certs but certs for subCA’s of enterprise customers that have decicated PKI or use our “PKI as a service”. Those enterprise customers are contractually bound to comply with our rules or have no choice to do otherwise in case they receive our PKI services. Checking for the ownership of the domain is part of the legal process to come to a contract with those customers (It`s no big deal to examine the ownership of the domain via the responsible NIC). 


3) The English version of the CPS says: “Unverified end subscriber information is information that is included in the certificate without being checked and includes:  the organizational unit (OrgU)”  Is it accurate to say that the value of the Organization attribute is not verified to be that associated with the subscriber, so it is not OV?

OU (= organizational unit) entries are not O (= organization) entries. Usually OU entries are just the names of internal departments or working groups (which usually can't be validated by anyone outside the company anyway). So we bind the domain to the Organisation, not to OUs that change all the time in modern enterprises. Checking, whether OUs are valid or not comes down to the same problem as with E-Mail. We do check, whether there is a process in place to assign the right data to people who are going to receive certificates in an enterprise(automized data collection and manual checking by the RAs in place), but how this is being done in detail is always described in the CPS of the SubCA, that issues EE certificates.

4) Would you please provide the url to a website (can be a test site) that uses a cert that chains up to this root?
Please have a look to https://www.pki.dfn.de/ . This is an example of one of our established customers, DFN (see above). Most of our customers use their certificates in corporate or B2B scenarios and infrastructures.

5) I see comment #37 about verifying that the email address for an email-cert is owned by the subscriber. However, this is still not clear to me.  One of the
things I’m supposed to find in the CPS is text that states that when a cert is to be used for email, that the email address is owned by the subscriber of
the cert.  I was not able to find this in the CPS.  Will there be end-entity email-certs that chain up to this root?

In our opinion this question is correlated with and thereby answered in our comment to question 3.


Best regards 

T-Systems Enterprise Services GmbH
ITO, CSS,  Professional Services & Solutions 
Wolfgang Pietrus 
Senior IT-Architekt 
Pallaswiesenstr. 182, D-64293 Darmstadt 
+49 6151 818-6113 (Tel) 
+49 6151 818-652 (Fax) 
E-mail: Wolfgang.Pietrus@t-systems.com 
http://www.t-systems.com 

T-Systems Enterprise Services GmbH 
Supervisory Board: René Obermann (Chairman) 
Executive Committee: Reinhard Clemens (Chairman)*, Helmut Binder, Olaf Heyden*, Dr. Klaus Hofmann, Katrin Horstmann, Joachim Langmack*, 
Wilfried Peters*, Dr. Stefan Schloter, Dr. Matthias Schuster*, Zvezdana Seeger*, Dr. Rolf Werner
Commercial register: Amtsgericht Frankfurt am Main HRB 55933 
Registered office: Frankfurt am Main 
WEEE -Reg.-No. DE87523644 
*Member of the Board of Directors as defined under section 35 GmbHG 

Comment 53

9 years ago
Hi Kathleen

just to get it right: Did your statement in comment #49 mean, that you wanted to initiate the public discussion phase or did you mean to discuss your findings internally with Frank?

If it's the public discussion: Is it the group mozilla.dev.tech.crypto where it will appear?

If it`s the internal discussion: Did you come to some intermediate results (additional questions or some action points for us)

Best regards

Wolfgang Pietrus

Comment 54

9 years ago
Hi,
just to put my 2 cents in: 
Firefox 3 with its harsh behavior regarding unknown CAs and without inclusion of the "Deutsche Telekom Root CA 2" is NOT USEABLE within the German research network (all universities in Germany). Please proceed with this matter urgently!

Regards,
Frank Richter, Chemnitz University of Technology
speaking for many irritated users, and helpdesk staff members ...

Comment 55

9 years ago
Just a thought for the German Research Network (DFN):

Wouldn't the Firefox Client Customization Kit be a solution?
http://www.mozilla.org/projects/cck/firefox/

It allows to add certificates (among other useful things). The custom Firefox could be distributed over the existing DFN PKI channels.

Unfortunately, it doesn't support FF 3.0 yet.

Comment 56

9 years ago
The Firefox Client Customization Kit is no solution for us because this would mean that every student and every employee must install a customized Firefox on its private computer to use the services of the university. The result would be that they simply use another browser (this is what we have to recommend today).
I guess providing a URL to those students, so that they can download the 
root CA, is too difficult to seem reasonable, but modifying a browser 
product seems simple by comparison.  

Comment 58

9 years ago
Yes, you're absolutely right. To let more than about 2,200,000 students importing a CA certificate is indeed much more complicated than just including it in one of the next FF[23] updates. That's undoubtedly out of question. So it is not easy for me to understand why it takes so long: at least 15 month by now.

Comment 59

9 years ago
It's not about students only - we (University of Wuerzburg, Artificial Intelligence) develop ssl-secured-web-applications that we want to make available to all users worldwide - to users that don't know us or our intentions and are not tech-savvy. If they use FF3 and get these new really unsettling ssl warnings it is an insurmountable obstacle! And you can't get these users to install some dubious customized browser-thing that you even mustn't name FF - who would do that? (Btw: Is it possible to install such a browser parallel to an existing FF installation?)

[NOTE: If you add certificates to Firefox, you CANNOT ship a browser outside of your company or institution and call it Firefox.]

As assigned to security issues for the past years I tried to persuade all users in our department to use the more secure FF and now I have to recommend IE as an intermediary solution ... think about it: IE(!) as a SOLUTION(!) :-(

this "bug"-fix is really of the utmost importance. and no - we can't afford certificates from FF-trusted CAs since we have no budget.

so: pretty please with sugar on top :)

(and please: let no flame wars delay this issue)

Comment 60

9 years ago
I have now opened a one-week period of public discussion of this request, as mentioned in my post to the mozilla.dev.tech.crypto forum:

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/b8b35ebb512419b1#

This public discussion period will provide people in the Mozilla community with an opportunity to comment on the request, raise concerns, ask additional questions, etc. After the discussion period ends I will make a preliminary decision about whether or not to approve this request, and then we will have a further one-week discussion period to address any remaining questions or issues.

Updated

9 years ago
Status: NEW → ASSIGNED

Comment 61

9 years ago
I should have added: The mozilla.dev.tech.crypto forum is also accessible via email; see

https://lists.mozilla.org/listinfo/dev-tech-crypto

for information on how to subscribe and post to the mailing list.

Updated

9 years ago
Whiteboard: Information confirmed complete → In public discussion

Comment 62

9 years ago
Sorry to all subscribers that are already aware, but I'd like to ping this bug because there *has* been a substantial reply by Eddy Nigg on the aforementioned forum and I really think it would be good if there would be some authoritative answer to the issues mentioned.

You can find the reply here:
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/c408051da9b98474

Comment 63

9 years ago
Hi everybody. I never thought this day would come, but yesterday we (University of Cologne, one of the biggest universities in Germany, roundabout 50000 students and employees) decided to recommend IE as standard browser to all of our members - just because of this ridiculous CA thing. I would really appreciate if we could revoke this decision within the next days (!). So would you please stop discussing after 15 months and simply prevent all German universities and other institutions from advising against using Firefox? It really cannot be that difficult!
(In reply to comment #63)
> Hi everybody. I never thought this day would come, but yesterday we (University
> of Cologne, one of the biggest universities in Germany, roundabout 50000
> students and employees) decided to recommend IE as standard browser to all of
> our members - just because of this ridiculous CA thing. I would really
> appreciate if we could revoke this decision within the next days (!). So would
> you please stop discussing after 15 months and simply prevent all German
> universities and other institutions from advising against using Firefox? It
> really cannot be that difficult!

Stop.

Bugzilla is not a place for advocacy, and even if it were, it is categorically not for insults and grandstanding.  If you are unclear about our conventions and expectations in this respect, please read:

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

The notion that it is "easy" to push out a new CA to 180 million users who will now implicitly trust it to identify any site on the net suggests either that you gravely underestimate the value we place on our users trust, or that you are being facetious; in either case, it is a long way from reality.

I deeply regret the fact that we have a backlog of CA requests, but Frank and Kathleen have been making substantial progress on these in the last month, and yours is among the requests that has benefited from this since, as Frank said back in comment 60, this request is now in the public review process demanded by our CA policy.

I am also quite aware of how essential it is to you that your certificates be recognized, but belligerence will not get you the results you seek from this community.  Instead I would strongly encourage you to look for constructive channels, like monitoring the public discussion Frank has started, and offering whatever clarifications you can, if concerns are raised.

Our obligations are to our users and the open internet - they will be served by including roots like yours which help democratize the trust space, but they will not be served by forcing through approvals without due consideration, even if that does mean contending with a backlog.

Comment 65

9 years ago
To all people that have concerns about the progress of this request:

If you want to have further information about the backgrounds or ideas how to support us please contact me directly, so that we can take productive steps together. 

This would help us in gaining our goal without further delays or backsets.

Best regards

Wolfgang Pietrus

wolfgang.pietrus@t-systems.com

Comment 66

9 years ago
Frank,

Since 2 weeks of public discussion have been completed now, we would like to know something about your intentions.

As we understand the remarks of Eddy he has two major concerns:

1. the handling of external subCAs
2. our "high level" policy description 

The first one is a baseline issue, which will have impact not only on us or other roots, but on Mozilla also. If Mozilla don't trust in the ability of Trustcenter providers to do this kind of business in general and evaluate their SubCAs according to certain rules, you will have to evaluate many more enterprise CAs in the future (and perhaps to reevaluate all roots already included ), since many large enterprises (at least in Europe) do have or work on their own PKI. Given the queue of requests and Eddy's remarks about the high frequency of public discussions, this could be a real stress test for the defined process of Mozilla. But that's just our point of view and maybe there are other ways to do this with reasonable effort (for Mozilla and all afflicted roots).

For the second one: 

You made the following remark in the discussion: 

"Second, in the case of T-Systems the issue seems to be that T-Systems 
functions primarily as a root CA, not as a CA issuing end-entity 
certificates. Therefore the T-Systems CPS does not address practices 
relating to issuance of end-entity certificates. The solution seems to 
be that we need to look at the CPS documents for DFN and other 
subordinate CAs of T-Systems, or obtain some other public statement 
about the practices of these subordinate CAs."
 
So yes it's meant to be a "global" root and not to serve a mixed scenario.

Evaluating all SubCAs is one way to solve this problem for our request, but touches the first issue.

For this we would like to make the following proposal: 

1. We do work on our CP/CPS, make clarifications and describe how we evaluate SubCAs and what prerequisits they have to meet. If you find those descriptions sufficient, you give us a "temporal" acknowlegdement.
We will urge our Webtrust auditor to make exlicit statements about our behaviour as a root after the first reaudit in November. We are willing to take the risk to be the first root that was expelled from Mozilla, if you are not satisfied with the next audit report of the auditor.

2. As far as we know Mozilla is a member of the Webtrust program. We would like to see the Webtrust criteria enhanced with special criteria for roots to meet the fisrt issue, so that application provider like Mozilla can rely on the judgement of registered Webtrust auditors. We would be happy to be reaudited according to such special criteria. So if you have some influence on the Webtrust program, we would see this as the way to go.

To give you a feeling about our external SubCAs, there is one with an English CP:

http://pki.fraunhofer.de/cp/Certificate_Policy_Fraunhofer_Corporate_PKI.pdf

http://pki.fraunhofer.de/cp/Certification_Practice_Statement_Fraunhofer_Corporate_PKI.pdf

The other one (DFN) has a CP written in German which you won't find easy to translate.

We think this as an pragmatic approach to come to a solution with reasonable effort for all participants.

Please let us know what you think about it.

Best regards

Wolfgang Pietrus
Wolfgang, no CA was ever "expelled" from Mozilla, maybe not admitted. But yours wouldn't be the first root which would have to make some changes in order to get admitted (and some never change).

I think the Mozilla CA policy is very clear in its requirements and I'm surprised that you haven't consulted earlier with that policy (in order to find out if you are eligible). The audit requirement of Mozilla is being applied across the band and all other CAs were evaluated with the same scrutiny and the same criteria was applied. I'm not sure if Mozilla is willing to start negotiations with CAs about their admittance.

Comment 68

9 years ago
Eddy, as I understand T-Systems is perfectly willing to update its CP/CPS, so I think we should try to help them with what they will have to update. 

T-Systems here does pretty the same as GlobalSign with its Trusted Root Program:

From http://eu.globalsign.com/pki/rootsign.htm
"...By having its Root Certificate accepted and trusted by all standard browser software, the Microsoft CA or inhouse CA can easily perform:

The Microsoft CA or inhouse CA is able to issue, publish & revoke trusted certificates completely independently from GlobalSign or any other trusted CA."

The only difference that I can see here is that GlobalSign has Subordinate CA requirements mentioned in the CPS and has elaborated about the audits it performs on them.

So, from your point of view: Would it be sufficient that T-Systems updates its CPS with requirements for the Sub-CAs (which they of course have to be bound to), and give details about the audits that they themselves perform on the Sub-CAs?
IIRC and according to your comment above, there are two different issues at hand right now:

1.) Clear requirements in the CP/CPS in relation to validations and verifications the CA(s) have to perform for the issuance of EE certificates.

2.) Not circumvent the audit requirement set forth by the Mozilla CA policy. This means that the CAs which belong to this PKI and are under this root MUST be part of the audit. CAs themselves can't be the auditors, otherwise all CAs will audit themselves.

Please note that this bug is about T-Systems and not about any other CA. Should you have a complaint about a CA which is included in NSS, please file a different bug or post to the m.d.t.c. mailing list. Thanks.

Comment 70

9 years ago
Hello Frank,

now that I'm back from my vacation and have heard about the joining of Mark Surman as Executive Director of the Mozilla Foundation let me tell you that we appriciate the continuity of your work regarding the PKI stuff.

Given that continuity we would like to receive your decision about how to proceed with our request. 

As we have mentioned before we are willing to work on all issues deemed necessary by Mozilla. For this we need a statement we can rely on and that gives us a clear understanding how much we have to work on those issues.

Best regards

Wolfgang Pietrus

Comment 71

9 years ago
(In reply to comment #63)
> Hi everybody. I never thought this day would come, but yesterday we (University
> of Cologne, one of the biggest universities in Germany, roundabout 50000
> students and employees) decided to recommend IE as standard browser to all of
> our members - just because of this ridiculous CA thing. I would really
> appreciate if we could revoke this decision within the next days (!). So would
> you please stop discussing after 15 months and simply prevent all German
> universities and other institutions from advising against using Firefox? It
> really cannot be that difficult!

Now that Chrome is on the horizon, there soon might be a working open source browser alternative for the german scientific community: Under Windows, Chrome (0.2) uses the certificate store supplied by the OS. I for my part and institutional responsibilities will definitely closely follow the progress on this alternative.
This whole subject makes you wonder whether Firefox would benefit from a feature allowing users to alternatively select the OS trust store - or a combination of both.

Comment 72

9 years ago
Hi Marcus,

we (T-Systems) still see Mozilla Firefox as an advanced browser software which will continue to increase its market share. For this we won't stop pushing this issue and will do everything to satisfy Mozilla. 

At the given time we don't see Chrome as a real alternative to browsers like Mozilla, Opera or Safari. We do even prefer IE to Chrome, as long as Chrome does not address all privacy concerns (This statement is not meant to be the starting point of a discussion about preferred browsers:-).

As for the progress of this request: We still hope to receive news from Frank within a reasonable timeframe.

Regards

Wolfgang Pietrus
T-Systems

Comment 73

9 years ago
Is there a workaround for this bug?

I.e. where can I securely download the required certificates for manual installation? Securely means: the site doesn't have one of the required certificates in its certificate chain.

From a security point of view, there isn't really a point in downloading a certificate over an insecure connection, as an attacker might manipulate the connection right at that moment. (Call me paranoid, but's that's exactly the scenario that HTTPS is designed for, isn't it?)

Comment 74

9 years ago
Thomas,

to answer your question:

basically certificates consist of a public key, some information about the requestor and the issuer and a digital signature to prove the integrity and authenticy of this information. So you don't need to protect certifates during download. This is slightly different for Root certificates, since they consist of so called self signed certificates. A website secured by a ssl-certificate, that was derived from that root would prove nothing. This is, where this bug comes in. People trust the root, because the browser or OS tells him, he can trust it. For this we try to get in the Mozilla root store. Still there is a way tho check the root certificate: The certificate includes a so called fingerprint. The website of the CA will show this fingerprint and you can compare this data with those in the certificate after the download. If you mistrust the website anyway, call the operator or send him a letter and he will tell you the fingerprint. 

You can download the certifcate from the following links:

http://www.telesec.de/pki/roots.html
http://www.pki.dfn.de/index.php?id=globalroot

Before anyone complains about missing details or accuracy in my answer: this is not meant as a scientific dissertation, but a pragmatic short description.

Regards 

Wolfgang Pietrus

Comment 75

9 years ago
Thanks Wolfgang,

your answer pointed me in the right direction. But why didn't you mention the root cert can also be downloaded over a secure connection from here:

https://www.telesec.de/pki/roots.html

That will save Mr. Obermann a lot of phone time (from 8 million FF users).

Comment 76

9 years ago
Thomas,

As I mentioned, you don't need to protect the cerftificate during download. You have to be sure, wether ist comes from a trustworthy source or not. The link you have found, is authenticated by a SSL-Certificate that was derived from another root. So you just have a prolonged chain of trust. Still you have to decide, whether you trust the anchor of this chain or not.

But if you are content with this HTTPS link, Mr. Obermann will be glad too:-)

Regards

Wolfgang

Comment 77

9 years ago
Wolfgang,

what I meant by "secure" download is authenticity (i.e. security against man-in-the-middle-attack), rather than confidentiality of transmission (which is pointless for a public key as you correctly noticed).

I am a follower of a "reasonable trust" philosophy: If the root cert file comes from the expected server that again provides a proper certificate trusted by Mozilla's builtin roots, then it's good enough for me. Let's not forget that the purpose of this certificate is HTTPS which in turn only serves to provide trust in the connection, not in the stuff that the people put on the server in the first place.

In other words: A chain is only as strong as its weakest link.

Comment 78

9 years ago
Can all please stay on topic. Also see comment #64. This bug is about, and only about adding a cert and not how to get the cert securely,which Browser already has the cert, whether already added certs meet the Mozilla rules or whatever.
Thanks!

Comment 79

9 years ago
Frank,

we have read your entry in the Mozilla wiki about the CA scheduling.

We are working on the translation of the CP and CPS of DFN.

English CP and CPS of our other external CA (Fraunhofer) can be found at the following links:

http://pki.fraunhofer.de/cp/Certificate_Policy_Fraunhofer_Corporate_PKI.pdf

http://pki.fraunhofer.de/cp/Certification_Practice_Statement_Fraunhofer_Corporate_PKI.pdf

We will work also on our Root CP to clarify the process and recommendations for the integration of Sub CAs.

We will try hard to finish that work until the end of October so that public discussion can be done on those papers.

Best regards

Wolfgang Pietrus

Comment 80

9 years ago
Frank,

this is another vote for this bug and a further message with regard to the importance of this issue.

Certainly, the community owes a lot to the developers of Mozilla and the past development really is impressive. 

However, with regard to this bug, you are just plainly getting the priorities wrong. Germany, and especially the academic community in Germany, has always played a very important factor in promoting the use of Mozilla and of Firefox. With the new, stricter Firefox 3.0 behavior in the case of missing certificates this bug is becoming a real issue for a large number of educational departments - and as such the prime users and supporters of your browser in Germany. 

I understand that there are other issues, which are more important. I also understand that there are still some rules, regulations and details you have to check with regard to the certificates. I finally understand the importance of sticking to these rules and audit regulations for Mozilla and for the safety and for the reputation of the browser.

However, looking at the time line of this bug and considering the bad PR effect this has for Firefox, I also understand that you are simply setting the wrong priorities here. 

Thanks for listening.

Comment 81

9 years ago
Frank,

one more vote for this bug.

What Clemens said is exactly the point. We are a german university of applied sciences and Firefox 3 adds quite a lot to our support work. This is not the right place to discuss if the new behaviour concerning certificates makes sense - but it's a matter of fact that it is a sticking point where many users of our services fail.

We always recommended our users to use Firefox. But for the time being the users experience is: many services - including our own - are not working with Firefox, but they are with other browsers.

Firefox is a great product, I think it enjoys a good reputation especially in the german academic environment - it's a pity that this now gets damaged by unbalanced priorities: very aggressive appearance towards the user in case of unknown certificates on the one hand, low priority to enable service providers to solve the problem on the other hand.
Apparently the "Deutsche Telekom CA 5" root is cross-signed by GlobalSign and the path length of the "Deutsche Telekom CA 5" root is set to 1. This means that the sub-ordinate CAs of T-Systems are also valid under the GlobalSign root. Can it be that the servers you are trying to access are not configured correctly? 

The site https://www.telesec.de/ is working correctly for me and so should other certificates signed by T-Systems or one of their sub-ordinate CAs (which in itself is questionable since it circumvents the requirements of Mozilla, but that's a different story - nevertheless configuring the servers correctly might remove the pain some are seeing here).

Comment 83

9 years ago
Frank,

one more vote for this bug.

What Clemens said is exactly the point. We are a german university of applied sciences and Firefox 3 adds quite a lot to our support work. This is not the right place to discuss if the new behaviour concerning certificates makes sense - but it's a matter of fact that it is a sticking point where many users of our services fail.

We always recommended our users to use Firefox. But for the time being the users experience is: many services - including our own - are not working with Firefox, but they are with other browsers.

Firefox is a great product, I think it enjoys a good reputation especially in the german academic environment - it's a pity that this now gets damaged by unbalanced priorities: very aggressive appearance towards the user in case of unknown certificates on the one hand, low priority to enable service providers to solve the problem on the other hand.

Comment 84

9 years ago
Concerning #82:
Eddy,
Deutsche Telekom CA 5 is not Deutsche Telekom Root CA 2.
The latter one is relevant for German academic life.

General:
I am in the same situation that has been bemoaned by many people above.
(There are currently 72 subscribers including a wide range of German
universities as can be guessed from the mail addresses.)
We need SSL-secured web services and the "official" cert-chain leads to
Deutsche Telekom Root CA 2. Therefore, some progress in this issue would
be very much appreciated.

Achim
(In reply to comment #84)
> Concerning #82:
> Eddy,
> Deutsche Telekom CA 5 is not Deutsche Telekom Root CA 2.
> The latter one is relevant for German academic life.
> 

OK, I understand...and judging from your comments, this root isn't cross-signed by GlobalSign.

> General:
> I am in the same situation that has been bemoaned by many people above.
> (There are currently 72 subscribers including a wide range of German
> universities as can be guessed from the mail addresses.)
> We need SSL-secured web services and the "official" cert-chain leads to
> Deutsche Telekom Root CA 2. Therefore, some progress in this issue would
> be very much appreciated.
> 

To all of my knowledge, T-Systems are working on it in order to satisfy the requirements of the Mozilla CA Policy and than the inclusion can be addressed hopefully soon.

Don't blame Mozilla on shortcomings caused (maybe unknowingly) by the CA itself nor the fact that T-Systems could have applied for inclusion long time ago! Non-conformance to the Mozilla CA Policy is certainly not Mozilla's fault as this policy is up for anybody read and review at any time nor is this a new CA root either.

Anybody here is aware of the importance of this request, but the ball is now in the court of T-Systems (see comment 70).

Comment 86

9 years ago
(In reply to comment #85)
> Don't blame Mozilla on shortcomings caused (maybe unknowingly) by the CA itself
> nor the fact that T-Systems could have applied for inclusion long time ago!
> Non-conformance to the Mozilla CA Policy is certainly not Mozilla's fault as
> this policy is up for anybody read and review at any time nor is this a new CA
> root either.
> 
> Anybody here is aware of the importance of this request, but the ball is now in
> the court of T-Systems (see comment 70).

Nobody is blaming Mozilla. Mozilla is great. You are right: The ball is in the court of T-Systems...

But this is completely missing the issue!! The issue is about using or wasting the chance for producing good or bad PR. The issue is about taking care or ignoring a core topic of a large group of customers. The issue is about recognizing and solving a problem or bluntly sticking to ones rules.

Look at the statistics: By distribution percentage, Germany is one of the most important countries for Firefox. Look at the number of votes for this bug: There aren't so many bugs with a higher number of votes. Look at the email headers of people commenting this bug: This *is* an issue for a large group of users. It affects educational institutions and students and thus a very important group when it comes to making a browser famous and widely used. And it is about one of the few bugs where the community can't help out - here the decision and action of Mozilla / T-Systems is required.

So the ball *is* in the court of *Mozilla*, who, by ignoring the issue so far, are damaging their own product. :-(

And, while we are discussing, who is to blame and whose fault it is, why not just go ahead and fix the issue?? 

I am disturbed to understand that for a considerable number of institutions this bug (and similar issues for mass deployment of Firefox) is the reason that people are forced to use a different browser while at work or at school. Statistics show that Firefox use goes up after work and school hours.

Sorry guys, but I really feel uneasy seeing that one of the finest software forgeries (ie. Mozilla) is actively damaging it's product and not realizing it. Well, guess it's still their (ie. Mozilla's) decision.

Thanks for listening.

Comment 87

9 years ago
(In reply to comment #86)
> Sorry guys, but I really feel uneasy seeing that one of the finest software
> forgeries (ie. Mozilla) is actively damaging it's product and not realizing it.

I guess you meant 'forges' (pl. of forge - dt.: Schmieden) instead of 'forgeries' (dt.: Faelschungen). But the mix up did bring a smile to my face :-)

Comment 88

9 years ago
> I guess you meant 'forges' (pl. of forge - dt.: Schmieden) instead of
> 'forgeries' (dt.: Faelschungen). But the mix up did bring a smile to my face
> :-)

Oooops. Certainly. Sorry. This mix up really was not intended. What a shame.
(In reply to comment #86)
> The issue is about taking care or
> ignoring a core topic of a large group of customers. The issue is about
> recognizing and solving a problem or bluntly sticking to ones rules.
> 

Admittance of CAs is indeed about rules and regulations and not about ones taste or urgency. Anybody operating a CA - including Wolfgang from T-Systems - will be confirming that to you.

> Look at the statistics..

It isn't relevant to the inclusion process. The only relevance is the Mozilla CA policy...

> here the
> decision and action of Mozilla / T-Systems is required.

Exactly. And right now Mozilla waits for T-Systems to correct a few things in order to be in compliance with the Mozilla CA Policy.

> 
> So the ball *is* in the court of *Mozilla*, who, by ignoring the issue so far,
> are damaging their own product. :-(
> 

Mozilla did not ignore anything about the request of T-Systems, quite the opposite. Mozilla reviewed and gathered all needed documents, updated the relevant entries and promoted the CA to the public discussion prior to inclusion. This is the defined inclusion process of Mozilla. There it was where some issues have been raised with this request and T-Systems expressed their willingness to address those.

> And, while we are discussing, who is to blame and whose fault it is, why not
> just go ahead and fix the issue?? 

Because it's not about writing a patch - its about compliance!

> Thanks for listening.

I hope my explanation somewhat helps to understand why you and others are waiting to have this bug resolved.

Comment 90

9 years ago
(In reply to comment #89)
> The only relevance is the Mozilla CA policy...

The only relevance is customer satisfaction.
:-)

To a great extend you are right! This is measured by how users of Mozilla software can rely on the CAs which are included (or the certificates issued by those). Users of Mozilla can be fairly sure that those CAs conform to a certain standard (the Mozilla Policy) and were audited accordingly. This certainly highers customer satisfaction.
STOP!  This bug is NOT the place to discuss Mozilla CA policy.  This bug
is NOT the place to discuss whether the delay in accepting a CA is the 
fault of Mozilla or the fault of the CA.  Don't discuss such things here!

This bug is the place to track the formal proceedings that may lead to 
the approval of a CA.  Facts that are relevant to the acceptance or the 
rejection of this CA, that determine whether the CA does or does NOT meet
Mozilla's CA policy, belong here.  Personal feelings about the importance 
of this CA to the world, or to your nation, do not belong here.  

If it gets clogged up with advocacy, that will HINDER the approval.  
So, STOP THE ADVOCACY!  If you feed the uncontrollable urge to advocate, 
post in the mozilla.dev.tech.crypto newsgroup, NOT in this bug.

Comment 93

9 years ago
I want to share what I consider a partial solution of the problem in https://bugzilla.mozilla.org/show_bug.cgi?id=378882

The issue we are discussing here is closely connected with the overly aggressive manner Firefox 3 reacts to missing certificates. Below I describe a patch for turning off this behaviour and for making Firefox react the way it should. The user still has to add an exception, but the annoyance caused by the GUI is removed. Here I found more on this:

  http://eggdrop.ch/blog/2007/11/20/the-new-ssl-error-pages-in-firefox-3-suck/

Advanced users can do the patch themselves and institutions can distribute patched versions. Autoupdates, of course, will destroy the patch. As soon as I have a bit more time I will supply a perl script for automated patching to deal with that. Right now I can offer a description for manual patching and links for downloading patched jar files which presently base on Firefox 3.0.3 at 

  http://www.informatik.uni-rostock.de/~cap/firefox-patch/en-US.jar
  http://www.informatik.uni-rostock.de/~cap/firefox-patch/pippki.jar
  http://www.informatik.uni-rostock.de/~cap/firefox-patch/toolkit.jar


** Description **

All you have to do is to make 3 tiny edits in the jar files of Firefox. I will describe it also for non-native Firefox speakers, the specialists will pardon the many words :-)

For the description assume a US-english locale version of Firefox installed on a windows system in C:\Program Files\Mozilla Firefox

This installation directory contains a directory called chrome.

Chrome contains the files pippki.jar, toolkit.jar and en-US.jar (in case of other languages, the latter may have a different name). These files are zip compressed files, so uncompress them into directories pippki, toolkit and en-US using WinZip. 

STEP 1: In pippki\content\pippki\exceptionDialog.js at the end of function initExceptionDialog insert a checkCert(); (at line 100, see below)

  function initExceptionDialog() {
    gNeedReset = false;
    gDialog = document.documentElement;
    gBundleBrand = srGetStrBundle("chrome://branding/locale/brand.properties");
    gPKIBundle = srGetStrBundle("chrome://pippki/locale/pippki.properties");
    var brandName = gBundleBrand.GetStringFromName("brandShortName");
    setText("warningText", gPKIBundle.formatStringFromName("addExceptionBrandedWarning2",[brandName], 1));
    gDialog.getButton("extra1").disabled = true;
    var args = window.arguments;
    if (args && args[0]) {if (args[0].location) {     
      document.getElementById("locationTextBox").value = args[0].location;
      document.getElementById('checkCertButton').disabled = false;
      if (args[0].prefetchCert) checkCert(); } 
    args[0].exceptionAdded = false; } 
    checkCert(); /////////// THIS IS THE LINE TO ADD !!!
  }


STEP 2: In toolkit\content\global\netError.xhtml comment the if statement in front of showSecuritySection (line 183 and 185)
  // if (className == "expertBadCert") { /////// comment this
       showSecuritySection();       
  // } //////// comment this


STEP 3: If desired, you could also improve on the error messages by editing en-US\locale\en-US\pippki\certManager.dtd I suggest exchanging the line

  <!ENTITY exceptionMgr.supplementalWarning     "Legitimate banks, stores, and other public sites will not ask you to do this.">

by the line

  <!ENTITY exceptionMgr.supplementalWarning     "You should not do this unless you know what you are doing.">


STEP 4: Now we have to rebuild the jar files from the modifications. For this, navigate into the modified directories (ie. into pippki, toolkit and en-US). You will find directories content, content and locale, respectively. Make a zip file out of them and rename them into pippki.jar, toolkit.jar and en-US.jar respectively. Make sure Firefox is not running and copy these jar files into the chrome directory. This procedure is necessary to get the path information in the jar file correct.

Now start Firefox and compare the behaviour at an https site with missing root CA. 

If anything goes wrong, a simple reinstall saves the day.


** Effect **

The effect of the patch is to make the reaction of the browser more meaningfull and to provide a smoother GUI for setting up exceptions. It does not add a certificate to the browser and it does not modify the GUI for all versions of the browser, but for institutions distributing their own Firefox it might be helpful.

This file is http://www.informatik.uni-rostock.de/~cap/firefox-patch/README.txt


Thanx for listening
(In reply to comment #93)

> Thanx for listening

Clemens,

I'm not sure how to communicate this more clearly, but bug advocacy comments, and comments outside the specific questions of Deutsche Telekom's policy compliance with our CA Certificate requires, are not helpful here.  They make it harder for people to do their work on this bug, and consequently breed hostility which I think no one wants.

As for your patch, it seems it would be substantially easier to just change the "browser.xul.error_pages.expert_bad_cert" and "browser.ssl_override_behavior" preferences in about:config, and this would accomplish the same goals (absent the text change).

I mention that in an attempt to be helpful, but if your impulse is to pursue further discussion on the subject, take it to newsgroups or another bug.  Anywhere but here, which is a bug focused on gathering the necessary information to make an informed policy decision that you seem to want made, and yet are (inadvertently, I presume) impeding.

Comment 95

9 years ago
Please allow me to ask what the status of this issue is.
Is there any progress foreseeable?

Comment 96

9 years ago
(In reply to comment #95)
> Please allow me to ask what the status of this issue is.
> Is there any progress foreseeable?

You can check the status of (not only) this issue at:
https://wiki.mozilla.org/CA:Schedule#Target_schedule

also you may check out the status page of the DFN-Verein:
http://www.pki.dfn.de/index.php?id=statusmozilla&L=0

You can be sure, that we are working on the necessary tasks.

Regards,

Sven

Comment 97

9 years ago
Frank,

find below links to english translations of CP and CPS of DFN, which is the second external SubCA. 

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_v21-english.pdf

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS_v21-english.pdf

And once again links to CP and CPS of Fraunhofer Institute to spare you some  work.

http://pki.fraunhofer.de/cp/Certificate_Policy_Fraunhofer_Corporate_PKI.pdf

http://pki.fraunhofer.de/cp/Certification_Practice_Statement_Fraunhofer_Corporate_PKI.pdf

We will also provide a link to a extension of our Root CP until the end of the week, which describes the handling of external SubCAs (This handling was applied on both SubCAs). This extension will become part of the CP, when the public discussion has finished with no additional or minor requirements. 

Best regards

Wolfgang Pietrus
T-Systems

Comment 98

9 years ago
Frank,

find below links to english translations of CP and CPS of DFN, which is the second external SubCA. 

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_v21-english.pdf

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS_v21-english.pdf

And once again links to CP and CPS of Fraunhofer Institute to spare you some  work.

http://pki.fraunhofer.de/cp/Certificate_Policy_Fraunhofer_Corporate_PKI.pdf

http://pki.fraunhofer.de/cp/Certification_Practice_Statement_Fraunhofer_Corporate_PKI.pdf

We will also provide a link to an extension of our Root CP until the end of the week, which describes the handling of external SubCAs (This handling was applied on both SubCAs). This extension will become part of the CP, when the public discussion has finished with no additional or minor requirements. 

Best regards

Wolfgang Pietrus
T-Systems

Comment 99

9 years ago
Frank,

find below two links to the remaining deliverables we promised for the discussion:

1. A translation for a Draft of our CP
2. A translation of a "service description", which will become a mandatory part of the CP (see Draft of CP). This document describes, how we handle external Sub CAs. All those regulations apply to both DFN and Fraunhofer.

http://pki.telesec.de/service/documents/T-Systems-Root-CP_en.pdf

http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-Signing_en.pdf

The CP (the German version) and the service description will come into force, if Mozilla has no further recommendations after the discussion. Otherwise we will stay with the previous version until we have come to an agreement about additional changes or extensions. We do this, since we don't want to change the CP without knowing, whether we have to change some of the new parts after the discussion, which would confuse our customers and users.

PS: We saw that the discussion has been rescheduled once again. We intend to issue an request for an EV CA at the beginning of next year.
Given that long queue of CAs requesting integration into Mozilla, we wonder if Mozilla will consider steps to adjust to that workload, so that requests can be processed in less than 12 months.

Regards

Wolfgang Pietrus

T-Systems

Comment 100

8 years ago
According to https://wiki.mozilla.org/CA:Schedule#Target_schedule the public comment phase is running since 2009/01/02. Where can I find a link to that? Thanx.

Comment 101

8 years ago
The discussion phase will take place in 

news://news.mozilla.org:119/mozilla.dev.tech.crypto

But the schedule is already delayed, AFAICS the latest CA in discussion was S-Trust, but then came christmas and nothing seems to have happened any more since then.
(Assignee)

Comment 102

8 years ago
Created attachment 357192 [details]
Completed Information Gathering Document

Replace the msword doc with pdf.
Attachment #324512 - Attachment is obsolete: true
(Assignee)

Comment 103

8 years ago
Created attachment 357193 [details]
Review of Subordinate CAs

This document summarizes the information gathered for each sub-CA as per https://wiki.mozilla.org/CA:SubordinateCA_checklist
Within the document items highlighted in yellow indicate where further clarification is needed.

For each sub-CA CPS the issuance practices for end-entity certificates must satisfy section 7 of 
http://www.mozilla.org/projects/security/certs/policy/ in regards to demonstrating that reasonable measures are taken to verify the ownership/control of the domain name and the email address. 
For DFN, I could not find the text that demonstrates that reasonable measures are taken to verify the domain name.

Audit statements will also be critical in evaluation of the sub-CAs. Since T-Systems performs the annual audits for the sub-CAs, perhaps T-Systems can provide an official statement for each sub-CA that is similar in format/content to https://cert.webtrust.org/SealFile?seal=701&file=pdf, such that it includes:
a) The name of the person/organization who performed the audit
b) What the criteria were. 
c) The date the audit was completed, and the time frame that the audit covers.
d) Statement that problems found have been corrected, or that no problems were found.

By the way, do you have an audit statement for the root CA for 2008?

Comment 104

8 years ago
Does the last post from Kathleen Wilson means the public discussion will be suspended once again?
There is currently no public discussion active and it has not proceeded yet to another one. This bug entry will most likely be updated once the public comments period is restarted.

Comment 106

8 years ago
Sorry for another unqualified question, but somehow I got lost on the way. Could someone please post a rough timeline of how this story might end? 

It's hard for me to tell right now which side is delaying the process, but it's almost another two months since the CPS translations were online and since it is in the interest of T-Systems, why can't they fill out the SubordinateCA_checklist and only leave it to the Mozilla team for checking.

In a normal company, I would propose someone from T-Systems and someone from Mozilla (Wolfgang Pietrus and Kathleen Wilson or whoever) meet for a coffee and discuss the missing points and everything should be settled within a week. 

So guys, PLEASE get going!

Comment 107

8 years ago
Niels (and others),

T-Systems agrees with you that this bug has made slow progress (it started effectively in June 2007).

But T-Systems also recognizes that Mozilla is no "normal" company but manages an open source project and has limited resources to do that. 

Root CAs are crucial for people's trust in the security of the internet (If this trust is justified, is another question).For this Mozilla has established formal processes and policies to work on such requests like ours.

So even it is a pain for us to make such slow progress we agree with the general process of formal evaluation of our request and will not try to circumvent that process.

We will continue to deliver requested information and try to encourage Mozilla to invest more resources in our and other's request.

regards

Wolfgang Pietrus

T-Systems
Wolfgang, as far as I understand, it's your turn now to answer the questions from comment 103, am I correct?

Comment 109

8 years ago
Yes,

that's correct.

We are working on it to deliver the reqiired information in one bunch.

regards

wolfgang

Comment 110

8 years ago
Kathleen,

find below the requested input.

1. Verification of domain names:

DFN verifies Domain Names for all issued certificates. This immplicitely results from the regulations in the DFN charter. See 1.3.3 CP:
"Subscribers are natural persons and organizations who/which are granted certificates based on their eligibility stated in the charter of the DFN-Verein."

DFN is willing to make a clearer statement in the CP.
For example:

"3.2.2 Authentication of an organization identity:
[...]
If a domain name is used in a certificate, the organization's right to use the domain name is verified by DFN-Verein as the PCA."

This is what DFN is doing. Before signing a contract DFN will check, what domains belong to the contractor, and afterwards each certificate issued by the contractor will be checked, whether the certifcate belongs to those domains or not.

2. As for the Audit statements. 
Both DFN and Fraunhofer PKI were checked and developed together with T-Systems for more than 6 months, before the root signing did happen. 
The audit statements you will find at the following link (http://pki.telesec.de/service/documents/Audits.zip) are based on that fact. So don't be surprised that they say "no findings". 

The dates stated in the documents are basically the date, where we did our final audit actions. We did this to have formal statements for our contracts, not to have a public statement, so those documents are only available in German.

You will find that I signed those statements, since I was the leader of all activities with DFN and Fraunhofer. I was supported by several colleagues from our trustcenter and CERT, each bringing in at least 5 years of experience of Trustcenter services and auditing.

As for myself: I'm working for T-Systems as Security expert and architect since 1998, performing occasional internal audits (twice a year on average).
My first experiences with (corporate) PKI go back to 2001. In the beginning of 2006 our group started the integration of the Trustcenter of Deutsche Telekom into T-Systems, which is a 100% subsidiary of Deutsche Telekom. Since that time I have been dealing with security for Trustcenter services as well.

Please state, if you need more information about my CV.

Regards

Wolfgang Pietrus

T-Systems
(Assignee)

Comment 111

8 years ago
Wolfgang,

Thank you for your thorough response.

In regards to DFN, I think it would be best to ask them to add the text to their CP. Please let me know when it is there, so I can update the sub-CA-review document to point to it.

I believe that the audit statements that you provided for the sub-CAs are sufficient.

Note that the audit for the root posted at 
https://cert.webtrust.org/SealFile?seal=701&file=pdf 
is dated 12/3/2007. Is the 2008 audit for the root available? If not, when do you expect it to be available?

In regards to the new versions of your CP and Service Description at
http://pki.telesec.de/service/documents/T-Systems-Root-CP_en.pdf
http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-Signing_en.pdf
In order to cover future sub-CAs, would it be possible to add some general text in regards to sub-CAs meeting the requirement of section 7 of http://www.mozilla.org/projects/security/certs/policy/. 
For example: Customer CP/CPS demonstrates that in addition to verifying the identity of individuals and organizations, reasonable measures are taken to verify that the subscriber owns/controls the domain referenced in the certificate and the email account associated with the email address referenced in the certificate.
(I apologize for not noting this in my previous request)

Kathleen

Comment 112

8 years ago
Kathleen,

sorry, I missed the point in your last comment regarding the Webtrust re-audit statement for 2008. We expect the official statement within the next 10 days. The audit was performed by E&Y Germany but the statement will come from E&Y USA, since they are doing the formal part. 

We will consider your proposal for adding such a statement to our CP. We will give you feedback asap (most likely next week). I think there should be no problem with such a statement. Anyway we will deal with that topic like the others stated in our comment 99. Since we don't want to update the CP/CPS to often, we would provide an updated draft. After having all topics covered we will make this draft an official version.

Regards

Wolfgang

Comment 113

8 years ago
Kathleen

I just received the link to the official Webtrust audit statement 2008.

https://cert.webtrust.org/ViewSeal?id=851

Regards

Wolfgang

Comment 114

8 years ago
Kathleen,

I was to quick with sending that link.

Since we were audited for three roots we received 3 statements (unfortunately not at the same time). So I did send the link for one of our other (new) roots.

This is the correct link.

https://cert.webtrust.org/ViewSeal?id=853

Regards

Wolfgang

Comment 115

8 years ago
https://cert.webtrust.org/ViewSeal?id=851

https://cert.webtrust.org/ViewSeal?id=853 are giving this message:

Invalid domain [https://bugzilla.mozilla.org/show_bug.cgi?id=378882]: please contact your practitioner.

Comment 116

8 years ago
(In reply to comment #115)
Apparently, they're blocking requests coming from Bugzilla. Just press F5 to reload after getting the message or copy the URL to the address bar manually and it will work fine.
(In reply to comment #115)
> Invalid domain [https://bugzilla.mozilla.org/show_bug.cgi?id=378882]: please
> contact your practitioner.

Works from here.

Comment 118

8 years ago
WFM (using copied links)
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Opera/10.00 (Windows NT 5.1; U; en) Presto/2.2.0
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090131 Minefield/3.2a1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090131 SeaMonkey/2.0a3pre


doesn't work with gecko browsers using link from bugzilla because of referrer:
Doesn't work pressing F5, Reload or Shift-Reload

seems a referrer from a non-certified website (as bugzilla) causes this message. Seems reasonable, so if you copy the Seal and link to the website, folks following the link won't get official text but an error message and be warned.

Comment 119

8 years ago
Kathleen,

one more point regareding your comment#111

"In regards to DFN, I think it would be best to ask them to add the text to
their CP. Please let me know when it is there, so I can update the
sub-CA-review document to point to it."

DFN has provided a Draft fur an update of their CP.

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_DRAFT_v22-english.pdf

This version will go live when there are not other requirements out of the public discussion and the activation of this version is the last prerequisite for an integration. Otherwise those changes will be handled within the standard schedule for review of the CP.

Regards

Wolfgang Pietrus

Comment 120

8 years ago
Kathleen,

looks like you are making progress with the CA schedule (Microsec, Certigna, Comsign in different phases of the public discussion).

Do you think that you will be able to start our next round of discussion within March (We would like to be prepared and have our experts (T-Systems, DFN and Fraunhofer) ready and not having some of them on vacation)?

It would be nice to have a rough estimation for the timeframe. Our managers (like all managgers, I guess) tend to understand and accept postponed milestones but don't like answers like "we have no idea when it will happen".

So this question is not to urge you but to receive informal information about your personal agenda for the CA schedule.

Kind regards

Wolfgang
Regards

Wolfgang
(Assignee)

Comment 121

8 years ago
Hi Wolfgang,

I apologize for the delay. I have been waiting for the follow-up to Comment #112: "We will consider your proposal for adding such a statement to our CP. We will give you feedback asap (most likely next week). I think there should be no
problem with such a statement. Anyway we will deal with that topic like the others stated in our comment 99. Since we don't want to update the CP/CPS to often, we would provide an updated draft. After having all topics covered we will make this draft an official version."

Was there a decision to add or not-add the information about the requirements of sub-CAs to verify the ownership of domain name and email address to the CP?

I apologize if I missed it.
Kathleen

Comment 122

8 years ago
Hi Kathleen,

good point. It's me to apologize.

We will insert such a statement (We will provide a new CP/CPS with all required and agreed changes after the next public discussion phase). 

Regards

Wolfgang
(Assignee)

Comment 123

8 years ago
I have been under the impression that for the second round of public discussion, we're going to point folks to the translations of the draft versions of the CP and Service Description: 

http://pki.telesec.de/service/documents/T-Systems-Root-CP_en.pdf

http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-Signing_en.pdf

I believe that so far you have added:
CP section 1.3.2.1, Registration authorities for subordinated CAs
Service Description section 3, Customer’s Duties to Cooperate

I thought that we would be reviewing these drafts during the second round of public discussion, so that we can ensure that all requested changes are brought to light before the end of the discussion. Then, after completion of the discussion, the updated CP and the service description would come into force.

So do you want to add the information about the requirements of sub-CAs to verify the ownership of domain name and email address to this draft CP before we start the second round of public discussion? Or do you want me to proceed to open the second round of public discussion, leaving this item as unresolved?

Comment 124

8 years ago
Hi Kathleen,

that depends on the meaning of the term "unresolved". If you consider our statement about the insertion of such a statement as being not sufficient for the discussion we will provide a draft. But since this has to go through our Change Board we wanted to collect additional change requirements out of the discussion.

So what do you think?: Will a draft that adresses this topic give us some benefit during the discussion? If so we will need this week to deliver this Draft (Due to the process).

Regards

Wolfgang
(Assignee)

Comment 125

8 years ago
I think it's best if the draft that we post in the next round of public discussion is what you believe to be final in regards to addressing the requirements of third-party sub-CAs. The goal being to have this next round of public discussion be the final one, so we can move onto the inclusion phase.

Comment 126

8 years ago
Formally assigning this to Kathleen Wilson, since she's the person actively working on it.
Assignee: hecker → kathleen95014

Comment 127

8 years ago
Hi Kathleen,

we have put the statement about validation of domains and email adresses in the service description document (see chapter 3, third bullet).

See the current version under the following link:

http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-Signing_en.pdf

Kind regards

Wolfgang
(Assignee)

Comment 128

8 years ago
Created attachment 368040 [details]
Review of Subordinate CAs
Attachment #357193 - Attachment is obsolete: true
(Assignee)

Comment 129

8 years ago
I am now opening the second public discussion period for this request from T-Systems to add the Deutsche Telekom Root CA 2 root certificate to Mozilla.

The discussion will take place in the new 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 topic is: T-Systems Root Inclusion Request Round 2

Please actively review, respond, and contribute to the discussion.
(Assignee)

Comment 130

8 years ago
The second 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 T-Systems’ request to add the Deutsche Telekom Root CA 2 certificate to the Mozilla root store, and enable all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by T-Systems, 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]. T-Systems appears to provide a service relevant to Mozilla users: It is a subsidiary of Deutsche Telekom, based in Germany. This root certificate, Deutsche Telekom Root CA 2, has an externally-operated subordinate CA called DFN-Verein PCA Global, which is used by many of the scientific programs in Europe wide computing, storage and info-grids crossing many organizational boundaries.

The certificate policies for T-Systems are published on their website and listed in the entry on the pending applications list. T-Systems created drafts of an updated version of their CP and their service description documents in order to add information about the controls that they enforce on their externally operated subordinate CAs.   
T-Systems has committed to making these versions official.
Draft of Updated CP: 
http://pki.telesec.de/service/documents/T-Systems-Root-CP_en.pdf 
Draft of Service Description: 
http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-S... 

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

* T-Systems Service Description section 3, Customer’s Duties to Cooperate 
+ Constrains sub-CA certificate usage based on contractual agreement. 
+ T-Systems to review/approve their CP/CPS. 
+ Requires annual audit. 
+ Customer CP/CPS demonstrates that in addition to verifying the identity of individuals and organizations, reasonable measures are taken to verify that the subscriber owns/controls the domain referenced in the certificate and the email account associated with the email address referenced in the certificate.

* Draft of DFN’s (externally-operated sub-CA) CP, which has information about the domain name verification that they do. DFN has committed to making this version official. The draft is at: 
http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_DRAFT_v22-english.pdf
** Section 3.2.3: For Global security level, the subscriber must be present and must provide photo ID and passport. Proof of belonging to the organization is checked. 
** Section 3.2.2: Authentication of an organization identity: If a domain name is used in a certificate, the organization's right to use the domain name is verified by DFN-Verein as the PCA. 
** Section 3.2.3: the e-mail address must be present and checked during in-person registration. 

* The FhG (externally-operated sub-CA) has two internally-operated subordinate CAs. One sub-CA provides certification services to their own employees, and the other sub-CA issues certificates for their own machines. All FhG employees are registered within their own SIGMA system. They also maintain a central list of registered services/machines. 

Section 8-10 [Audit]. Section 8-10 [Audit].  This root, Deutsche Telekom Root CA 2, has been audited by Ernst and Young against the WebTrust CA criteria. The audit is posted on the cert.webtrust.org website, and dated December 11, 2008. T-Systems audits their externally-operated sub-CAs annually, and provided the audits for 2008 for DFN and FhG.

Section 13 [Certificate Hierarchy].  
* Underneath the Deutsche Telekom Root CA 2 is an internally-operated sub-CA for issuing certificates for qualified signatures according to the German Signature Act.
* The Deutsche Telekom Root CA 2 certificate currently has 2 subordinate CAs that are operated by third parties; one of them serving the community of the German Research Network (Deutsches Forschungsnetz, DFN), and the other issuing certificates internally to Fraunhofer Corporate PKI (FhG) employees and systems.
** DFN operates a sub-CA of the Deutsche Telekom Root CA 2 certificate, for the Global security level certificates that are described in their CP. 
** FhG operates two sub-CAs that chain up to the Deutsche Telekom Root CA 2 certificate, one issues end-entity certificates for employees, the other for machines.

Other: 
* CRL issuing frequency is controlled by the CP of each sub-CA. 
** DFN: CRLs must be generated and published at least once a month. If a certificate is revoked, a new CRL must be generated and published without delay.
** FhG: Soon as revocation occurs. At least once per week.

Potentially problematic practices: 
* This root has externally-operated subordinate CAs as described above.

Based on this assessment I recommend that Mozilla approve the request to add the Deutsche Telekom Root CA 2 root certificate to NSS and enable all three trust bits.

Comment 131

8 years ago
Kathleen,

thank you for your work on this bug!

Thorsten

Comment 132

8 years ago
Kathleen,

that's good news to us.

We will transfer the drafts into working documents now and publish them.
Since the Easter weekend with public holidays is comming now in Germany this will happen at the beginning of the next week.

Thank you for your dedication to move our request forward.

Kind regards

Wolfgang

Comment 133

8 years ago
To Kathleen: Thank you for your work on this request. I know this request in particular required a lot of additional work, and we're all grateful for your willingness to take on this task.

To the representatives of Deutsche Telekom / T-Systems: Thank you for your cooperation and your patience. I very much appreciate your willingness to work with Kathleen to provide the information we requested, and to make CP and other changes to address our concerns.

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

I have reviewed the summary and recommendation in comment #130, and on behalf of the Mozilla project I approve the request from Deutsche Telekom / T-Systems to add the following root certificate to NSS, with trust bits set as indicated:

* Deutsche Telekom Root CA 2 (email, SSL, object 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
(Assignee)

Updated

8 years ago
Depends on: 487647
(Assignee)

Comment 134

8 years ago
I have filed bug 487647 against NSS for the actual changes. 

Please post to this bug (378882)to provide the urls to the final documents when they have been made official.
Draft of Updated CP: 
http://pki.telesec.de/service/documents/T-Systems-Root-CP_en.pdf 
Draft of Service Description: 
http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-S...
DFN draft is at: 
http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_DRAFT_v22-english.pdf

Comment 135

8 years ago
Hi Kathleen,

We will provide the links until the end of the week.

Kind regards

Wolfgang Pietrus

Comment 136

8 years ago
Hi Kathleen,

find below the links to the updated (not drafts anymore) versions of the relevant documents. 

http://pki.telesec.de/service/documents/T-Systems-Root-CP_V1.5_en.pdf 
http://pki.telesec.de/service/documents/service-spec_T-Systems-Root-Signing_V1.3_en.pdf 

for CP and the service spec, which is referred in the CP.

The updated version of the DFN policy can be found at the following URL:

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_v22-english.pdf

Those policies are now active.

With that I would like to thank you, Frank and all people who worked on this request or participated in the discussion. 

We believe that the current process for evaluating root requests gives both sides (Mozilla and the requesting CAs) the opportunity to improve quality and as we all know: Quality takes its time:-)

Best regards

Wolfgang Pietrus

T-Systems
(Assignee)

Comment 137

8 years ago
Hi Wolfgang,

Thank you for following up on this. 

Would you also please provide the urls to the corresponding German versions of these documents, so I can update the pending list entry to point to equivalent documents for both German and English?
http://www.mozilla.org/projects/security/certs/pending/#T-Systems

Kathleen

Comment 138

8 years ago
Hi Kathleen,

see below the links to the German docs.

Ours (The third one is the Service Description (in German:Leistungsbeschreibung):

https://www.telesec.de/pki/service/DT_ROOT_CA_2/cp.pdf

https://www.telesec.de/pki/service/DT_ROOT_CA_2/cps.pdf

https://www.telesec.de/pki/service/DT_ROOT_CA_2/Leistungsbeschreibung_T-Systems-Root-Signing-V1.3.pdf

The DFN CP:

http://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_v22.pdf

Best regards

Wolfgang
(Assignee)

Comment 139

8 years ago
Thanks Wolfgang.
I have updated the pending list to show both the German and English versions of these documents.
http://www.mozilla.org/projects/security/certs/pending/#T-Systems

By the way, I don’t think the information about the Service Description document has been added to the German CP yet.

In the English CP, 
http://pki.telesec.de/service/documents/T-Systems-Root-CP_V1.5_en.pdf
1.3.2.1 Registration authorities for subordinated CAs 
Registration of subordinated CAs of third parties (that not belong to T-Systems and are completely under control of the T-Systems Trust Center) will be performed solely by authorized employees of the T-Systems Trust Center. Principles for contracts and registration are based on the regulations described in the service description „T-Systems Root Signing“ [TSYSROOTSIGN]. Those regulations are mandatory. The actual registration is then based on contractual regulations.

I did not find this in the German CP,
http://pki.telesec.de/service/DT_ROOT_CA_2/cp.pdf

Would you please check that the appropriate change has been propagated?

Comment 140

8 years ago
Hi Kathleen,

I will check it and initiate an update, if required. This won't take long since we already agreed about that in our change board. 

Best regards

Wolfgang

Comment 141

8 years ago
Hi Kathleen,

we have found the problem: The link you were using still pointed to the old version of the CP (This was a link to the directory where we provided all drafts and valid docs together at one location). 

The now valid version 1.5 can be found under the link I provided last week, which are the links we show on our website. We have now changed the version of the document behind the link you used also so that no other people will run into the same trouble.

Best regards

Wolfgang
(Assignee)

Comment 142

8 years ago
Thank you, Wolfgang. I see the change now in the documents that the pending page links to.
(Assignee)

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago8 years ago
Resolution: --- → FIXED

Comment 143

6 years ago
Note: This CA was singled out as a CA that signed an excessive number of intermediate authorities (252) which together only have issued 4164 certificates in EFFs talk at C3. This is, by far, the highest number, the next contender is GTE Cybertrust with 93.

http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html

Although from the data reviewed in the talk it cannot be known if the CAs are also handing out, for example, personal certificates for validating email, one could be of the opinion that this authority should not be on the trusted list because it is delegating the trust to too many parties and thus deluting the trustworthiness of the entire list, for very little practical use.

Comment 144

6 years ago
It is correct to question this, but perhaps you need to also ask about local organizations. I am an American-born professor for computer science in Germany, so I do understand a tiny bit about how Germany works. 

The Deutsche Telekom is, indeed, a serious organization. They signed the certificate for the DFN, (Deutsche Forschungsnetz, German Research Network) which is organized as a "Verein", a club, for tax purposes and because in Germany, there is no federal organization for universities. It is the job of the individual states (16 of them) to finance and organize their universities, so we have lots of fun problems when people move from one state to another, but I digress.

In turn, the universities have a lot of autonomy in organizing themselves. One of the very bright things that happened, however, was that the computer center leaders got together at a meeting in 1984 (check out the German Wikipedia: http://de.wikipedia.org/wiki/DFN) and pooled their resources, with a little money from the federal government, to get a common research network set up. I started studying in Germany in 1976 and know the chaotic situation that prevailed far too well. They set up X.25 nodes, they organized DATEX-P, they've tried out stuff that has spectacularly failed (ATM), and now they organize the Internet connections for the universities that are members. And they do it very well, indeed.

But: each university has - as universities are wont to do - approximately a gazillion independent units. Now, in the US, either the universities just self-sign all their certificates and go on their merry way, like MIT, or they purchase from someone like entrust, like UCSD. It would have been prohibitively expensive to purchase certificates for all the domains that are run at the universities (and we do not take tuition, so we are permanently strapped for cash, not being able to increase tuition to cover these expenses). 

So the solution was: Deutsche Telekom signs DFN, DFN signs each of the computer centers, they sign internally. They enforce VERY STRICT rules about who can sign what how. The rules are so strict, it is not enough for me to write "Hey, I'm big honcho dean, sign me a certificate!" No, I have to move physically to the center, show my ID, fill out twenty forms or so, and then get my certificate. I know, I tried to pull rank and failed ;)

This means that any attempt to set up easy-to-use certificate systems fails, because everyone has to go and identify themselves, which is a good thing, I suppose. This is Germany, the rules are indeed followed.

I attended the same talk at the 27C3, and I was more shocked to hear that Firefox trusts 14.000 CA, many who are not listed when I try and look at the list. Maybe we need an easier way to see who, indeed, has signed what, and which CAs I choose when installing the system. I don't need TÜRKTRUST or BuyPass or Unizeto - so either we have all the serious CAs built in, on none. 

I would strongly suggest that Mozilla find some other way of setting up the default trusted CAs, but as long as we still have this system, then Deutsche Telekom belongs in, and believe me, they *are* trustworthy.
(Assignee)

Comment 145

6 years ago
> and I was more shocked to hear that
> Firefox trusts 14.000 CA

The exact statement is: "1,482 CAs trustable by Microsoft or Mozilla"

This obviously includes all sub-CAs chaining up to roots that are included in Mozilla's and Microsoft's root stores.

Anyways, if further discussion is needed, please post in mozilla.dev.security.policy rather than in this bug.
You need to log in before you can comment on or make changes to this bug.