D-TRUST Root Inclusion Request

[Kathleen Wilson]

D-TRUST has applied to add the “D-TRUST Root Class 3 CA 2 2009” and
“D-TRUST Root Class 3 CA 2 EV 2009” root certificates to NSS. 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.

D-TRUST GmbH, founded in Berlin in 1998, is a wholly owned subsidiary of
Bundesdruckerei and is the only German trust center authorized 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.

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

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#D-TRUST

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

Noteworthy points:

* The primary documents are the 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

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.

The request is to turn on the Websites trust bit for both root certs. EV
treatment is requested for the “D-TRUST SSL Class 3 CA 1 EV 2009” root cert.

* Only Class 3 certs are issued within the hierarchy of these roots.

* CP section 1.5.3: Class 3 SSL-EV-certificates as well as their Sub-
and Root-CAs adhere to the specifications of the CA/Browser Forum
Guidelines for Extended Validation Certificates [GL-BRO]. In the case of
inconsistencies between this document and above mentioned guidelines,
the [GL-BRO] takes precedence for Class 3 SSL EV CAs as well as their
Sub- and Root-CAs.
** CP section 1.6.3: [GL-BRO] = Guidelines for Extended Validation
Certificates, CA/Browser Forum, Version 1.2 October 2009

* CP section 3.2.2:
** Class 3: High-level identification and assessment. Personal
participant identification as well as a thourough assessment of the
applicant-data are conducted along the procedures defined for the
creation of qualified certificates. Legal entities are verified in
adherence with the [ETSI-F]- guidelines. The verification encompasses
all of the DN-components.
** Class 3 EV-certificates: Identification and authentication as well as
data verification follow the standards stated in [GL-BRO] and section
12.2 [GL-BRO].

* CPS Section 4.2.1: An organization’s domain and possibly further
attributes such as e-mail addresses are verified by a domain-enquiry in
the official registers (WHOIS). Class 3-2: It is questioned whether the
subscriber has the exclusive control of the domain. The findings are
documented. With EV certificates in addition a review of the domain name
for known phishing domains of blacklists is carried out. Domains that
are not subject to registration (non Top-Level Domains) are not allowed.

* EV Policy OID: 1.3.6.1.4.1.4788.2.202.1

* Root Cert URLs:
https://www.d-trust.net/cgi-bin/D-TRUST_Root_Class_3_CA_2_2009.crt
https://www.d-trust.net/cgi-bin/D-TRUST_Root_Class_3_CA_2_EV_2009.crt

* Test Websites:
https://certdemo-ov-valid.ssl.d-trust.net
https://certdemo-ev-valid.ssl.d-trust.net

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

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

* Potentially Problematic Practices – None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices):

This begins the discussion of the 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 to NSS. 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.

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

[Erwann Abalea]

The resources accessed at
http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_2009.crl
http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.crl
are PEM encoded, they MUST be DER encoded objects.

A question: why do your OCSP responses include the root certificate? It's useless, and costly.

I tried to read the CPS, but my german is too bad. Do your CAs allow for SHA1withRSA signatures? If yes, then the serial number MUST have at least 20 random bits, or some random data MUST be set in the subject. From what I read in your CPS, you have a serialNumber attribute in the subject name of the produced certificates, but it's not random for your Class 3 CA.

[frank.st...@bdr.de]

Thanks for your evaluation.

1. I requested the CRL-encoding to be changed.
2. You're right - for end entity certificates of this type, meaning where the root has already been distributed, it's definetly useless. So, the reason for this is historicly in our case, but technically we are definetly able to "sitch off" this.
3. Under these roots we're just issuing SHA2 certificates.

I expect that changes should be done by the end of the week after they have been approved internally.

[Erwann Abalea]

Le mardi 16 octobre 2012 17:12:17 UTC+2, (inconnu) a écrit :
> 2. You're right - for end entity certificates of this type, meaning where the root has already been distributed, it's definetly useless. So, the reason for this is historicly in our case, but technically we are definetly able to "sitch off" this.

