467891 - Add "D-TRUST Root Class 3 CA 2 2009" and "D-TRUST Root Class 3 CA 2 EV 2009"

Status: RESOLVED FIXED

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

Description

[Arno Fiedler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Firefox v3.0.4, German

The user stays on the URL he wants to visit, but will get a content-free error page, that is explaining the fact, that there is a problem with the securty certificate used on this side since the issuer is unknown. He has now the chance to add an exception to visit this side or to stop his side visit.

Reproducible: Always

Steps to Reproduce:
1. Use any kind of client with the firefox browser, that has not installed the root manually before
2. Visit https://ssl.d-trust.net
Actual Results:  
The user stays on the URL he wants to visit, but will get a content-free error page, that is explaining the fact, that there is a problem with the securty certificate used on this side since the issuer is unknown. He has now the chance to add an exception to visit this side or to stop his side visit.

Expected Results:  
Our goal as a Trustcenmter and CA is of course to have none-stop site visit on any website on the internet for the endusers.

Comment 1

[Arno Fiedler]

Attachment: Enclosed please find further information requested by the CA-information checklist on wiki.mozilla.org

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Normalizing summary

Comment 3

[Frank Wein [:mcsmurf]]

Off the UNCO radar.

Comment 4

[Arno Fiedler]

Attachment: Request information in XLS format

Comment 5

[Kathleen Wilson]

Accepting this bug so we can begin the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.

Comment 6

[Kathleen Wilson]

Thank you for submitting such thorough information.

In regards to the CP/CPS your response said: 
“English Versions: will be submitted soon”.
Do you still plan on providing an English version of the CP or CPS? 
One (CPS?) is probably sufficient -- the one that provides the most detail about the steps taken to verify identity/organization, ownership of domain, and ownership of email address of the end-entity certificate subscriber.

I need to find text in the CP, CPS, or other official document that describes how the identity of the individual and/or organization are verified, and satisfies section 7 of http://www.mozilla.org/projects/security/certs/policy/ in regards to domain name and email address owernship verification.

Can you provide an HTTP URL (not ldap) for the full CRL for the SSL sub-CA?

Please review the potentially problematic practices documented at http://wiki.mozilla.org/CA:Problematic_Practices, and comment as to whether any of these are relevant.
If relevant, please provide further information.

I'm having difficulty testing the OCSP responder urls. Does the OCSP signer chain up to this root?

Comment 7

[Arno Fiedler]

Hi Kathleen, 

as an attachment to this bug you can find now the recent English version of our CPS and as well the recent xls file updated from 2.11 (SSL) to 2.13 (E-Mail /Code). Please let us know if this is fine. More detailed are of course our internal process instructions what we just have in German.

Public HTTP URL (not ldap) for the full CRL for the SSL sub-CA: http://www.d-trust.net/crl/d-trust_service_class_3_ca_1_2008.crl

It should chain up successfully to the same root. What kind of difficulties do you have in detail with the OSCP responder, how did you test them? 

Frank

Comment 8

[Arno Fiedler]

Attachment: Request information in XLS format_2009-0211

Comment 9

[Arno Fiedler]

Attachment: CPS English version

Comment 10

[Arno Fiedler]

Attachment: Request information in XLS format_2009-0211

changed or added:
2.11 - 2.13
2.21

Comment 11

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the Initial Information Gathering Document which summarizes the information that has been gathered and verified. Please review for accuracy and completeness.

I have also added an entry for this request in the pending list
(there may be a slight delay before the changes are visible)
http://www.mozilla.org/projects/security/certs/pending/
Please review this information for this entry and provide feedback/corrections.

Within the attached document the items that are highlighted in yellow indicate the information that needs to be clarified or provided. I will also summarize below.

1) Is the CRL that you provided PEM encoded instead of DER encoded? Please see if you can download the CRL into Firefox.

