Request for additional D-Trust root Integration with trust bit "email" (Non-TLS).

RESOLVED FIXED

Status

task
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: browser-ca, Assigned: kwilson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Added in NSS 3.30.2, Firefox 54 and NSS 3.28.5, ESR 52.2)

Attachments

(9 attachments, 4 obsolete attachments)

595.99 KB, application/pdf
browser-ca
: review+
Details
619.75 KB, application/pdf
browser-ca
: review+
Details
148.42 KB, application/x-download
Details
72.87 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
3.64 MB, application/x-zip-compressed
Details
64.60 KB, application/pdf
browser-ca
: review+
browser-ca
: feedback+
Details
3.61 KB, application/x-zip-compressed
browser-ca
: review+
browser-ca
: feedback+
Details
448.80 KB, application/pdf
Details
153.07 KB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; rv:11.0) like Gecko

Steps to reproduce:

In Europe we want to promote the use of signed and encrypted email. D-Trust is offering different types of certificates for this use case: Personal, Team and Device IDs.


Actual results:

Signed emails using D-Trust certificates are categorized as not trusted.


Expected results:

D-Trust should be accepted as trustworthy also for signing email. Therefore the new root "D-TRUST Root CA 3 2013" should get the trustbit "email" and be integrated in Mozilla's rootstore. Two sub-CAs belong to this root at this Point: D-TRUST Application Certificates CA 3-1 2013" and "E.ON Group CA 2 2013". Both are already audited by TuevIT based on ETSI TS102042.
Assignee: nobody → nobody
Component: Untriaged → CA Certificates
Product: Firefox → NSS
Version: unspecified → trunk
Assignee: nobody → kwilson
OS: Unspecified → All
Product: NSS → mozilla.org
Hardware: Unspecified → All
Version: trunk → other
Please provide more of the information listed here: https://wiki.mozilla.org/CA:Information_checklist
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I was just looking at https://www.bundesdruckerei.de/de/2826-d-trust-roots to find the D-TRUST Root CA 3 2013 root, and noticed there are many other root certs too.

Please look at the D-Trust roots that are currently included
https://wiki.mozilla.org/CA:IncludedCAs
and update this bug to indicate which other D-Trust roots we should consider adding at the same time.
I have entered the information I have verified so far into Salesforce.

Please scan the attached document for the word "NEED" to see what information still needs to be provided. Provide the requested information and any corrections by posting comments in this bug.
Hopefully it convinces the Mozilla Community to accept a additional Root with the eMail Trust Bit. The Microsoft Rootstore inclusion happened in 2014. Please contact us, if there is any question, we´ll do our very best to fullfill all the complex requirements
requested docs and examples for D-TRUST Root CA 3 2013
D-TRUST Response to Mozilla's list of Recommended Practices as *.pdf for inclusion of the D-TRUST Root CA 3 2013 with Trustbit "eMail"
Attachment #8723651 - Flags: review+
Attachment #8723651 - Flags: feedback+
Posted file exampleCert.cert (obsolete) —
Attachment #8728094 - Attachment is obsolete: true
Please directly attach to this bug an example S/MIME cert that I can view via 
http://cert-checker.allizom.org/graph/certsplainer/
(In reply to Kathleen Wilson from comment #10)
> Please directly attach to this bug an example S/MIME cert that I can view
> via 
> http://cert-checker.allizom.org/graph/certsplainer/

That chains up to the 'D-TRUST Root CA 3 2013' root cert.
https://www.bundesdruckerei.de/de/2833-repository ...

Certification Practice Statement of the D-TRUST Root PKI:
https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-trust_root_pki_cps_v1.14_en.pdf

Certification Practice Statement der D-TRUST CSM PKI:
https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-trust_csm_pki_cps_v1.2_en.pdf

I don't understand why there are two CPS documents. What is CSM?
Posted file E.ON_SE_CP_EN.pdf (obsolete) —
Posted file Uniper_CP_EN.pdf (obsolete) —
Attachment #8728132 - Attachment is obsolete: true
Attachment #8728134 - Attachment is obsolete: true
To support a better audit practise D-TRUST has decided to develop one CPS for the "standard" issuing process managed within the CSM-System, please see 
https://www.bundesdruckerei.de/en/812-certificate-service-manager
all other issuing processes are covered by the generic CPS.
Please see d-trust_root_pki_cps_v1.14_en.pdf

(In reply to Kathleen Wilson from comment #12)
> https://www.bundesdruckerei.de/de/2833-repository ...
> 
> Certification Practice Statement of the D-TRUST Root PKI:
> https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-
> trust_root_pki_cps_v1.14_en.pdf
> 
> Certification Practice Statement der D-TRUST CSM PKI:
> https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-
> trust_csm_pki_cps_v1.2_en.pdf
> 
> I don't understand why there are two CPS documents. What is CSM?
Please give feedback
Attachment #8730195 - Flags: review+
Attachment #8730195 - Flags: feedback+
Posted file 1166723-CAInformation-Complete.pdf (obsolete) —
This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.
Whiteboard: Ready for Public Discussion
Arno, my notes about this root cert currently say the following. Is this correct/current?
~~
The root “D-TRUST Root CA 3 2013” has three internally-operated subCAs:
1) D-TRUST Application Certificates CA 3-1 2013
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6768UE_s.pdf
2) E.ON Group CA 2 2013
-- www.eon.com/pki
-- CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8728132
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6764UE_s.pdf
3) UNIPER Group CA 2 2015
-- www.uniper.energy/pki
-- CP (English): https://www.uniper.energy/static/download/files/UNIPER_CP.pdf
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6769UE_s.pdf

“UNIPER” is a new subsidiary and brand of “E.ON”, so it was decided to have two identical CA-Infrastructures with identical CP/CPS Procedures in parallel.
~~
Kathleen, your notes are correct
On 22/11/2016 we created from "D-TRUST Root CA 3 2013" a new internally-operated sub-CA, 
----
4.) D-TRUST Application Certificates CA 3-2 2016
----
there was a full Audit by TÜVIT in December 2016, we expect the Audit Report and the CP latest Mid of January 2017. 
The CA will not be used for issuing EE-Certs before Audit and CP are published.
Attachment #8734068 - Attachment is obsolete: true
I am now opening the public discussion period for this request from D-TRUST to included the ‘D-TRUST Root CA 3 2013’ root certificate and enable the Email trust bit.

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Include Additional D-TRUST root certificate".

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

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Ready for Public Discussion → In Public Discussion
The public comment period for this request is now over.

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

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#inclusion

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

Inclusion Policy 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.

Inclusion Policy Section 6 [Relevance and Policy].
D-TRUST appears to provide a service relevant to Mozilla users. D-TRUST GmbH is a subsidiary of Bundesdruckerei GmbH and is fully owned by the German State. In Europe D-TRUST wants to promote the use of signed and encrypted email by offering different types of certificates for this use case: Personal, Team and Device IDs. D-Trust operates subordinate CAs for Trusted Service Providers (TSPs), who do the identity and email address verification and issue the end entity certificates directly. The TSPs provide public-facing policy documentation, and are audited by TUVIT.
 
Root Certificate Name: D-TRUST Root CA 3 2013
O From Issuer Field: D-Trust GmbH
Trust Bits: Email
EV Policy OID: Not EV
Root Certificate Download URL: http://www.d-trust.net/cgi-bin/D-TRUST_Root_CA_3_2013.crt

* The primary documents, the CP and CPS, and are provided in both German and English. 

Document Repository: https://www.bundesdruckerei.de/de/2833-repository
CP v2.2 (German): http://www.d-trust.net/internet/files/D-TRUST_CP.pdf
CP v2.1 (English): https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-trust_cp_v2.1_en.pdf
CPS v1.15 (German): http://www.d-trust.net/internet/files/D-TRUST_Root_PKI_CPS.pdf
CPS v 1.14 (English): https://www.bundesdruckerei.de/sites/default/files/documents/2016/01/d-trust_root_pki_cps_v1.14_en.pdf

Certificate Revocation
* CRL URLs:
http://pki.intranet.eon.com/crls/EON_Group_CA_2_2013.crl
http://crl.d-trust.net/crl/eon_group_ca_2_2013.crl
CPS and CSM CPS section 2.3: Certificate revocation lists are published immediately following revocations. Even if no certificates were revoked, the TSP ensures that a new certificate revocation list is created at least every 24 hours.

