Closed Bug 179716 Opened 22 years ago Closed 18 years ago

Some TC TrustCenter CA certs missing from mozilla

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: schliwa, Assigned: hecker)

References

Details

User-Agent:       Mozilla/4.78 [de]C-CCK-MCD DT  (WinNT; U)
Build Identifier: 

Mozilla 1.2b has buildin object token TC TrustCenter Class 2 CA - Class 0, Class 
1, Class 3 and Class 4 CA are missing. 
Our customers have to install them and to configure the trust level. 

Is it possible to pre-install our root ca certificates? 
http://www.trustcenter.de/certservices/cacerts/TC_RootServer_DER_Class0.der
http://www.trustcenter.de/certservices/cacerts/tcclass1-2011.der
http://www.trustcenter.de/certservices/cacerts/tcclass2-2011.der
http://www.trustcenter.de/certservices/cacerts/tcclass3-2011.der
http://www.trustcenter.de/certservices/cacerts/tcclass4-2011.der


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Julien, could you take a look at this bug and make
sure it is fixed in Mozilla 1.2 final?  Thanks.
Assignee: wtc → jpierre
Status: UNCONFIRMED → NEW
Ever confirmed: true
What build did you test this on ? You provided no build ID . Mozilla/4.78 isn't
Mozilla 1.2 . It seems like you used the facility to override the User-agent field.


Julien, Mozilla/4.78 is the user agent used to file the
bug report.  The build ID is Mozilla 1.2b (1.2beta).
In Mozilla 1.2 final, TC Trustcenter 2 & 3 are showing.
There are no TC TrustCenter 0 or 1 . 
Stephane, should these be included or not ?
Severity: normal → blocker
Severity: blocker → normal
Priority: -- → P2
Target Milestone: --- → 3.8
Version: unspecified → 3.6
Stephane,

This is a fairly old bug. We have TC TrustCenter 2 & 3 in NSS currently. Should
we have any others from them ? If not, please close the bug.

Thanks.

Please do NOT include the Class 0 root.

This root is for DEMO / TESTS,
so certificates are issued with _NO_ verifications.
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
What about TC TrustCenter 1 ? Is that something we want to have in Mozilla or not ?
OS: Windows NT → All
Hardware: PC → All
The Class 1 CA verifies only the E-Mail Address.

But at the moment it is the only one available for private use.

So it would be good if Mozilla has it.


BTW: We think about new root certificates (nothing short term...),
     having more extensions and a different DN.
     What extensions do you want a CA cert ho have,
     what extensions do you not want a root to have ?

Class 1 CA is still not implemented. 

Why?
Not sure if I can do anything about this bug. The Mozilla Foundation is NOW
discussing a new Certificate Authority policy to clarify which CAs certs should
go in.

This bug mystifies me.  I can't think of any other case where we let some
but not others of a root CA's certs into the trust list.  
Assuming these 4 classes correspond roughly to Verisign's 4 classes, 
I think they should be either (a) all in, or (b) all out.
I wonder who this CA dealt with at Netscape in the past.
Blocks: 233453
The blocking/dependency relationship for this bug was backwards.
I have corrected it.
No longer blocks: 233453
Depends on: 233453
Unlike the certificate authorities cited in other bug reports requesting their
certificates be added to Mozilla, TC TrustCenter is part of a company
(Betrusted) whose practices have been accredited by WebTrust.  Since this is a
recent acquisition (22 Jan 04), confirmation should be obtained from Betrusted
that TC TrustCenter does indeed follow the practices of Betrusted.  
Changed Summary to reflect the current problem.  

This bug seems somewhat different from the others that are blocked by 233453
in that this CA was apparently already approved, but only some of their 
certs went into the trust list.  This bug is really a bug, not a request
for enhancement.  

But I think 233453 must be resolved before this bug can be resolved.
Summary: Mozilla 1.2b has only one buildin object token: TC TrustCenter Class 2 CA → Some TC TrustCenter CA certs missing from mozilla
Blocks: 167572
No longer blocks: 167572
I have reviewed the online information relating to TC TrustCenter; see my draft
CA list at <http://www.hecker.org/mozilla/ca-certificate-list/> for references.
I think the major issue right now is whether TC TrustCenter is covered under the
WebTrust audit for BeTrusted or not. As far as I can tell from the online
information, TC TrustCenter never completed a WebTrust audit prior to its
acquisition.

