Re: Include Additional D-TRUST root certificate

2017-03-09 Thread Kathleen Wilson via dev-security-policy
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Include Additional D-TRUST root certificate

2017-03-03 Thread Kathleen Wilson via dev-security-policy
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Include Additional D-TRUST root certificate

2016-12-21 Thread 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:

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