697908 - Investigate or remove DFN-Verein

Status: VERIFIED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Ben Bucksch (:BenB)]

https://www.eff.org/files/colour_map_of_CAs.pdf

This shows that DFN-Verein (Deutsches Forschungs-Netzwerk, German Research network) is the epi-center of countless CAs. Most of the CAs that it trusts are various universities, schools, and institutes. None of these should be able to sign certs for the general web.

Investigate: Please whether DFN-Verein and Mozilla (NSS) is *technically* limiting the domains that these CAs can issue certs for, e.g. Universität Erfurt must only be able to sign certs for *.uni-erfurt.de.

Action: If the above is not true, either because of DFN-Verein or because NSS cannot enforce this, please either remove DFN-Verein or implement the restrictions.

Importance: Having some forgotten server standing in a uni somewhere being able to sign certs for my bank is unacceptable, in any case, no apologies.

Comment 1

[Ben Bucksch (:BenB)]

The same would be true for any CA that signs and allows big companies to have their own subordinate certs that *technically* (!) allow to sign arbitrary domains. (Legal restrictions are irrelevant.)

Comment 2

[Kathleen Wilson]

The DFN-Verein CA certificate is not a BuiltIn Object Token in NSS.

Carsten, Would you please comment in this bug regarding the constraints and auditing of the DFN sub-CA?

Comment 3

[Ben Bucksch (:BenB)]

FYI, I ended up with 3 certs from DFN-Verein listed as CA in Firefox, stored in "Software Security Device":
* Deutscher Bundestag CA - G01
* Zertifizierungsstelle der TUM
* ZIVIT CA - G01

I don't know how they got there, I didn't add them, like most other software certs listed there. Probably they were listed as intermediate certs for some server cert and automatically stored.

TUM probably means Technische Univerität München. To me, that suggests that the central DFN-Verein cert is signed by some other CA that we ship and trust, and therefore Mozilla indeed implicitly trusts all those schools listed in the PDF.

Comment 4

[Carsten]

Hi Kathleen, Ben, All,

From T-Systems point of view there is no need for either organizational or technical modification, because the current procedures and implementations do already meet the stated requirements.

First of all, let me stress that _all_ Sub-CAs are located and operated centrally by DFN on one platform. No Sub-CA’s private key is located at a DFN member’s infrastructure.

It may be of interest, that this issue was discussed years back during T-Systems initial request to add its root into Mozilla's NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=378882), which led to some changes regarding DFN's policy to meet Mozilla's requirement.
Kathleen asked for further information regarding the domain validation procedure in comment #103 (https://bugzilla.mozilla.org/show_bug.cgi?id=378882#c103). This was answered by one of my colleagues in comment #110 (https://bugzilla.mozilla.org/show_bug.cgi?id=378882#c110).

DFN's CP states in chapter 3.2.2:
"If a domain name is used in a certificate, the organization's right to use the domain name is verified by DFN-Verein as the PCA."

This means DFN's infrastructure has implement _technical and organizational_ restrictions for each of their sub-CAs to limit the ability of signing certificates. Each DFN member has to announce and request the release of assigned domains. Following a well-defined workflow this is performed by a responsible person of the member in question. No DFN member is able to issue certificates other than their own, validated and technically released domains. Domains can be activated by DFN only, not the members itself.

Regarding the concerns related to audits: T-Systems as owner of the root-CA still is performing an annual audit on DFN, as stated within the bug referred to above. 

It may be helpful for some further investigations - so here are the links to DFN's documentation: 
https://www.pki.dfn.de/policies/
english CP:  https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP_v22-english.pdf
english CPS: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS_v21-english.pdf



Encouraged by discussions in the past, we believe more than ever that DFN disclose quite a lot of information to the public regarding their relationsships to their customers by running those sub-CAs. Others may hide those relations by running just Enterprise RAs, which cannot be seen by the certificate hirachy. 
This attitude of public disclosure is one of the main points of especially Mozilla's policy. 


In case of further questions let me know, I will provide you with an answer as soon as possible. Please be aware, that there is a public holiday on 1st of November (Tuesday next week) in Germany and many people take the chance to get a long weekend by going on vacation on Monday. Anyhow, personally I will be available on Monday.

Kind regards,
Carsten

Comment 5

[Ben Bucksch (:BenB)]

> First of all, let me stress that _all_ Sub-CAs are located and operated
> centrally by DFN on one platform.

With "Platform", you mean physical server? Meaning all Sub-CAs are in your house?

That, together with the procedural limitations on your servers so that they sign certs only for the sub-domains of the relevant orgs, that is sufficient, IMHO.

Comment 6

[Carsten]

Hi Ben,

You are right, "platform" in this case means technical infrastructure solely located within the data center owned by DFN.

Thanks,
  Carsten

Comment 7

[Kathleen Wilson]

(In reply to Ben Bucksch (:BenB) from comment #3)
> FYI, I ended up with 3 certs from DFN-Verein listed as CA in Firefox, stored
> in "Software Security Device":
> * Deutscher Bundestag CA - G01
> * Zertifizierungsstelle der TUM
> * ZIVIT CA - G01
> 
> I don't know how they got there, I didn't add them, like most other software
> certs listed there. Probably they were listed as intermediate certs for some
> server cert and automatically stored.
> 

Yes, you must have visited a website which served up the SSL cert and the corresponding intermediate certs. Certs that are included by default in NSS are shown as "Builtin Object Token" in the Certificate Manager. The intermediate certs that are provided by websites or root certs that you import manually are displayed as "Software Security Device" in the Certificate Manager.


> TUM probably means Technische Univerität München. To me, that suggests that
> the central DFN-Verein cert is signed by some other CA that we ship and
> trust

Correct. For example, if you browse to https://www.dfn-cert.de/ and view the SSL cert details you see that the "DFN-Verein PCA Global - G01" intermediate cert is signed by the "Deutsche Telekom Root CA 2" root certificate, which is a Builtin Object Token in NSS (listed under Deutsche Telekom AG).

Carsten is the representative of T-Systems for the "Deutsche Telekom Root CA 2" root certificate.

Comment 8

[Kathleen Wilson]

Carsten, Thank you for providing the thorough information in Comments #4 and #6.

Ben, Thank you for your interest in investigating a CA Hierarchy that looked suspicious to you in the EFF SSL Observatory data. I appreciate you taking the time to file this bug and follow up on it. 

I believe this particular concern has been addressed. 

Please don't hesitate to file additional bugs in the future as you notice things of concern regarding CA certificates.

Comment 9

[Ben Bucksch (:BenB)]

VERIFIED WONTFIX

Thanks, Carsten, for the swift response. Sorry for crying wolf and thanks for bearing with me. More importantly, thanks for handling this properly in the first place.

(FYI, the PDF is linked on <https://www.eff.org/deeplinks/2011/10/how-secure-https-today>. It's unnecessarily scary (the CAs cannot actually sign gmail.com as implied there), so you may want to inform the author, or I will.)

Comment 10

[Carsten]

Hi Ben,

No sorry - that's how it should work I believe :-) 
Someone having questions brings the issue to notice giving the involved parties the possibility to clarify (and I other cases to take some corrective actions if necessary).

Thanks for your hint regarding the EFF article. Good point. We will happily get in contact with the author and if you don't have any objections we would link to this bug as well.

Enjoy tomorrows public holiday ;-)

Comment 11

[Ben Bucksch (:BenB)]

> if you don't have any objections we would link to this bug as well.

No objections.
Thanks for your fine work.