To be clear, that's not a blocker, sending the root is only useful for debugging; a correctly implemented RP will simply ignore it. So it simply adds latency for the browser.

> 3. Under these roots we're just issuing SHA2 certificates.

Reading the Mozilla CA Policy again, the 20bits of entropy are not algorithm dependant. Preferably in the serial number, but others have put it in the subjectName (as the very first RDN).
That's a SHOULD for CABForum Basic Requirements, and only the serial number is mentionned.
Adding entropy allows you to escape a chosen-prefix collision attack in case the hash algorithm used is no more collision resistant. SHA2 isn't at risk for now, so I guess you have plenty of time to modify your platform.

[frank.st...@bdr.de]

> 2. Yes, but if we just do reduce latency, than it's great for the end user experience.

> 3. We had clearly been focussed on the CAB forum in this case and were waiting for the next release update of our certificate management system since our current version also does not support that kind of entropie in the certificate serial no. But we would also go now for "subject" and add it there as an interims solution.

We would start to implement and test early next week now. I'll let you know then.

[Kathleen Wilson]

Thanks, Erwann, for reviewing and commenting on this request.

Does anyone else have feedback/comments regarding this request from D-TRUST?

Kathleen

[Frank S.]

Since we always offer both formats (for lots of other products we thought we still do need that), but we don’t know which the customers are using. We have to evaluate that and it might take a little while. Here’s how the different links do look like today for example:
PEM – http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.crl
DER - http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl

So, for SSL we will have a special solution and we have two options on the table, that could both be realized – No.1 is, what the team would prefer as an interim solution (we’re discussing a general move meanwhile here to DER for all products):

1.) Change the CRL-Link in the cert profile to http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl
2.) Ex-Change Encoding of the CRLs and rename the http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl to http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.pem.crl (or just leave it out completely for SSL)

BUT: in case of 1.) which would just effect new certs – would we have to revoke and replace valid certificates that are outside today in order give them new certs with the new link including crl in DER-format?

[Frank S.]

In regards to the subject random value: for the position is not the end user's standard cert viewer relevant, but the ASN-viewer. So, if you look at the EE cert on a Browser you'll find the random value at the very end of the cert - correct?

[Erwann Abalea]

Le lundi 29 octobre 2012 11:39:08 UTC+1, Frank S. a écrit :
> Since we always offer both formats (for lots of other products we thought we still do need that), but we don’t know which the customers are using. We have to evaluate that and it might take a little while. Here’s how the different links do look like today for example:

You're free to offer both formats to your customers.
However, RFC5280 paragraph 4.2.1.13 shows this:

-----
If the DistributionPointName contains a general name of type URI, the
following semantics MUST be assumed: the URI is a pointer to the
current CRL for the associated reasons and will be issued by the
associated cRLIssuer. When the HTTP or FTP URI scheme is used, the
URI MUST point to a single DER encoded CRL as specified in
[RFC2585]. HTTP server implementations accessed via the URI SHOULD
specify the media type application/pkix-crl in the content-type
header field of the response.
-----

So the object designated by the CRLDP HTTP URI MUST be DER encoded.

> PEM – http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.crl
> DER - http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl

The former returns an error with Firefox (version 16.0.x here).

> So, for SSL we will have a special solution and we have two options on the table, that could both be realized – No.1 is, what the team would prefer as an interim solution (we’re discussing a general move meanwhile here to DER for all products):
>
> 1.) Change the CRL-Link in the cert profile to http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl
>
> 2.) Ex-Change Encoding of the CRLs and rename the http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.der.crl to http://www.d-trust.net/crl/d-trust_ssl_class_3_ca_1_ev_2009.pem.crl (or just leave it out completely for SSL)
>
> BUT: in case of 1.) which would just effect new certs – would we have to revoke and replace valid certificates that are outside today in order give them new certs with the new link including crl in DER-format?