I don't plan to do anything further with this request until I get more info on
the WebTrust question (or until we have a final policy, whichever comes first).
Status: NEW → ASSIGNED
Re-assigning this bug to me (forgot to do this before).
Assignee: julien.pierre.bugs → hecker
Status: ASSIGNED → NEW
FWIW, I spoke with an engineer of them to build the initial list of certs a few
years ago, and they *seemed* decent, made a good impression on me. Would be nice
to have/keep them on board.

Frank, this bug seems to be more of a technical nature, that some class certs
are (accidentially?) missing, not if TC should be in or not - it was already in.
Should we use another bug for the general TC inclusion?
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries
Why is this bug not fixed yet? It is really a technical bug, obviously the Class 1 certificate are somehow missing.
It appears that this bug is awaiting a decision by the mozilla foundation.
It appears that Frank last looked at this bug before the mozilla CA Cert
policy was finalized. It's a 5 year old bug, and I agree that it's time to
make a decision about this, and not leave it in purgatory.
Component: Libraries → CA Certificates
Product: NSS → mozilla.org
QA Contact: libraries
Version: 3.6 → other
QA Contact: ca-certificates
Given that the final policy does require an audit, it seems to me from comment #16 that we still need a clear statement about whether TC Trustcenter is covered by a WebTrust audit of some sort (either their own or a BeTrusted one).  If the TC Trustcenter representatives CCed on this bug could confirm the situation, we would be able to move forward. Otherwise, after (say) a month, this bug will be closed.

Gerv