2) I am able to connect to https://ssl.d-trust.net in Firefox when I don’t have OCSP enforced. However, when I change the validation setting to use this root and fail if OCSP fails, I get an error. Would you please try this?

3) CPS section 6.3.2 indicates that the maximum validity period for class 3 certs is 5 years. Are the SSL-certs valid for 5 years?

Comment 12

[Kathleen Wilson]

There has been no activity in this bug for over a year.

Is this request obsolete?

Comment 13

[Arno Fiedler]

Hi Kathleen, we have set up new roots we're going to submit and expect the recent certification this months. We will then update our bug. Frank

Comment 14

[Arno Fiedler]

Attachment: request information update on root CA integration

Hi Kathleen, enclosed please find new request information for our now recent root CA certs - those should work now also correctly with OCSP. So the title "D-TRUST Root Class 3 CA 2007" of this bug is no longer correct since we do not would get this Root into Mozilla's root certificate store, but the two other ones the xls sheet is referring to instead. Cheers, Frank

Comment 15

[Arno Fiedler]

Attachment: CPS V1.3 English

Comment 16

[David E. Ross]

Please update summary to indicate the names of the certificate authority and the affected certificates.

Comment 17

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

I have attached a new Initial Information Gathering Document, to reflect the new roots and new information that has been provided.

Please review the full document for accuracy and completeness. The items highlighted in yellow indicate where further information or clarification is needed.

Comment 18

[Arno Fiedler]

We fixed the CRL issue. Can you please try again and confirm this? 

The more detailed description in our CPS on how to verify domain name ownership or exclusive rigth to use and acknowledgement of it's registration will follow.

Comment 19

[Kathleen Wilson]

I have successfully imported these CRLs into my Firefox browser, without error
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_2009.crl
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_ev_2009.crl

Note that while testing, I ran into an intermittent issue. I have OCSP enforced in my Firefox browser, and I browsed to 
https://extranet.d-trust.net 
and 
https://ssl-test-ev.d-trust.net
and I for both sites I got the error: sec_error_ocsp_unauthorized_response
(See https://wiki.mozilla.org/CA:Recommended_Practices#OCSP)

However, I went on to do some other testing, then cleared my cache again, and browsed successfully to the two test websites (no OCSP error, even though I have OCSP enforced). Now I can’t reproduce the problem.

Comment 20

[Kathleen Wilson]

(In reply to comment #18)
> The more detailed description in our CPS on how to verify domain name
> ownership or exclusive rigth to use and acknowledgement of it's registration
> will follow.


Any update on this and the rest if the highlighted items in the Initial Information Gathering Document?

Comment 21

[Arno Fiedler]

Attachment: Recent Version of our CPS V1.5

Page 23, Paragraph 4.2.1 explains how domain authentication is done and shows that D-TRUST is no longer offering so called "Intranet Certs".

Comment 22

[Arno Fiedler]

Attachment: request information update

Update on OSCP update cycles, auditing information including recent links to latest audit reports(ETSI now).

Comment 23

[Kathleen Wilson]

Thank you for the updates. I have a few more question...

1) What is the maximum expiration time of OCSP responses?

2) It looks like the maximum validity period for OV SSL certs is 5 years.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
section 6: "We require that all CAs whose certificates are distributed with our software products: ... verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less;"

3) Can an RA perform the verification for the ownership/control of the domain name to be included in the certificate? Also, Can an RA directly cause the issuance of an SSL certificate?

4) Can SSL certs be issued for private IP addresses or internal domains?

Comment 24

[Arno Fiedler]

Hi Kathleen, thanks for your feed back.

Here are the answers:

1) Our responder just gives real time certificate status answers, we do not practise OCSP stapeling or similar - so, expiration time is immediately after response.

2) I have canceled the 5-year-option as a product for all of our SSL certs under the respective roots. The changes are already reflected on the enrollment page. Our CP / CPS and product sheets will be adopted within 1 week.

3) No RA can perform validation / verification procedures under these roots.

4) We are not offering SSL certs for IP addresses or internal domain names.

Cheers,
Frank

Comment 25

[Arno Fiedler]

And no cross-certificates have been issued.

Comment 26

[Kathleen Wilson]

Thanks for the updates.  Please post a comment here when the CP/CPS have been updated on your website.

Please review the CA Communication that was sent on September 8, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 27

[Arno Fiedler]

Hi Kathleen,

the recent CP / CPS in V1.5 are online at http://ssl.d-trust.net/support/repository.php available.

Regarding your last comments we have are bit unsure about what is ment in paragraph 4.) CA:Communications "Confirm that you have automatic blocks ...". Would it be sufficient to integrate an standard block on our production system for all SSL requests, that includes a further task/step on our electronic checklist? The validation officer needs to check than the domain name included in the CN against this list. If the name is not on this list, than he/she needs to set the checkbox for this task on "checked". If this checkbox stays "unchecked" the request would stay pending and cannot be processed. If there is a positive finding on the list, the request will be forwarded as a potential security event to a separate production role "quality management" and potentially "security officer". 
Would that be ok?

Thank, Frank

Comment 28

[Arno Fiedler]

And additionally to the CA:Communicatons task list the last remaining question to answer was: 1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs. 

Besides the tests that the auditors are doing on a yearly basis, we do have of course a Intrusion Detection / Prevention & Firewall system in place. Furthermore we have a software that is also continously monitoring the integrity of our files & data bases.

Comment 29

[Kathleen Wilson]

(In reply to browser-ca from comment #27)

Hi Frank,

I apologize for the delay in my response. I'm still trying to catch up from holidays.

> the recent CP / CPS in V1.5 are online at
> http://ssl.d-trust.net/support/repository.php available.

I will download the updated versions.

> Regarding your last comments we have are bit unsure about what is ment in
> paragraph 4.) CA:Communications "Confirm that you have automatic blocks
> ...". Would it be sufficient to integrate an standard block on our
> production system for all SSL requests, that includes a further task/step on
> our electronic checklist? The validation officer needs to check than the
> domain name included in the CN against this list. If the name is not on this
> list, than he/she needs to set the checkbox for this task on "checked". If
> this checkbox stays "unchecked" the request would stay pending and cannot be
> processed. If there is a positive finding on the list, the request will be
> forwarded as a potential security event to a separate production role
> "quality management" and potentially "security officer". 
> Would that be ok?

Yes, I believe so. Other CAs also responded to action #4 by saying that they have no automated cert issuance -- all their SSL cert approval and issuance is manual. I believe that the concern that #4 was meant to address can be met with the combination of multi-factor auth (action #3) and having no automated cert issuance.

Comment 30

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 31

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 32

[Arno Fiedler]

Hi Kathleen,

the last CPS Version was actually 1.6. The website update was one version behind unfortunately. But it's there now at http://www.d-trust.net/internet/files/D-TRUST_Root_PKI_CPS-EN.pdf.

In addition we have passed a new ETSI audit for both roots. I'll let you know as soon as we got the official certificate. It shouldn't take more than 6 weeks - so we are "renewed" in time.

Frank

Comment 33

[Arno Fiedler]

Hi Kathleen,
yesterday we have updated our Root-CA test websites and also setup one for the OV-Root. The direct links are:
EV valid - https://certdemo-ev-valid.ssl.d-trust.net
EV expired - https://certdemo-ev-expired.ssl.d-trust.net
EV revoked - https://certdemo-ev-revoked.ssl.d-trust.net
OV valid - https://certdemo-ov-valid.ssl.d-trust.net
OV expired - https://certdemo-ov-expired.ssl.d-trust.net
OV revoked - https://certdemo-ov-revoked.ssl.d-trust.net

Frank

Comment 34

[Arno Fiedler]

Hi Kathleen, 
enclosed please find the pre-confirmation of our auditor, that we have successfully passed the recent audit. The final certificate should be issued in the nex weeks. They're just low on ressources at the moment.

Cheers,
Frank

Comment 35

[Arno Fiedler]

Attachment: ETSI confirmation

Comment 36

[Arno Fiedler]

Attachment: ETSI TS 102 042 V2.21, policy NCP - D-TRUST Root Class 3 CA2 2009

Audit Summary / Certificate

Comment 37

[Arno Fiedler]

Attachment: ETSI TS 102 042 V2.21, policy EVCP - D-TRUST Root Class 3 CA2 EV 2009

Audit summary / certificate

Comment 38

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated as per current CPS and audits.

Comment 39

[Kathleen Wilson]

I am now opening the first public discussion period for this request from D-TRUST to add the “D-TRUST Root Class 3 CA 2 2009” and “D-TRUST Root Class 3 CA 2 EV 2009” root certificates. The request is to turn on the Websites trust bit for both root certs, and to enable EV for the “D-TRUST Root Class 3 CA 2 EV 2009” root cert.

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

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

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

The discussion thread is called “D-TRUST Root Inclusion Request”

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

A representative of D-TRUST must promptly respond directly in the discussion thread to all questions that are posted.

Comment 40

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #39)
> 
> The discussion thread is called “D-TRUST Root Inclusion Request”
> 
> Please actively review, respond, and contribute to the discussion.
> 
> A representative of D-TRUST must promptly respond directly in the discussion
> thread to all questions that are posted.


There are questions in the discussion thread that are awaiting prompt response from a representative of D-TRUST.

Comment 41

[Kathleen Wilson]

The public comment period for this request is now over. 

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

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

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

To summarize, this assessment is for the request to add the “D-TRUST Root Class 3 CA 2 2009” and “D-TRUST Root Class 3 CA 2 EV 2009” root certificates, turn on the Websites trust bit for both root certs, and enable EV for the “D-TRUST Root Class 3 CA 2 EV 2009” root cert.

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

Section 6 [Relevance and Policy]. D-TRUST appears to provide a service relevant to Mozilla users. It is a wholly owned subsidiary of Bundesdruckerei and is the only German trust center authorised to perform sovereign tasks. The development and marketing of high-security products for the electronic signature are carried out in Bundesdruckerei's high-security value printing building. The primary market is the German speaking area (Austria, Germany, Switzerland) and B2B focused.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest CP and CPS, which are translated into English.

Document Repository: http://ssl.d-trust.net/support/repository.php
http://www.d-trust.net/internet/files/D-TRUST_Root_PKI_CPS-EN.pdf
http://www.d-trust.net/internet/files/D-TRUST_Root_PKI_CP-EN.pdf 

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

* SSL: According to CPS section 4.2.1, an organization’s domain is verified by a domain-enquiry in the official registers (WHOIS). It is questioned whether the subscriber has the exclusive control of the domain. The findings are documented. Domains that are not subject to registration are not allowed.

* Email: Not applicable. Not requesting the email trust bit.

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

Section 15 [Certificate Hierarchy]. 
The “D-TRUST Root Class 3 CA 2 2009” root currently has one internally-operated subordinate CA, “D-TRUST SSL Class 3 CA 1 2009”, which signs end-entity certificates.
The “D-TRUST Root Class 3 CA 2 EV 2009” root currently has one internally-operated subordinate CA, “D-TRUST SSL Class 3 CA 1 EV 2009”, which signs end-entity certificates.

* EV Policy OID: 1.3.6.1.4.1.4788.2.202.1

* CRL 
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_2009.crl
http://www.d-trust.net/crl/d-trust_root_class_3_ca_2_ev_2009.crl
NextUpdate: 7 days
CPS section 2.3: Even if no revocation has occurred in the meantime, the CSP publishes a new CRL every day.

* OCSP
http://root-c3-ca2-2009.ocsp.d-trust.net
http://ssl-c3-ca1-2009.ocsp.d-trust.net
http://root-c3-ca2-ev-2009.ocsp.d-trust.net
http://ssl-c3-ca1-ev-2009.ocsp.d-trust.net
Comment #24: “Our responder just gives real time certificate status answers, we do not practice OCSP stapeling or similar - so, expiration time is immediately after response.”

Sections 9-11 [Audit]. 
Audits are performed against the ETSI TS 102 042 criteria by TUVIT, and the ETSI certificates are posted on the TUVIT website.
https://www.tuvit.de/en/certification-overview-1265_trusted-site-etsi-certificates-1334_ENX_HTML.htm
Annual surveillance audits are performed by TUVIT, and the ETSI certificates are updated annually to reflect this.
https://www.tuvit.de/data/content_data/tuevit_en/6719UE_s.pdf  
https://www.tuvit.de/data/content_data/tuevit_en/6720UE_s.pdf  (EV)

Based on this assessment I intend to approve this request to add the “D-TRUST Root Class 3 CA 2 2009” and “D-TRUST Root Class 3 CA 2 EV 2009” root certificates, turn on the Websites trust bit for both root certs, and enable EV for the “D-TRUST Root Class 3 CA 2 EV 2009” root cert.

Comment 42

[Kathleen Wilson]

Please add a comment to this bug to provide your response to the action items listed in the CA Communication that was sent today, and is available here:
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

Comment 43

[Arno Fiedler]

Hi Kathleen,
here's our statement. 
Cheers,
Frank

1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations. 
ANSWER:
a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy. 

2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.
ANSWER:
a) Our CA operations conform to the latest Version CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit by TÜV-IT will include verification of this conformance. 

3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.
•	All certificates with basicConstraints: CA=TRUE have the basicConstraints marked critical. 
•	All intermediate certificates with basicConstraints: CA=TRUE have CRL-DistributionPoints containing a well-formed and compliant URL that returns a valid CRL. 
•	All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration). 
•	All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013. 
•	Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.
ANSWER:
a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices. 

4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.
ANSWER:
a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names. 

5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. 
ANSWER:
EV: https://certdemo-ev-valid.ssl.d-trust.net/
OV: https://certdemo-ov-valid.ssl.d-trust.net/

Comment 44

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #41)
> Based on this assessment I intend to approve this request to add the
> “D-TRUST Root Class 3 CA 2 2009” and “D-TRUST Root Class 3 CA 2 EV 2009”
> root certificates, turn on the Websites trust bit for both root certs, and
> enable EV for the “D-TRUST Root Class 3 CA 2 EV 2009” root cert.

To the representatives of D-TRUST: Thank you for your cooperation and your patience.

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

As per the summary in Comment #41, and on behalf of Mozilla I approve this request from D-TRUST to include the following root certificates:

** “D-TRUST Root Class 3 CA 2 2009” (websites).

** “D-TRUST Root Class 3 CA 2 EV 2009” (websites), enable EV.

I will file the NSS and PSM bugs for the approved changes.

Comment 45

[Kathleen Wilson]

I have filed bug #845132 against NSS and bug #845149 against PSM for the actual changes.

Comment 46

[Arno Fiedler]

D-TRUST is not issuing SSL certificates containing a Reserved IP Address or Internal Server Name today, but reserves the right to so upon customer requests observing the expiry date limitation of November 2015 as per BR #9.2.1.

Comment 47

[Arno Fiedler]

Our recent ETSI certificates can be downloaded at 

a) EV https://www.tuvit.de/data/content_data/tuevit_en/6720UE_s.pdf
b) OV https://www.tuvit.de/data/content_data/tuevit_en/6719UE_s.pdf

Comment 48

[Kathleen Wilson]

Hey folks, No one from D-TRUST has responded to the recent CA Communication.
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014

Please respond ASAP. Either respond in this bug, or send me email.