Include Additional D-TRUST root certificate

[Kathleen Wilson]

This request from D-TRUST is to included the ‘D-TRUST Root CA 3 2013’ root certificate and enable the Email trust bit.

D-TRUST GmbH is a subsidiary of Bundesdruckerei GmbH and is fully owned by the German State. D-TRUST currently has two root certificates included in Mozilla’s program. The ‘D-TRUST Root Class 3 CA 2 2009’ and ‘D-TRUST Root Class 3 CA 2 EV 2009’ root certificates are currently enabled with the Websites trust bit, and were included via Bugzilla bug #467891. In Europe D-TRUST wants to promote the use of signed and encrypted email, so D-Trust is offering different types of certificates for this use case: Personal, Team and Device IDs.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1166723

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8820825

* 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

* CA Hierarchy: All SUB-CAs of this Root are D-TRUST internally operated subCAs and under full control and audit. 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.
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
There was a full Audit by TÜVIT in December 2016, we expect the Audit Report and the CP latest Mid of January 2017. This will not be used for issuing EE-Certs before Audit and CP are published.

* This request is to turn on the Email trust bit only.

** 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.

* EV Policy OID: Not Requesting EV treatment. Not requesting Websites trust bit.

* Example Cert: https://bugzilla.mozilla.org/attachment.cgi?id=8730195

* 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.


* Audit: Annual audits are performed by TUVIT according to the ETSI EN 319 411 audit criteria.
https://www.tuvit.de/data/content_data/tuevit_en/6768UE_s.pdf
https://bug1166723.bmoattachments.org/attachment.cgi?id=8813743


* 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.

This begins the discussion of the request from D-TRUST to included the ‘D-TRUST Root CA 3 2013’ root certificate and enable the Email trust bit. At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then an additional discussion may be needed as follow-up. If there are no outstanding issues, then I will recommend approval of this request in the bug.

Kathleen

[Kathleen Wilson]

Does anyone have any comments or questions regarding this request from D-TRUST to included the ‘D-TRUST Root CA 3 2013’ root certificate and enable the Email trust bit?

Kathleen

[Hanno Böck]

On Wed, 25 Jan 2017 10:54:10 -0800 (PST)
Kathleen Wilson <kwi...@mozilla.com> wrote:

> Does anyone have any comments or questions regarding this request

> from D-TRUST to included the ‘D-TRUST Root CA 3 2013’ root

> certificate and enable the Email trust bit?

I just looked at their CRL:
Issuer: /C=DE/O=D-Trust GmbH/CN=D-TRUST Root CA 3 2013
Last Update: Sep 12 10:13:03 2016 GMT
Next Update: Sep 14 10:12:03 2017 GMT

This seems highly unusual to only update the CRL once a year.

This seems to violate the mozilla policy:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
"CRLs must be updated and reissued at least every seven days, and the
value of the nextUpdate field shall not be more than ten days beyond
the value of the thisUpdate field; or"


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Jürgen Brauckmann]

Hanno Böck schrieb:

> I just looked at their CRL:
> Issuer: /C=DE/O=D-Trust GmbH/CN=D-TRUST Root CA 3 2013
> Last Update: Sep 12 10:13:03 2016 GMT
> Next Update: Sep 14 10:12:03 2017 GMT
>
> This seems highly unusual to only update the CRL once a year.

It's highly normal for Root CRLs to be issued in far longer intervalls
than CRLs for end-entity-issuing CAs. As CA revocations are currently
mostly propagated by OneCRL, disallowed.stl or CRLset, thats fine.

> This seems to violate the mozilla policy:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> "CRLs must be updated and reissued at least every seven days, and the
> value of the nextUpdate field shall not be more than ten days beyond
> the value of the thisUpdate field; or"

Just above the paragraph you quoted the policy says:

"For end-entity certificates:

CRLs must be updated and reissued at least every seven days,[...]"


Regards,
Jürgen

[Kathleen Wilson]

On Wednesday, December 21, 2016 at 11:03:18 AM UTC-8, Kathleen Wilson wrote:
> This request from D-TRUST is to included the ‘D-TRUST Root CA 3 2013’ root certificate and enable the Email trust bit.
>
> D-TRUST GmbH is a subsidiary of Bundesdruckerei GmbH and is fully owned by the German State. D-TRUST currently has two root certificates included in Mozilla’s program. The ‘D-TRUST Root Class 3 CA 2 2009’ and ‘D-TRUST Root Class 3 CA 2 EV 2009’ root certificates are currently enabled with the Websites trust bit, and were included via Bugzilla bug #467891. In Europe D-TRUST wants to promote the use of signed and encrypted email, so D-Trust is offering different types of certificates for this use case: Personal, Team and Device IDs.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1166723
>
>

All,

D-Trust (a currently included CA, in good standing) is requesting that a new root certificate be included, but only to have the Email trust bit enabled for it. Therefore, I plan to close this discussion and recommend approval in the bug. Please reply asap if you have any concerns about this.

Thanks,
Kathleen

[Kathleen Wilson]

Thank you to those of you who have reviewed this request, and to those of you who have participated in this discussion.

I am now closing this discussion, and I will update the bug to recommend approval of this request from D-TRUST to include the D-TRUST Root CA 3 2013 root certificate and enable the Email trust bit.

All further follow-up on this request should be in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1166723

Thanks,
Kathleen