Closed Bug 275583 Opened 20 years ago Closed 18 years ago

Add T-Systems CA certificate

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: hecker, Assigned: hecker)

Details

I've received a request from T-Systems (subsidiary of Deutsche Telekom) to add
two root CA certificates to Mozilla and related products: Deutsche Telekom Root
CA 1 and Deutsche Telekom Root CA 2. T-Systems operates the Trust Center for
Deutsche Telekom. The Trust Center has not been WebTrust audited, but has been
QM DIN ISO 9001:2000 certified since 1997, and since 1998 has fulfilled the
requirements of the German Signature Act. (Information supplied by T-Systems.)

For other current information see the T-Systems listing on my CA certificate
information page:

  http://www.hecker.org/mozilla/ca-certificate-list

Here are the open issues regarding this CA's application:

1. T-Systems does not have a current Certification Practices Statement (CPS) for
the root CAs (either of them). This is supposedly being revised and will be
available in January 2005.

2. I'd like some more information about T-Systems/Trust Center compliance with
the German Digital Signature Act, including URLs pointing to information in
English about this.
http://www.droit.fundp.ac.be/textes/addendum.pdf 
 
Rosa Julià -Barcelà 
  
 
(3) Duties and Obligations 
 
The DSA provides, inter alia, for the following obligations: 
 
Article 5 states that the CA will have to reliably establish 
the identity of persons applying for a certificate as well 
as information concerning their professional status. 
 
The CA must issue certificates and take measures to prevent 
undetected forgery or manipulation of data as well as to 
ensure confidentiality of private signature keys. 
 
The CA will notify the applicants of the measures necessary 
to support secure digital signatures and their reliable verification. 
 
Article 8 contains an obligation concerning the invalidation 
of certificates where the owner of a signature key requests 
it, when the certificate was obtained through certain false 
statements. It should be noted that the DSA does not address 
the issue of whether the CA should be required to provide a 
full 24-hour service for invalidating certificates. 
 
(4) Liability 
 
Unlike other laws or proposals, the DSA does not address 
liability issues. Legal comments argue that regulation has 
been postponed until more consensus has been achieved about 
which kind of rules should be established. Therefore, at the 
moment, the general liability rules shall apply. In case of 
tort liability, this means that a with-fault liability regime 
will be applicable. 
 
The licensed CA, as described above, has the statutory 
obligation to issue certificates and to establish and 
maintain a database of revoked certificates. Thus, the CA 
should assume responsibility for the accuracy, the updating 
and completeness of its certificates and database vis a vis 
its own subscribers. 
 
The criteria of duty of care would seem to be a good one. 
However, because of the technical issues surrounding the 
certification process, it will be very difficult for 
consumers to prove the lack of care of the CA in the 
issuance of a certificate. Consequently, we suggest that 
the onus probandi should be reversed. This means that it 
should be sufficient for the damaged subscriber and third 
party to assert that the CA did not exercise sufficient 
care in the carrying out of his obligations and it will 
be up to the CA to evidence the contrary by proving the 
satisfaction of the requirements set out in the DSA and 
Ordinance. 
 
In order to compare the two regimes it would be 
necessary to state with some certainty what it 
is that WebTrust achieves, and I don't think this 
is possible in objective terms.  Or, at least I've 
not seen any objective statement of what MF 
demands of the WebTrust regime, and its place 
is more justified on "historical evolution." 
 
So any comparison would have to be subjective. 
 
Having said that, I suspect that this is easy enough 
in this specific case, because the German law 
follows the regulated model for Digital Signature 
Acts. 
 
In digital signature laws there are (as a gross 
simplification) two "models" being the highly 
regulated one and the permissive one.  The 
latter is the easiest one to write about and 
understand:  it simply states that a signature 
that is created digitally is not denied the status 
of a signature purely because it is digital. 
 
This is no bad thing, as it extends the signature 
and allows it to be considered on its merits in 
a dispute, which is what we want.  However, it 
adds nothing to a question of whether a CA 
using that form is comparable to a WebTrust 
audited CA, the precise question today. 
 
The other model, the regulated model, is often 
referred to as the Utah model.  This model is 
comparatively heaveyweight and much closer 
to WebTrust.  In this model, a CA can be licensed 
by the state, and must take on obligations and 
responsibilities.  As long as those obligations 
and responsibilities are serious, then one could 
make a subjective judgement that this is as 
sufficient as WebTrust, for the purposes of 
Mozilla (I'm writing this trying to avoid stating 
that WebTrust itself represents the necessary 
goal...). 
 
Doing a bit of googling I found the link below, 
which is an analysis of the 1997 law passed in 
Germany.  The appropriate text is also below 
as a useful summary of Mozilla's interests. 
 
On the basis of that, my "vote" would be for 
adding the T-Systems root cert, if they can 
confirm that they are licensed by the state 
under the provisions of the Act, and subject 
to Duties and Obligations outlined below. 
 
A simple letter to that effect would seem like 
sufficient due diligence.  Anything more would 
probably lead to needing the legal eagles to 
pass muster and an "opinion" and that is way 
beyond the scope of Mozilla Foundation's 
activities and position on liability. 
 
iang 
 
http://www.droit.fundp.ac.be/textes/addendum.pdf 
QA Contact: ca-certificates
Frank: do you have a name and email address for the contact from T-Systems?

Gerv
Lothar Eickholt <Lothar.Eickholt@t-systems.com>
I have sent the following email to Lothar.Eickholt@t-systems.com:

Dear Mr Eickholt,

Two years ago, you requested inclusion of the root certificate of your
Certificate Authority in Mozilla products.
https://bugzilla.mozilla.org/show_bug.cgi?id=275583

Since that time, we have formalised a CA Certificate policy, detailing how we process such requests:
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
We hope that this will bring clarity to the process.

Due to the age of the request, the above mentioned bug report has been closed. If inclusion of your certificate(s) is still desired, please could you file a new bug report as specified in section 14 of the policy, including all the information requested by that clause.

Many thanks,

Gerv
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.