* OCSP URLs
http://eon-ca-2-2013-xxi.ocsp.d-trust.net
CPS and CSM CPS section 4.10: The status query service is available via the OCSP protocol. The availability of the service is indicated as a URL in the certificates. 

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

* SSL Verification Procedures: 	Not Applicable. Not requesting the Websites trust bit for this root.

* Email Verification Procedures: 
* CPS section 4.2.1: The identification and registration process described herein must be carried out completely on a class-specific basis and all the proof necessary must be provided.
Individuals or organisations can be authenticated and further certificate-relevant data verified before or after submission of the application, but must be completed before certificates and key material, if any, and PINs are handed over.
Class 3, Class 2
Individuals must be unambiguously identified; in addition to the full name, further attributes (such as place and date of birth or other applicable individual parameters) must be used to prevent individuals from being mistaken. If legal entities are named in the certificate or if legal entities are subscribers, the complete name and legal status as well as relevant register information must be verified.
The TSP defines the following verification methods:
<snip>
Domain
The domain of an organisation and, if applicable, other attributes, such as e-mail addresses, are verified by a domain query in official registers (WHOIS). Class 3 and Class 2: In this case, it is questioned whether the subscriber has exclusive control of the domain. The results of the enquiry are filed. In the case of EV certificates, the domain name is additionally checked against blacklists of known phishing domains. Domain names not subject to a registration obligation (no toplevel domains) are not permitted.
E-mail
The TSP sends an e-mail to the e-mail address to be confirmed, and receipt of this e-mail must be confirmed (exchange of secrets). The results of the enquiry are filed.


Audit (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#requirements)
Annual audits are performed by TUVIT, according to the ETSI EN 319 411 criteria.
https://www.tuvit.de/data/content_data/tuevit_en/6768UE_s.pdf
https://bug1166723.bmoattachments.org/attachment.cgi?id=8813743	

Certificate Hierarchy
The root “D-TRUST Root CA 3 2013” currently has four internally-operated subCAs:
1) D-TRUST Application Certificates CA 3-1 2013
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6768UE_s.pdf
2) E.ON Group CA 2 2013
-- www.eon.com/pki
-- CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8728132
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6764UE_s.pdf
3) UNIPER Group CA 2 2015
-- www.uniper.energy/pki
-- CP (English): https://www.uniper.energy/static/download/files/UNIPER_CP.pdf
-- Audit: https://www.tuvit.de/data/content_data/tuevit_en/6769UE_s.pdf
“UNIPER” is a new subsidiary and brand of “E.ON”, so it was decided to have two identical CA-Infrastructures with identical CP/CPS Procedures in parallel.
4) D-TRUST Application Certificates CA 3-2 2016
This will not be used for issuing EE-Certs before Audit and CP are published.
Externally Operated SubCAs: All SUB-CAs of this Root are D-TRUST internally operated subCAs: and under full control and audit.
Cross Signing: No cross-certs existing. Cross-certs are prohibited by Policy. Only direct trust structures.

Potentially Problematic Practices: (http://wiki.mozilla.org/CA:Problematic_Practices)
* Email address verification is delegated to third parties. D-Trust has Trusted Service Providers, and they are required to provide public-facing policy documentation and are audited by TUVIT. (see details above).

Based on this assessment I intend to approve this request from D-TRUST to include the D-TRUST Root CA 3 2013 root certificate and enable the Email trust bit.
Whiteboard: In Public Discussion → Pending Approval
As per the summary in Comment #26, and on behalf of Mozilla I approve this request from D-TRUST to include the following root certificate:

** "D-TRUST Root CA 3 2013" (email)

I will file the NSS bug for the approved change.
Whiteboard: Pending Approval → Approved, Pending NSS Changes
Depends on: 1348132
I have filed bug #1348132 against NSS for the actual change.
Whiteboard: Approved, Pending NSS Changes → [ca-approved] - Pending NSS Changes
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - Pending NSS Changes → Added in NSS 3.30.2, Firefox 54 and NSS 3.28.5, ESR 52.2
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.