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:

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 

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

[Eric Mill]

It's not a big deal. The important part is that there's flexibility for
entities in novel legal situations to meet the intent of the policy, which
this does.

On Wed, Dec 21, 2016 at 12:38 AM, Jakob Bohm  wrote:

> On 16/12/2016 16:10, Gervase Markham wrote:
>
>> On 14/12/16 23:13, Eric Mill wrote:
>>
>>> Sure, that works. Is the "in writing" part necessary? You might say
>>> instead
>>> "publicly accepted by Mozilla.", which would imply text on m.d.s.p or
>>> bugzilla that would necessarily be in writing, while also ensuring better
>>> visibility.
>>>
>>
>> I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
>> Bugzilla". I say "in writing" because I want to make sure some CA
>> doesn't come back with "you said it was OK when we chatted at CAB
>> Forum", or "you implied it was OK by accepting this other license over
>> here which is almost the same".
>>
>>
> I guess he meant that an "in writing" acceptance in an obscure or
> non-public forum (such as IRC or private e-mail) should not count,
> since it is not auditable which such acceptances exist.
>
> But it seems most objections have been ignored and the draconian rule
> instated.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

[tdelmas]

On Monday, December 19, 2016 at 2:45:16 AM UTC+1, Richard Wang wrote:
> I wish everyone can talk about this case friendly and equally.

I'm sorry about the wosing-bashing that followed. It wasn't my intention.

> We know Let's Encrypt is released after the public announcement, but two day 
> later, its .cn domain is still not registered, I think maybe it is caused by 
> the strict registration rule in China, so I registered it for protection that 
> not registered by Cornbug.

Thank you for that and for your prompt response.

I think Mozilla still doesn't answer my first question:what is the position of 
Mozilla regarding CA that act in bad faith regarding the usage of the names 
associated with others CA (like, registering such trademarks or domains) ?

Wosing's answer to my question was positive and in my opinion faithful, but 
it's not the first time a CA engage in such behavior, and I think Mozilla 
should at least makes an official comment.

Best regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 exception First Data

[Gervase Markham]

On 16/12/16 17:55, Nick Lamb wrote:
> So here we are, three months later, First Data are back, as predicted, asking 
> for another "exception".

Those reading the CAB Forum list will note that Mozilla has declined to
grant an additional exception.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

[Gervase Markham]

On 21/12/16 05:38, Jakob Bohm wrote:
>> I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in
>> Bugzilla". I say "in writing" because I want to make sure some CA
>> doesn't come back with "you said it was OK when we chatted at CAB
>> Forum", or "you implied it was OK by accepting this other license over
>> here which is almost the same".
> 
> I guess he meant that an "in writing" acceptance in an obscure or
> non-public forum (such as IRC or private e-mail) should not count,
> since it is not auditable which such acceptances exist.

It doesn't need to be auditable; CAs are not audited against Mozilla's
policy requirements. And Mozilla knows what license use permissions it
has given out. Regardless, we would expect to publish any such
exceptions granted in the application bug or some other obvious place.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy