Deutsche Telekom/T-Systems CA request
Frank Hecker
period for a request from T-Systems (a subsidiary of Deutsche Telekom)
to add the Deutsche Telekom Root CA 2 root certificate to Mozilla. This
is bug 378882, and Kathleen has produced an information document
attached to the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=378882
Some points worth mentioning about this request:
* T-Systems actually has two other root CAs, T-TeleSec GlobalRoot Class
2 and T-TeleSec GlobalRoot Class 3. Those are not included in this
request (although of course we'd be glad to consider those as well in
future).
* T-Systems has undergone at least two audits, for ETSI 101 456 and
WebTrust for CAs. The WebTrust for CAs audit is the relevant one for our
purposes, since the WebTrust audit report we have is more recent. (Also,
the ETSI 101 456 audit was apparently a self-audit, though there is some
ambiguity about this.) Note that the WebTrust for CAs audit covered all
three T-Systems root CAs.
* There was apparently a bit of confusion about email certificates. As I
understand it, T-Systems does not directly issue certificates usable for
email. (T-Systems issues "qualified" certificates to individuals, but
those do not contain email addresses, and are apparently used primarily
in client authentication to web sites.) However T-Systems does have
subordinate CAs, most notably the Deutsche Forschungsnetz (DFN, the
German academic research network), that do issue email certificates and
verify email account control per the relevant CPSs/CPs.
This first public comment period will be for one week, and then I'll
make a preliminary determination regarding this request.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
German version of the CP and CPS, which I understand is the only legal
document. The English version seems to be a draft only and perhaps not
legally binding.
Nevertheless I read mostly the English version which is easier to
understand. Similar to Kathleen's comment at
https://bugzilla.mozilla.org/show_bug.cgi?id=378882#c46 I had difficulty
to come to positive conclusion concerning their handling of sub
ordination CAs and about the validation methods this CA requires. Some
has been answered in the bug, however the CP/CPS is not clear at all in
that respect and basically the concerns raised by Kathleen haven't been
addressed.
Subordinate CAs may be external to T-Systems and as I understand not
part and covered by the audit performed by E&Y. Instead we are referred
to "contractual obligations" without defining what those obligations
are. Those obligations are not clearly defined anywhere as far as I
could see. This is a problem which has been pointed out here previously
and at http://wiki.mozilla.org/CA:Problematic_Practices
Apparently subordinated CAs maintain their own sets of subordinated CA
certificates - despite the illustrations and descriptions and comments
telling us otherwise, or the term of root CAs is interpreted differently
in the CPS and are actually subordinated CAs. Anyway, that's what I
found out after visiting the suggested URL in comment 52 of bug 378882:
https://www.pki.dfn.de/
I couldn't find any clear regulation in respect of the issuing and
maintaining of subordinated CAs which are themselves subordinated to the
T-Systems root.
Validation of email addresses and domain names aren't clearly defined
(or I might have simply missed the relevant sections). Instead CP/CPS of
the subordinated CAs are governing and regulating those aspects
according to comment
https://bugzilla.mozilla.org/show_bug.cgi?id=378882#c52 and domain
ownership is commented with:
"Checking for the ownership of the domain is part of the legal process
to come to a contract with those customers (It`s no big deal to examine
the ownership of the domain via the responsible NIC)"
The "legal processes" are nowhere defined as far as I could find in the
CP/CPS nor are alternative minimum requirements concerning validations
clearly published. I haven't seen any CP/CPS of sub CAs which regulates
those aspects nor were they examined by Mozilla so far. Nor could I find
how IP address handled, which domain names are acceptable or anything
with relevance in that respect (hostnames, wild cards, IP addresses,
FQDN etc). The same applies for email address verification. Neither have
I found how identities and organizations are validated, which might be
relevant for code signing certificates.
My input is by no means conclusive and perhaps Kathleen or a
representative of T-Systems can point me to the relevant sections of
their CP/CPS. I reserve the right to raise additional questions during
the comments period should I find anything which should be cleared
before continuing.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
wolfgang...@t-systems.com
See the comments of T-Systems (WP as an Acronym of my Name Wolfgang
Pietrus) in the text below.
On Jul 20, 1:37 am, Eddy Nigg <eddy_n...@startcom.org> wrote:
> I started to review this inclusion request by reading parts of the
> German version of the CP and CPS, which I understand is the only legal
> document. The English version seems to be a draft only and perhaps not
> legally binding.
>
> Nevertheless I read mostly the English version which is easier to
> understand. Similar to Kathleen's comment athttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c46I had difficulty
> to come to positive conclusion concerning their handling of sub
> ordination CAs and about the validation methods this CA requires. Some
> has been answered in the bug, however the CP/CPS is not clear at all in
> that respect and basically the concerns raised by Kathleen haven't been
> addressed.
>
> Subordinate CAs may be external to T-Systems and as I understand not
> part and covered by the audit performed by E&Y.
WP: Yes, subordinate CAs may be external to T-Systems. Nevertheless
they are part of the audit in that way, that the auditor did prove our
process to register and issue subordinate CAs. Still this is common
business among trustcenter service providers.
Instead we are referred
> to "contractual obligations" without defining what those obligations
> are. Those obligations are not clearly defined anywhere as far as I
> could see. This is a problem which has been pointed out here previously
> and athttp://wiki.mozilla.org/CA:Problematic_Practices
WP: It is true, that the CP does not maintain a detailed list of
obligations for external SubCAs (besides the obligation that they must
comply to all rules within the CP). We didn't see any sense about
that, since we have made the experience that every enterprise (our
customers) is doing the job of building and running a PKI a little bit
different. We have to evaluate those circumstances for every request
just like the Webtrust auditors.
E&Y will perform ra-audits on a yearly basis. If they don't accept our
subCAs, we will loose the certfication and can and should be removed
from the Root store. Until then we think to be be compliant to this
standard. If Mozilla wants to define its own criteria for subCAs, we
are ready to modify our CP, CPS and in common our modus of operandi to
comply to them.
>
> Apparently subordinated CAs maintain their own sets of subordinated CA
> certificates - despite the illustrations and descriptions and comments
> telling us otherwise, or the term of root CAs is interpreted differently
> in the CPS and are actually subordinated CAs. Anyway, that's what I
> found out after visiting the suggested URL in comment 52 of bug 378882:https://www.pki.dfn.de/
WP: It is true: Those images and the text don't show explicitly the
possibilities of an hierarchical CA structure. Nevertheless the
certificate profile in chapter 7.1.1.2 shows PathLenConstraint = 5,
which should make this clear.
>
> I couldn't find any clear regulation in respect of the issuing and
> maintaining of subordinated CAs which are themselves subordinated to the
> T-Systems root.
>
> Validation of email addresses and domain names aren't clearly defined
> (or I might have simply missed the relevant sections).
WP: The CP mentions the requirement, that all data that are part of a
certificate have to be validated by a RA and that those date have to
enable a unique identification. How this can be accomplished, should
be defined be the CPS of the Subordinated CAs that issue user
certifates or other entity certificates. If someone comes up with a
method for evaluating certificate requests, that applies to most of
the enterprises of at least Germany and can be considered feasible, we
will be glad to define this method as mandatory. Until then we prefer
to discuss this issue with our customers directly and evaluate their
methods.
Instead CP/CPS of
> the subordinated CAs are governing and regulating those aspects
> according to commenthttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c52and domain
> ownership is commented with:
>
> "Checking for the ownership of the domain is part of the legal process
> to come to a contract with those customers (It`s no big deal to examine
> the ownership of the domain via the responsible NIC)"
>
> The "legal processes" are nowhere defined as far as I could find in the
> CP/CPS nor are alternative minimum requirements concerning validations
> clearly published.
WP: see our previous comments...
I haven't seen any CP/CPS of sub CAs which regulates
> those aspects nor were they examined by Mozilla so far. Nor could I find
> how IP address handled, which domain names are acceptable or anything
> with relevance in that respect (hostnames, wild cards, IP addresses,
> FQDN etc).
WP: We consider those issues not to be part of the Root CP or CPS. In
our opinion the Root defines the policies, but not the methods for the
SubCAs.
The same applies for email address verification. Neither have
> I found how identities and organizations are validated, which might be
> relevant for code signing certificates.
WP: Not only for code signing. Still: How the evaluation of data
within certificate requests is being performed in detail should be
part of a CPS of the issuing CA, but not of the Root.
If I would want to check the trustlevel of a certificate I would read
the CPS of the issuing CA first, and then evaluate the chain up to the
Root.
>
> My input is by no means conclusive and perhaps Kathleen or a
> representative of T-Systems can point me to the relevant sections of
> their CP/CPS. I reserve the right to raise additional questions during
> the comments period should I find anything which should be cleared
> before continuing.
>
WP: We think, that a CP of a Root should not be to specific in
defining methods, how policies should be implemented.
Nevertheless: If this discussion leads (Frank) to the conclusion, that
we should make an update on our CP, we will do that.
Best Regards
Wolfgang Pietrus
T-Systems Enterprise Services GmbH
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
rainer_k
If this is such a serious concern, why did Microsoft decicde to put
this CA inside the Windows
CA store and even distribute this via automatic update?
Installment of the Telekom CA into Firefox and putting more
restrictive policies for CAs into action in general
are two different topics and should not be interwoven.
The comment today that Cologne University (one of Germanys largest)
recommends IE as
standard browser just because of this CA question shows that this
issue must be resolved immediately!
Best regards,
Rainer
On 20 Jul., 01:37, Eddy Nigg <eddy_n...@startcom.org> wrote:
> I started to review this inclusion request by reading parts of the
> German version of the CP and CPS, which I understand is the only legal
> document. The English version seems to be a draft only and perhaps not
> legally binding.
>
> Nevertheless I read mostly the English version which is easier to
> understand. Similar to Kathleen's comment athttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c46I had difficulty
> to come to positive conclusion concerning their handling of sub
> ordination CAs and about the validation methods this CA requires. Some
> has been answered in the bug, however the CP/CPS is not clear at all in
> that respect and basically the concerns raised by Kathleen haven't been
> addressed.
>
> Subordinate CAs may be external to T-Systems and as I understand not
> part and covered by the audit performed by E&Y. Instead we are referred
> to "contractual obligations" without defining what those obligations
> are. Those obligations are not clearly defined anywhere as far as I
> could see. This is a problem which has been pointed out here previously
> and athttp://wiki.mozilla.org/CA:Problematic_Practices
>
> Apparently subordinated CAs maintain their own sets of subordinated CA
> certificates - despite the illustrations and descriptions and comments
> telling us otherwise, or the term of root CAs is interpreted differently
> in the CPS and are actually subordinated CAs. Anyway, that's what I
> found out after visiting the suggested URL in comment 52 of bug 378882:https://www.pki.dfn.de/
>
> I couldn't find any clear regulation in respect of the issuing and
> maintaining of subordinated CAs which are themselves subordinated to the
> T-Systems root.
>
> Validation of email addresses and domain names aren't clearly defined
> (or I might have simply missed the relevant sections). Instead CP/CPS of
> the subordinated CAs are governing and regulating those aspects
> according to commenthttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c52and domain
> ownership is commented with:
>
> "Checking for the ownership of the domain is part of the legal process
> to come to a contract with those customers (It`s no big deal to examine
> the ownership of the domain via the responsible NIC)"
>
> The "legal processes" are nowhere defined as far as I could find in the
> CP/CPS nor are alternative minimum requirements concerning validations
> clearly published. I haven't seen any CP/CPS of sub CAs which regulates
> those aspects nor were they examined by Mozilla so far. Nor could I find
> how IP address handled, which domain names are acceptable or anything
> with relevance in that respect (hostnames, wild cards, IP addresses,
> FQDN etc). The same applies for email address verification. Neither have
> I found how identities and organizations are validated, which might be
> relevant for code signing certificates.
>
> My input is by no means conclusive and perhaps Kathleen or a
> representative of T-Systems can point me to the relevant sections of
> their CP/CPS. I reserve the right to raise additional questions during
> the comments period should I find anything which should be cleared
> before continuing.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
Eddy Nigg
> Eddy,
>
> If this is such a serious concern, why did Microsoft decicde to put
> this CA inside the Windows
> CA store and even distribute this via automatic update?
> Installment of the Telekom CA into Firefox and putting more
> restrictive policies for CAs into action in general
> are two different topics and should not be interwoven.
Microsoft and Mozilla implement to different policies and criterion for
the shipping of CA roots. There are CAs which are present in Mozilla and
not in Microsoft and vice versa. There are CAs which are in Opera but
not in Apple, but again in Microsoft and not Mozilla. Each software
vendor implements its own policy. A CA wishing to be built into the NSS
module must conform to the Mozilla CA policy and not to the Microsoft CA
root program.
For more information about the Mozilla CA policy please read
http://www.mozilla.org/projects/security/certs/policy/ and also
http://wiki.mozilla.org/CA:Problematic_Practices
>
> The comment today that Cologne University (one of Germanys largest)
> recommends IE as
> standard browser just because of this CA question shows that this
> issue must be resolved immediately!
>
I've read that comment and it's simply disgusting! But Mozilla has
withstand much higher pressure in the past! Such comments are only
counter-productive and I'm sure the comment doesn't represent the policy
of the T-Systems CA!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Eddy Nigg
> Eddy, Frank,
>
> See the comments of T-Systems (WP as an Acronym of my Name Wolfgang
> Pietrus) in the text below.
Hallo Wolfgang,
Vielen Dank fuer Ihre Antwort :-)
>>
>> Nevertheless I read mostly the English version which is easier to
>> understand. Similar to Kathleen's comment athttps://bugzilla.mozilla.org/show_bug.cgi?id=378882#c46I had difficulty
>> to come to positive conclusion concerning their handling of sub
>> ordination CAs and about the validation methods this CA requires. Some
>> has been answered in the bug, however the CP/CPS is not clear at all in
>> that respect and basically the concerns raised by Kathleen haven't been
>> addressed.
>>
>> Subordinate CAs may be external to T-Systems and as I understand not
>> part and covered by the audit performed by E&Y.
>
> WP: Yes, subordinate CAs may be external to T-Systems. Nevertheless
> they are part of the audit in that way, that the auditor did prove our
> process to register and issue subordinate CAs. Still this is common
> business among trustcenter service providers.
Can you point me to the relevant sections at the CP/CPS which describes
the obligations of those CAs concerning issuing of intermediate CA
certificates, their obligations concerning issuing of end user
certificates and the relevant validation requirements of all the CA
certificates under your root?
It might be common business practice to issue intermediate CA
certificates, but it's also common practice to define the requirements
and obligations of those CAs and how they are governed, including the
auditing of those CAs which operate under a certain root. For more
information see also
http://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_unconstrained_subordinate_CAs
BTW, intermediate CA certificates are many times issued, operated,
regulated and governed by the very same CA and all CA certificates are
effectively controlled by the relevant CP/CPS and same public key
infrastructure.
> WP: It is true, that the CP does not maintain a detailed list of
> obligations for external SubCAs (besides the obligation that they must
> comply to all rules within the CP).
OK, this is a very important statement! As you confirm, the external CAs
must adhere to your CP, but the CP doesn't define those requirements and
obligations. This is the actual issue I'm touching here. The CP is a
legally binding document which is public and which the auditor has to
confirm (amongst other things). As a relying third party (which includes
Mozilla and all its users), this is the document we have to rely on.
>> Apparently subordinated CAs maintain their own sets of subordinated CA
>> certificates - despite the illustrations and descriptions and comments
>> telling us otherwise, or the term of root CAs is interpreted differently
>> in the CPS and are actually subordinated CAs. Anyway, that's what I
>> found out after visiting the suggested URL in comment 52 of bug 378882:https://www.pki.dfn.de/
>
> WP: It is true: Those images and the text don't show explicitly the
> possibilities of an hierarchical CA structure. Nevertheless the
> certificate profile in chapter 7.1.1.2 shows PathLenConstraint = 5,
> which should make this clear.
OK, this shows that the chain can be extended for up to five
subordinated CAs. How are those regulated and governed? Can an external
CA issue another subordinated CA certificate to another external entity?
What are the obligations of those CAs? How will they validate domains,
emails and identities? How will E&Y audit them? Please note that the
audit requirement of the Mozilla CA policy doesn't fall only on the CA
root, but on all issuing CAs within the same root.
> WP: The CP mentions the requirement, that all data that are part of a
> certificate have to be validated by a RA and that those date have to
> enable a unique identification. How this can be accomplished, should
> be defined be the CPS of the Subordinated CAs that issue user
> certifates or other entity certificates. If someone comes up with a
> method for evaluating certificate requests, that applies to most of
> the enterprises of at least Germany and can be considered feasible, we
> will be glad to define this method as mandatory. Until then we prefer
> to discuss this issue with our customers directly and evaluate their
> methods.
I think that we also would like to know about it. I would like to know
if the validation procedures conform to the Mozilla CA policy and I'd
like to know where in your CP and practice statements I can understand
what those requirements are.
>
> I haven't seen any CP/CPS of sub CAs which regulates
>> those aspects nor were they examined by Mozilla so far. Nor could I find
>> how IP address handled, which domain names are acceptable or anything
>> with relevance in that respect (hostnames, wild cards, IP addresses,
>> FQDN etc).
>
> WP: We consider those issues not to be part of the Root CP or CPS. In
> our opinion the Root defines the policies, but not the methods for the
> SubCAs.
This is acceptable, however in that case I think we must evaluate those
CA policies of the issuing CA. CAs through root proxies are very
problematic and circumvent directly and effectively the audit
requirements of the Mozilla CA policy. Additionally, the point I raised
above are very important aspects of the Mozilla CA policy!
>
> The same applies for email address verification. Neither have
>> I found how identities and organizations are validated, which might be
>> relevant for code signing certificates.
>
> WP: Not only for code signing. Still: How the evaluation of data
> within certificate requests is being performed in detail should be
> part of a CPS of the issuing CA, but not of the Root.
> If I would want to check the trustlevel of a certificate I would read
> the CPS of the issuing CA first, and then evaluate the chain up to the
> Root.
Yes, and in this case I suggest that the issuing CAs should apply for
inclusion at Mozilla directly! As it has been the case with other CA
requests in the past, where the root CA has limited functions and/or
requirements on part of the CA which are actually the functioning CAs
and are effectively a CA and different entity in their own right and
where their CA and public key infrastructure (including physical) has
NOT been audited, I tend to recommend to Frank to refrain from including
T-Systems CA root certificate until either the issues raised have been
addressed and/or the issuing CAs themselves requested inclusion and have
been evaluated accordingly.
>
> WP: We think, that a CP of a Root should not be to specific in
> defining methods, how policies should be implemented.
> Nevertheless: If this discussion leads (Frank) to the conclusion, that
> we should make an update on our CP, we will do that.
>
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
wolfgang...@t-systems.com
we (T-Systems) appreciate your input, even if we don't agree with all
of your statements. We strongly encourage you to give further feedback
until the end of the first week. We know that you do this in your
spare time to support Mozilla, but changing the CP and CPS is a
serious act and shouldn't be done on a weekly basis. So the more
findings you have in the first round, the better for us all.
We will take your feedback after this week, try to discuss it with
Frank and then take all steps that are necessary to accomplish our
goal.
Best regards
Wolfgang
Frank Hecker
> If this is such a serious concern, why did Microsoft decicde to put
> this CA inside the Windows
> CA store and even distribute this via automatic update?
> Installment of the Telekom CA into Firefox and putting more
> restrictive policies for CAs into action in general
> are two different topics and should not be interwoven.
I have not yet had time to read and respond to all the messages in this
thread. However I do want to make two points:
First, as Eddy Nigg mentioned, Mozilla does not have exactly the same
policy as Microsoft with respect to adding root CA certificates. We are
a public project in which anyone can participate, and our policy is
designed to address the concerns that many Mozilla community members
have about adding new roots. In particular, our community members want
to have a reasonable level of assurance that CAs follow basic security
practices when issuing SSL, email, or object signing certificates, and
they want to have some publicly-available evidence regarding those
practices.
That is why our policy has some (relatively minimal) requirements
regarding verification of subscribers' domains, email addresses, and
identities (for SSL, email, and object signing certificates
respectively). That is also why we want to see Certification Practice
Statements or other published documents that state that such
verification is done.
Second, in the case of T-Systems the issue seems to be that T-Systems
functions primarily as a root CA, not as a CA issuing end-entity
certificates. Therefore the T-Systems CPS does not address practices
relating to issuance of end-entity certificates. The solution seems to
be that we need to look at the CPS documents for DFN and other
subordinate CAs of T-Systems, or obtain some other public statement
about the practices of these subordinate CAs.
Eddy Nigg
I think, that there now two separate decisions which have to be taken at
this stage. One is the issue about the audit requirements concerning the
intermediate CAs about which I suggest that Frank comes to a principal
decision before continuing. Obviously there isn't much point in
continuing to evaluate this root, if the subordinated CAs are not in
compliance with the requirements of Mozilla.
The other issue is about all the other aspects which are missing and/or
need to be evaluated against the relevant CA policies of the
intermediate CAs. As Frank indicated, Mozilla might choose to evaluate
all those policies *or* you might choose to modify your CP/CPS
accordingly (and have those confirmed by your auditor).
Once a decision has been taken about the former issue concerning the
audit requirement, me and others here will be glad to invest some more
time to find all issues which might have to be addressed in order to
have your policies in compliance with the Mozilla CA policy.
Thank you for your positive input so far and hope you'll accomplish your
goals!
Justin Dolske
> If this is such a serious concern, why did Microsoft decicde to put
> this CA inside the Windows
> CA store and even distribute this via automatic update?
I don't think "but Microsoft did it" is, in general, a convincing
argument when it comes to good security practice.
> The comment today that Cologne University (one of Germanys largest)
> recommends IE as
> standard browser just because of this CA question shows that this
> issue must be resolved immediately!
No, I think following an established process to safeguard the
security/trust of 180+ million Firefox users is the important issue.
It's unfortunate that it can take so long to process new requests, but
neither should we hastily rush to rubberstamp anyone who knocks on the door.
Justin
Thorsten Becker
> Second, in the case of T-Systems the issue seems to be that T-Systems
> functions primarily as a root CA, not as a CA issuing end-entity
> certificates. Therefore the T-Systems CPS does not address practices
> relating to issuance of end-entity certificates.
> The solution seems to
> be that we need to look at the CPS documents for DFN and other
> subordinate CAs of T-Systems, or obtain some other public statement
> about the practices of these subordinate CAs.
To the folks at DFN/T-Systems: Wolfgang wrote: "Yes, subordinate CAs may
be external to T-Systems. Nevertheless they are part of the audit in
that way, that the auditor did prove our process to register and issue
subordinate CAs."
So it could perhaps be possible to get a detailed statement from the
auditor about the process of approving sub CAs?
Thorsten