Closed
Bug 275583
Opened 21 years ago
Closed 18 years ago
Add T-Systems CA certificate
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
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
Updated•19 years ago
|
QA Contact: ca-certificates
Comment 3•18 years ago
|
||
Frank: do you have a name and email address for the contact from T-Systems?
Gerv
| Assignee | ||
Comment 4•18 years ago
|
||
Lothar Eickholt <Lothar.Eickholt@t-systems.com>
Comment 5•18 years ago
|
||
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
Updated•8 years ago
|
Product: mozilla.org → NSS
Updated•3 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•