I just called TC Trustcenter (it's a German company), concretely Bernd Kirsig (IT Security responsible) and Christian Drews (lawyer). We had a nice chat for one hour.

The bug here is partially resolved, partially bogus.
My own Mozilla Firefox build does show their Class 2 and Class 3 certs as root certs, in  Prefs|View Certs|Authorities.
Class 4 is not actively used by them.
Class 0 and 1 are test roots and should not ship as root certs.
In other words, all cert roots they need are already in.
Resolving WORKSFORME.

Regarding WebTrust:
Ownership of the company, directly or indirectly, has changed many times in the last 4 years, due to several big mergers in the CA market, funny story. They are currently owned by ChooseSecurity or similar, not any big CA.
At all points in the history, their technical/security operation has been completely independent, always in Hamburg, Germany.
They don't have a WebTrust audit, but a European one one that Microsoft considers "equivalent". I think the EV guidelines also require "WebTrust or equivalent". Our policy [1] is even more precise. They'd have to fill in whether their audit fulfills that, but I'd assume so.

I pointed them to this bug, maybe they'll comment as well.

[1] http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
I can comment on that.
Class 2 and Class 3 being in the browser is fine for me.
We also issue Class 0 and Class 1 but I would not call these classes trustworthy; so they are better kept out.

Speaking about audits: TC TrustCenter is accredited by the German Bundesnetzagentur as an issuer of qualified certificates in compliance with the German Signaturgesetz (German Signature Act).
Qualified signatures are (in a legal sense) equivalent to handwritten signatures.
In Germany the requirements for this accreditation are higher than in all other European countries.

We have not performed a Webtrust audit because there was no requirement for it; and it is quite expensive.
Currently we are preparing audits against the ETSI standards TS 102042 and TS 101456. Both of them are regarded by Microsoft Germany as being equivalent to Webtrust.

(In reply to comment #23)
> Currently we are preparing audits against the ETSI standards TS 102042 and TS
> 101456. Both of them are regarded by Microsoft Germany as being equivalent to
> Webtrust.

... and they are by the Mozilla policy.
>We also issue Class 0 and Class 1 but I would not call these classes
>trustworthy; so they are better kept out.

This is certainly true for Class 0 certs which are issued as (test) demo-certificates.

The Class 1 certs may be "not trustworthy" because there is no in-person validation BUT that is true in the same way for other Class-1 free E-Mail certificates (Comodo for example) which are indeed recognized by Mozilla products.

I don't see any problem to allow users of Mozilla products, especially Thunderbird to work properly with Trustcenter TCs Class 1 certificates by recognizing them as trusted root-certs. These Class 1 certs are for E-Mail security only and include a proper validation of the named E-Mail address but unfortunately they are not present in Mozilla's Mail-products.

Please don't mix-up them with Class 0 demo certificates which are per definition for testing purposes only and contain no validation at all.
I disagree. Email security can be far more critical than webshops.

The CA itself said they "would not call these classes trustworthy" and "they are better kept out", so there's nothing to discuss here. Please move on.
To add to Ben's comment: In general I believe that we should include a root CA certificate only at the request of the CA. After all, a CA is making certain commitments with regard to certificates that it issues: it has certain legal obligations, obligations to issue CRLs and/or run an OSCP responder, and so on. It's up to a CA itself to determine whether it wishes to take on those obligations for a particular use of its certificates (e.g., having them be included in mass-market browser or email client).

So if a CA does not want a particular root CA certificate to be included in Mozilla products (for whatever reasons, good or bad) then I believe we should respect that wish and not include the certificate.
I am sorry but I have to contradict for another time.

First of all I do not understand, why Trustcenter TC itself wants the Class 1 certs kept out although they should have a fair interest in gaining customers for their products. At the moment, the Class 1 root-certs are included in standard (which means Microsoft) software but not in Mozilla. Can somebody explain to me, why a billion-dollar company regards theses certs as trustworthy while mozilla corp. does not? It is a shame to have these compability-lacks, every (more experienced than average) user will be confused why certain e-mail security solutions perfectly working with Microsoft products cause problems with Mozilla software. Guess, who he will blame for it...

Secondly, I will try to answer the question of how trustworthy these certs are. Regarding S/Mime certs, different classes have to be distinguished. There are Class 1, 2 and 3 certs. While Class 2 and 3 usually mean identification based on  legal documents (therefore expensive), some trustcenters also offer free Class 1 certs for (personal!) usage. These ones are for end-users who want to secure their E-Mail transfer. Class 1 certs work very well for this, because a relatively reliable authentification is done based on checking the apllicant's e-mail adress. There is no authentification of the person itself but since these certs are for e-mail security and NOT for replacing handwritten signatures under contracts in business environments this is not a real problem.
As I stated before, there are only a few trustcenter issuing free e-mail certs. Most well-known of them are Comodo and TC Trustcenter which have both their root-certs included in Microsoft software for years now. Both of them offer free class 1 personal e-mail certs and their issuing procedure differs only very little. The main difference is that Comodo is included in Mozilla products, TC Trustcenter not. 
I am sorry but I cannot understand this paradoxon.
Hopefully, the employee of TC Trustcenter may explain here why he considers their class 1 certs as not trustworthy for personal e-mail usage?
Regarding
> First of all I do not understand, why Trustcenter TC itself wants the Class 1
> certs kept out although they should have a fair interest in gaining customers
> for their products. At the moment, the Class 1 root-certs are included in
> standard (which means Microsoft) software but not in Mozilla. Can somebody
> explain to me, why a billion-dollar company regards theses certs as trustworthy
> while mozilla corp. does not? It is a shame to have these compability-lacks,
> every (more experienced than average) user will be confused why certain e-mail
> security solutions perfectly working with Microsoft products cause problems
> with Mozilla software. Guess, who he will blame for it...

Never, NEVER cite MS as an authority on how things should be done.  Too many Web messes have been created on the basis of proprietary deviations in IE from the W3C HTML and CSS specifications.  Then there was the mess created when MS tried to implement their own non-standard Java; fortunately, Sun was able to knock that down before it went too far.  

David: that's not a particularly sound argument, because "what certs you include" is not covered by any standard.

However, the argument that, unless we have overriding reasons to the contrary and are prepared to accept the consequences, we don't include certs unless we are asked to by a CA is a good one. So this bug will remain closed. If a TC TrustCenter representative wants these certs included, they should ask. If someone who is not a TC TrustCenter representative wants them included, they should ask TC TrustCenter to ask.

Gerv
I do understand your reasoning, however I believe it is a shame for free software such as Mozilla to not support security related technologies which affect the so important end-user security.

SPAM and even more Phishing are exceptionally critical issues and S/MIME is at least an attempt to cover both of them.

If end-users use e-mail signatures and are aware of their advantages, then, some day the companies (banks, ebay, etc.) are forced to switch to signed-emails too.

But unless Mozilla stops blocking one of the two well-known free certificate-issuers, no one will go this way because he cannot be sure that the recipient uses Mozilla-software and therefore gets ugly warnings - unfounded warnings as I suppose.

Consider this: Comodo offers free S/Mime certificates as well and they contain name and E-mail address either, althoug no real identification takes place.
These certs are regarded as trustworthy by Mozilla. The Class 1 certs from Trustcenter which are nearly identicial (they use stronger encryption up to 2048bit than Comodo) however are not trustworthy.

This is no logic.
We are not blocking anyone. They are free to enter the store - they have only to ask. 

Your last paragraph would be a good argument only if we said we were "blocking" the certs on the grounds of the weakness of their encryption. But we are not doing that.

Gerv
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.