My preference would go for #2 (and don't populate certificates with the PEM link of course). If some of your customers need to have a direct access to the PEM encoded one, they certainly have a local parameter, and can change it.
Why they can't convert the object by themselves is not a question here.

[Erwann Abalea]

Le lundi 29 octobre 2012 17:01:38 UTC+1, Frank S. a écrit :
> In regards to the subject random value: for the position is not the end user's standard cert viewer relevant, but the ASN-viewer. So, if you look at the EE cert on a Browser you'll find the random value at the very end of the cert - correct?

I'm not sure I understand you well, here.

Are you going to place the required entropy in an AVA of certificate.subjectName rather than in the certificate.serialNumber field?
If yes, then this AVA SHOULD be placed before any user-controlled data, and thus SHOULD be among the first elements of the subjectName sequence. Different browsers will display DN in different orders, so I'm talking about the ASN.1 Sequence here.

[Frank S.]

You got everything right - thanks for your help, Erwann!!

Cheers,

Frank

[Frank S.]

Hi,

changes in regards to subject random value and CRL-format will be applied to our systems nex thursday. We will issue new certs for our EU test websites and notify you.

Cheers,
Frank

[Frank S.]

We already changed the available CRL-format and random value, but realized, that the SAN-field should also be applied right away if we're making changes anyway. These change will be applied next Thursday within the next maintainance slot, so the new certs should be installed early next week.

[David E. Ross]

On 11/27/12 6:41 AM, Frank S. wrote:
> We already changed the available CRL-format and random value, but realized, that the SAN-field should also be applied right away if we're making changes anyway. These change will be applied next Thursday within the next maintainance slot, so the new certs should be installed early next week.
>

You are replying twice to the
mozilla-dev-s...@lists.mozilla.org mailing list -- once in a
To: line and once in a Cc: line -- and again to the
mozilla.dev.security.policy newsgroup. Thus, you are flooding the
discussion with duplicate messages.

Either send E-mail to mozilla-dev-s...@lists.mozilla.org or
send newsgroup messages to mozilla.dev.security.policy BUT NOT BOTH.
Also, DO NOT SEND E-mail to
mozilla-dev-s...@lists.mozilla.org as Cc:.

--

David E. Ross
<http://www.rossde.com/>

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Frank S.]

Sorry, was off sick some days, so my last requested additional change for the SAN field will take some more days, but that's not required by today anyway.

Meanwhile the team installed the certs with new profiles though at https://certdemo-ev-valid.ssl.d-trust.net/ and https://certdemo-ov-valid.ssl.d-trust.net/. Please check the CRL and Random value and let me know if it's fine now when you have a chance to do that. Thanks!

[Frank S.]

We have also implemented the SAN-entry into the EU certs now. Please look at https://certdemo-ev-valid.ssl.d-trust.net and https://certdemo-ov-valid.ssl.d-trust.net to verify.

[Erwann Abalea]

Le jeudi 13 décembre 2012 15:16:41 UTC+1, Frank S. a écrit :
> We have also implemented the SAN-entry into the EU certs now. Please look at https://certdemo-ev-valid.ssl.d-trust.net and https://certdemo-ov-valid.ssl.d-trust.net to verify.

Everything's fine for me now.

[Kathleen Wilson]

Thanks Erwann!

All of the action items that were identified in this discussion have
been closed.

Does anyone have further comments about 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 to NSS, 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?

If not, I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

On 12/13/12 10:37 AM, Kathleen Wilson wrote:
> Does anyone have further comments about 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 to NSS, 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?
>
> If not, I will close this discussion and recommend approval in the bug.
>
> Thanks,
> Kathleen
>

Thank you to those of you who reviewed and contributed to this
discussion about the 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,

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.

All of the action items that were identified during this discussion have
been resolved.

I am closing this discussion, and I will recommend approval in the bug.

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

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen