110.97 KB, application/pdf
522.26 KB, application/pdf
28.50 KB, application/octet-stream
107.36 KB, application/pdf
224.56 KB, application/pdf
555.01 KB, application/pdf
554.38 KB, application/pdf
107.58 KB, application/pdf
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:220.127.116.11) 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.
Created attachment 351344 [details] Enclosed please find further information requested by the CA-information checklist on wiki.mozilla.org
Off the UNCO radar.
Created attachment 358820 [details] Request information in XLS format
Accepting this bug so we can begin the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.
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?
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
Created attachment 361775 [details] CPS English version
Created attachment 361782 [details] Request information in XLS format_2009-0211 changed or added: 2.11 - 2.13 2.21
Created attachment 361898 [details] 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?
There has been no activity in this bug for over a year. Is this request obsolete?
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
Created attachment 448719 [details] 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
Please update summary to indicate the names of the certificate authority and the affected certificates.
Created attachment 451776 [details] 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.
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.
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.
(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?
Created attachment 550068 [details] 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".
Created attachment 550089 [details] request information update Update on OSCP update cycles, auditing information including recent links to latest audit reports(ETSI now).
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?
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
And no cross-certificates have been issued.
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
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
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.
(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.
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
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
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
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
Created attachment 652381 [details] ETSI TS 102 042 V2.21, policy NCP - D-TRUST Root Class 3 CA2 2009 Audit Summary / Certificate
Created attachment 652382 [details] ETSI TS 102 042 V2.21, policy EVCP - D-TRUST Root Class 3 CA2 EV 2009 Audit summary / certificate
Created attachment 664275 [details] Completed Information Gathering Document Updated as per current CPS and audits.
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 email@example.com 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.
(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.
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: 18.104.22.168.4.1.4722.214.171.124 * 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.
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
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/
(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.
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.
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
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.