CaCert Certificates not installed

[iroli]

Binary package hint: evolution

Although CaCert.org certificates are part of the ca-certificates packages and installted on the system by default, evolution does not have them installed by default. One has to manually import them from either web or /usr/share/ca-certificates/...
They should be known to evolution by default.

[Jo-hermans (jo-hermans)]

--> Security/General

[Jea-enigma (jea-enigma)]

you must include

[Support-cacert (support-cacert)]

A lot of people that are emailing me in support of this RFE are stating that it
would be a good thing if it was included as they'd finally be able to convince a
lot more people of changing over to use mozilla on their networks instead of IE.

Can forward examples on request.

[Glen-arachnoid (glen-arachnoid)]

Security should be a right not dependent on your ability to pay.

[Jnysen (jnysen)]

There seems to be a lot of support for this.

It is free, and the referee system keeps it secure. Basically a clever
time/money tradeoff vs big guys like Thawte and Verisign.

[Peter-lairo (peter-lairo)]

Since this bug seems to be attracting several people new to bugzilla (that's
great), I would kindly ask that you read the following before posting any
comments: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

TIP: A good place to discuss the advantages are in the mozilla newsgroups:
news://news.Mozilla.org:119/netscape.public.mozilla.general
news://news.Mozilla.org:119/netscape.public.mozilla.security

[Bugzilla+nospam (bugzilla+nospam)]

This bug was filed against the incorrect product. Reassigning.

[Thomas Horsten (thomas-horsten)]

Especially in the light of VeriSign's excessive living up to their corporate
motto of "The Value Of Trust" with their *.com wildcard, I think it adds
emphasis to the need for a free alternative to the certificate providers.

[Caillon (caillon)]

.

[skyhorse (mail-skyhorse)]

Certification should not mean bribery.

As a user, I would trust more a certificate from CA Cert group than a
certificate from VeriSign or Microsoft , who are really only interested in the
money they get from it and not in my security.

Free Speach. Free Software. Free security!

paulo

[David-gigawatt (david-gigawatt)]

I'd just like to offer my opinion, that while *commercial* software's
dependence on commercial Certificate Signing Authorities seems appropriate to
me, Open Source software, such as (any of) the projects of The Mozilla
Organization, should *not* be depending solely on commercial entities to verify
the integrity of it's security model.

As others have pointed out, access to the primary benefit of SSL encryption and
security, which is *trust*, should not be restricted to only those who have
paid a fee for it. The mere existence of a commercial transaction between
someone and Thawte or Verisign or Network Solutions (--oh, wait.. those are all
the same company!) does not, or at least *should* not, in and of itself provide
the public any greater assurance that their systems are secure, that internet
transactions with them are safe, or that their identities are legitimate,
anymore than one's trust in the "authority" of the organization signing the
certificate would lead one to have in the first place.

It has been argued that a browser should not ship with *any* installed root
certificates, in order to force the user to realize that they must take the
responsibility to install trust certificates themselves, so that their software
is configured only to trust those whom they themselves have *chosen* to trust,
and whom they've chosen trust to vouch for the authenticity of others. That
is, after all, the entire point of certificate signing, as Phil Zimmerman wrote
in the original PGP documentation that introduced the world to public key
cryptography, [available from
ftp://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt] "You should use a public key
only after you are sure that it is a good public key that has not been tampered
with, and actually belongs to the person it claims to. You can be sure of this
if you got this public key certificate directly from its owner, or if it bears
the signature of someone else that you trust". For a software projects to
install these "trust keys" at all is presumptive at best, and at worst, itself
a technical breach, a security hole. But this is the situation that today has
become the de facto standard for browser software. Mozilla would be criticized
as insecure or incomplete if it did not include the root certificates that are
widely used today in the industry to verify the identity of web sites and the
privacy and integrity of visitors' encrypted communications with those sites.
But to limit Mozilla users, by default, to trusting only those same commercial
Certificate Authorities that Microsoft Internet Explorer trusts does a
disservice to Mozilla users, by lending credibility to the idea that these
companies are the only trustworthy guardians of safe, secure internet
communications.

Especially in light of the level of trust that some of these companies who are
in "the business of trust" have earned with the public so far, the need for a
reliable, trustworthy, not-for-profit Certificate Authority like CACert.org has
been sorely felt by those of us who understand that by installing a root
certificate in our browsers (and email clients, web and mail servers) we're
delegate...

[Chofmann (chofmann)]

to late to try and do anything for this in 1.6.

[Chofmann (chofmann)]

here is a summary of the policy in the works that we may use going forward.
frank can update on more details

Distributors can add or delete certs and modify trust bits on certs in the
default db. On a case-by-case basis, MF will decide whether such changes affect
distributor's right to use Mozilla trademarks. See the trademark policy [does
this exist yet? /be].

MF requires all CAs (a) be root CAs; (b) offer services to the general public;
(c) provide public info about CA and (d) its policies and procedures. MF may in
addition include root CAs that do not provide services to the general public
(e.g., for an intranet customer). MF won't distribute non-CA-certs (e.g.,
self-signed web server certs).

Any CA not in the list can mail <email address hidden> and apply to be
considered for addition, giving needed info: (a-d) above, plus various contact info.

MF won't charge for adding CAs, but welcomes donations.

[Helm-fionn (helm-fionn)]

For comment #14:
<email address hidden> bounces

Michael Helm (<email address hidden>)
ESnet/LBNL

[Vdvo (vdvo)]

What's holding this? Is it just waiting for someone to come up with a patch, or
for someone's decision?

[Bugzilla-alanjstrbugs (bugzilla-alanjstrbugs)]

Has the CA applied for consideration per comment 14 (assuming that the emails
don't bounce)

[Kk-kjernsmo (kk-kjernsmo)]

(In reply to comment #17)
> Has the CA applied for consideration per comment 14 (assuming that the emails
> don't bounce)

Yes, they have. I dropped them an e-mail last night, and I got a nice response
with the two e-mails they sent. And they said the e-mails hadn't bounced either.
But perhaps the address isn't read...?

[Christian-barmala (christian-barmala)]

On Thursday, January 08, 2004 10:31 AM
I replied to C. Hofmann (Comment #14)

On Friday, January 23, 2004
I sent an email to <email address hidden>

and answered most of the questions by reference to CAcert pages:

a) yes we are a root ca
  Root certificate: http://www.cacert.org/index.php?id=16
b) Mission Statement: http://www.cacert.org/index.php?id=2
c) About CAcert: http://www.cacert.org/index.php?id=0
d1) Policy: http://www.cacert.org/index.php?id=10 ,
d2) Privacy statement: http://www.cacert.org/index.php?id=1
Contact: http://www.cacert.org/index.php?id=28

Until now, I didn't get a reply.

[Hecker-mozilla (hecker-mozilla)]

My sincere apologies. I suspect that I may have been the bottleneck here -- I'm
the person tasked with developing the mozilla.org policy on inclusion of root CA
certs, and with approving noot root CAs for inclusion. Unfortunately between
work, my wife's back surgery, and caring for a 17-month old child I have fallen
badly behind on both getting the policy completed and approving any new CAs.

In any case, I have looked over the documentation provided for CAcert, and I
approve of including their root CA cert in Mozilla. I'm not the person who does
the actual work, but I'll send that person an email to tell them to go ahead and
include the cert as soon as possible.

Again, I'm very sorry for the severe delays in getting this issue resolved.

[Daragao (daragao)]

(In reply to comment #14)
[snip]
> MF won't charge for adding CAs, but welcomes donations.

As someone interested in the inclusion of CAcert certificates I have donated to
MF in the early days of January (2/Jan/2004) - $15.00 USD.
I'm glad the inclusion will be done.
Thanks

[Leaf-mozilla (leaf-mozilla)]

I'm investigating how to include a new CA, as it seems Wan-Teh might be busy at
the moment. It is a high priority to get this included in the 1.7a timeframe.

[Nelson-bolyard (nelson-bolyard)]

The criteria listed in comment 14 above are clearly inadequate.
By those criteria, anyone who has the slighted idea how to use openSSL
and claims to be willing to issue certs publicly, qualifies. Allowing
such into mozilla's source would be a disaster, completely discrediting
mozilla's crypto-based security.

There are internationally accepted standards for CAs, and IINM there is
an organization that tests CAs for adherence to those standards.
Perhaps mozilla's acceptance criteria should include them.

[Bugzilla-bppb (bugzilla-bppb)]

Are you merely passing comment on #14, or are you suggesting that as a result
of #14, CaCert should not be eligible?

'MisterSSL'? You don't happen to work for a for-profit SSL Cert rip-off
merchant by any chance do you?

[Nelson-bolyard (nelson-bolyard)]

No, I don't work for a public CA.

I happen to be one of the ~5 engineers who actually develops and maintains NSS.

Do you happen to be one of the
"I care nothing about PKI, I just want to have free certs" crowd?

[Iang-iang (iang-iang)]

The criteria listed in #14 are entirely appropriate given that Mozilla is not a "franchise"
trying to make money, nor charge money. As Mozilla presumably desires to avoid any
liability, it should not pretend that the practices of any of the certificate issuers, or any
standards body, are endorsed. Anyone who wants to be a certificate issuer, can be, as
long as they disclose their practices.

Mozilla needs to work with the limitations of the crypto-based security standard,
HTTPS/SSL. Within that legacy, accepting top level certs on a minimal basis, and
accepting self-signed certs on websites, is probably the best way forward as it would
encourage the use of free crypto.

[Support-cacert (support-cacert)]

Should CAcert also adopt the practise of charging $300/year and requiring
business registration before issuing certificates?

The current PKI industry is VERY scarey, the body issuing "certification" to
certificate authorities uses accounting practices and anyone with $250,000 and a
good lawyer can be certified... This has very little to do with technical
competence and more to do with fact they are trying to milk the industry for
substantially more money then certificates really should cost, just like the
domain industry before it was allowed to have other registrars, I suppose you
think US$70 for 2 years for a domain is a good deal too then?

CAcert has said all along that is may charge for some certificates on a cost
recovery basis, so your argument about free certificates is also incorrect,
however it won't be anywhere near the $50/year it currently costs, closer to $10
or less, and that would be for wildcard certificates not on a per host basis,
but that is debate for another day, and would relate to businesses wanting more
information then the hostname on their certificate...

[Bugzilla-bppb (bugzilla-bppb)]

> Do you happen to be one of the
> "I care nothing about PKI, I just want to have free certs" crowd?

No, I'm not; Duane has accurately portrayed my similar feelings on the matter.
I'm not objected to paying a reasonable fee; I just object to being bent over a
barrel and taken from behind by a company that quite frankly doesn't deserve my
money. A number of corportate certificate issuers are, quite frankly, not worth
the paper it'd use to print out their terms and conditions.

Certification/approval means nothing if there is no re-evaluation of the
system, which there doesn't appear to be any mention of. Things such as one of
the big-name CAs not being able to find documentation provided as proof of
identity (claiming it is in an 'archive') when it comes to renewing a cert
comes to mind.

[Nelson-bolyard (nelson-bolyard)]

Any bug that requests that a CA cert be added to mozilla MUST have the
proposed new CA cert(s) attached to it. Otherwise, the requestor is
rudely asking the mozilla developers to find the cert to include it.

The American Institute of Certified Public Accountants, and their Canadian
equivalent, have jointly established a set of criteria for root CAs.
They have a program for testing CAs to see if they pass muster.
They "attest" (as opposed to certify, they're not a CA) that the third
party CA meets their standards. You can read more about this program here.

http://www.aicpa.org/webtrust/caexec~1.htm

Microsoft also uses this standard for CAs. You can read about that here:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/rootcert.asp

I have no opinion about the worthyness of the particular CA being proposed
in this bug. I don't know who it is yet. But my question would be:

Does webtrust "attest" to this CA?

I think that should be one of the criteria.

PKI is about TRUST. All root CAs that are trusted for (say) SSL service
are trusted EQUALLY for that service. If we let a single CA into mozilla's
list of trusted CAs, and they do something that betrays the publics' trust,
then there is a VERY REAL RISH that the public will lose ALL FAITH in the
"security" (the lock icon) in mozilla and its derivatives.

We don't want that to happen. If that happens, mozilla's PKI becomes
nothing more than a joke. If you want to see mozilla's PKI continue to
be taken seriously, you will oppose allowing un attested CAs into mozilla's
list of trusted root CAs.

[Support-cacert (support-cacert)]

Should we bring up verisign at this point issuing certificates to social
engineers?

The public should have lost all TRUST in verisign at point in time, instead
nothing happened... TRUST as defined in CPS documents, has nothing to do with
trust as most people consider it, nothing at all to do with trusting the pki
process at all.

The certification processes as I stated before are all about policy documents,
nothing more nothing less, and yes I have seen and read those pages before along
with a lot of others.

Also another good read is...

The Shocking Truth About Digital Signatures and Internet Commerce
http://www.totse.com/en/technology/cyberspace_the_new_frontier/162023.html

And for further reading...

Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure

http://www.counterpane.com/pki-risks-ft.txt
http://www.counterpane.com/pki-risks.pdf

[Nelson-bolyard (nelson-bolyard)]

Frank, Re: your comment 20
One of the most (if not *the* most) important criteria established by AICPA
for CAs is the measure of care they take to protect their private keys.
I found nothing about this using the links from comment 19 above. Did you?
Are you willing to approve a CA that doesn't address AICPAs requirements?

[Support-cacert (support-cacert)]

(In reply to comment #31)
> Frank, Re: your comment 20
> One of the most (if not *the* most) important criteria established by AICPA
> for CAs is the measure of care they take to protect their private keys.
> I found nothing about this using the links from comment 19 above. Did you?
> Are you willing to approve a CA that doesn't address AICPAs requirements?

Thankyou for the feed back, while were are via'ing for inclusion it's this kind
of responses we were after, we are constantly updating our documentation to
accomodate requests such as this, we want to operate in a manner as transparent
as possible.

We will endevour to get this additional information to the website as soon as
humanly possible, however like Mozilla, we too are a non-profit, community run
organisation, that doesn't mean the quality of either organisation is any less
then alternative commercial offerings.

[Kk-kjernsmo (kk-kjernsmo)]

I hope that continuing this debate here on Bugzilla is appropriate, I guess it
is since actually implementing the fix is trivial.

Clearly, this is problematic. On one hand, you have Verisign that has so
thoroughly discredited itself, with such a huge array of mistakes, that if we
had any clear standards, Verisign root certificates should be removed by now.
Furthermore, if AICPA had any real meaning, they too would have discredited
Verisign. When this has not happen, at least it means to me that the AICPA seal
of approval doesn't mean anything at all. Nothing. Besides, would you trust an
organization which use caexec~1.htm as a filename, has "best viewed with"
statements and distribute their statements as Word documents?!? Deep
understanding of technology? Security? Sure...

But Nelson's points are still valid, one mistake on CAcert's part, and you may
have the press all over the place. It may not matter that Verisign is worse,
because that is not the spin that'll be in the media. Indeed, his point is very
valid, one mistake on CAcert's part may very well undermine the public's trust
in Mozilla.

As others have pointed out, there is no good reason to trust a CA. It's a "uhm,
just because" kind of thing. It's something you use because it is widespread and
 the only real option, not because it is good. Given that the company with the
largest market share has goofed so badly, this isn't about real security at all.
If you want real security, you're on your own.

But this also tells us that there isn't any particular reason why CAcert should
be any worse than the market leader. They want to provide us with a free service
and strengthen the community, and they may well do it better than the company
with the greatest market share.

Also, that AICPA doesn't seem to be an organization to be trusted, doesn't mean
that it couldn't have produced a reasonable spec, it only means that $250,000 is
money out the window (and that the people who produced the spec doesn't have any
real influence on how to run the business, which seems not a very unusual
situation).

So, what it alls boils down to is that CAcert needs to produce a policy that the
developers find satisfactory. Let's not rush it. Those who feel a need for
CAcert certificates should get involved with them to produce a good policy.
AICPA's recommendations could form the basis for the policy work, but the
objective should not be to satisfy AICPA (because it clearly means nothing), but
to satisfy NSS developers.

[Daragao (daragao)]

(In reply to comment #33)
[snip]
> So, what it alls boils down to is that CAcert needs to produce a policy that the
> developers find satisfactory. Let's not rush it. Those who feel a need for
> CAcert certificates should get involved with them to produce a good policy.
> AICPA's recommendations could form the basis for the policy work, but the
> objective should not be to satisfy AICPA (because it clearly means nothing), but
> to satisfy NSS developers.

I don't think people are rushing it, remember that this report was opened on
2003-08-06. Although I agree that nobody wants to force anything. NSS/PKI
developers have be convinced by CAcert that the system is secure and works
smothly. This is a matter os developers expressing their doubts and CAcert
answering them. Let's hope an agreement can be reached.

David

[Hecker-mozilla (hecker-mozilla)]

Questions about the appropriateness of the proposed CA policy really should be
discussed in some public forum (e.g., the Mozilla crypto mailing
list/newsgroup). I plan to start such a discussion once I have a real draft
policy, but unfortunately I haven't had time to finish that up yet. In any case,
I'll make the following semi-random points right now:

* Historically mozilla.org has delegated the process of selecting root CA certs
to a third party (Netscape/AOL). That's no longer appropriate IMO, so we have to
make some decisions about how best to do this in the context of the Mozilla
Foundation and the Mozilla project as a public open source project. This debate
is part of that decision process.

(To my knowledge Netscape never published its own policies on accepting CAs. So
while we may be now discussing criteria for including new CAs, there's also a
separate issue of what to do, if anything, about all the CAs whose certs are
already included in Mozilla. We should also discuss this at some point;
otherwise IMO we're simply letting the already-included CAs off the hook, and
discouraging new CAs based on criteria that weren't necessarily applied to the
old CAs.)

* For the moment the Mozilla Foundation is dependent on volunteer labor (e.g.,
me) to take on the task of selecting CAs. No one is getting paid to do this, and
no one is going to be paid to do it for the foreseeable future. So we have to
evaluate potential policies in light of the resources (e.g., my and others'
volunteer time) required to implement them. In that context having a relatively
liberal and easy-to-apply policy is attractive.

(Of course we can also imagine leveraging the efforts of other volunteers, as in
the Mozilla project generally; see also below.)

* From my experiences with FIPS 140-x and Common Criteria evaluations I am well
aware that "security as certified" and "security in reality" are not always the
same. So while it may be good to look at formal third party certifications of
CA, I think such certifications should not be the only criteria for selecting a
given Ca for inclusion, and I think lack of such certification should not
necessarily disqualify a CA from being included.

* IMO there's a real question of what question of what to do (and what can be
done) about problems with CAs that get selected for inclusion. Some of the
comments in this bug imply that we're dealing with a "brittle security"
situation here: that one mistake on selecting a CA for inclusion could lead to a
total meltdown in terms of user trust of Mozilla (or, alternatively, it could
lead to a significant lessening in user trust in the whole PKI setup around
SSL-enabled web servers, etc.).

Is this really the case? In a related areas, the presence of security
vulnerabilities in Mozilla hasn't led to a breakdown in user trust in Mozilla;
in fact, Mozilla seems to have a better reputation in this area than competitive
products like IE. IMO this is not all due to the care taken in Mozilla design
and implementation; it is also a function of the process the Mozilla project
uses for handling vulnerabilities once found.

Is it possible and desirable to take the same approach here? In other words, ...

[Nelson-bolyard (nelson-bolyard)]

Frank I agree with nearly all your points in comment 35. I would add that

* if the mozilla foundation gets into the position of establishing its own
selction criteria, and become its own filter of acceptable CAs, then it
may be liable for its choices. (I am not a lawyer, and don't pretend to be)
OTOH, if it instead relies entirely on the attestation of another body
(be it AICPA or someone else), then potentially the liability issues transfer
to that other body. That's part of the reason why I proposed that mozilla
rely on AICPA. If I had known of others trying to do the same thing, I might
have included them in that recommendation too.

* about the brittle/meltdown issue, and referring to the links in Duane's
comment 30 above, I think part of the reason those articles were written
was to deflate the public's expectations of web security somewhat, to try
to avoid a "significant lessening in user trust in the whole PKI setup
around SSL-enabled web servers" (quoting Frank).

Much of the public still mistakenly thinks that the lock icon implies that
the party who runs the server whose page you're viewing is trustworthy.
Of course, it doesn't mean that and never has.

* Regarding the notion to "divide efforts between an initial selection process
and a post-selection process for dealing with CA-related problems", I would
say this. Browsers last a long time. There are still people running C4.x.
Most browser users NEVER even DISCOVER the "Certificate Manager" by which
they can add or remove CA certs from their browser. The browser lives with
its initial set of CAs for its entire lifetime in their profiles. It's
relatively easy to add CAs, and almost impossible to get the public to take
out a CA that has been deemed a rogue after the fact. In short, I think it's
not practically feasible right now to ever "revoke" a root CA cert that's
out in the field in mozilla executables. So, I think mozilla should continue
to put a high effort up front.

OTOH, The idea of an Uber-CA keeps coming up. Someone might offer a CA-like
service with a server that will answer in real time (ala OCSP) the question of
whether a certain root CA is still trustworthy. If the service was offered
and available, mozilla could surely be made to act as a client for it.

I invite all to discuss this further in the public newsgroup
news://news.mozilla.org:119/netscape.public.mozilla.crypto

I can't think of a more ON-TOPIC discussion for that group that this one,
and news.mozilla.org is MUCH better prepared to handle hundreds of discussion
participants than bugzilla.mozilla.org is. (I'm referring to the 320+ member
CC list this bug has now!) Please join me in that group!

I'll start by posting there a list of issues I'd want to see a CA address to
earn my trust (as an end user).

[Support-cacert (support-cacert)]

Why should money be such an entry criteria? And if Verisign can make such
blatent mistakes we have heard about, what have they or other CAs done we
haven't heard about? And with Verisigns blatent snubbing of everyone everywhere
with their sitefinder service, who's to say they wouldn't do equally dodgy
things to sell certificates for overly inflated prices as well? And if there is
no threat of being revoked what would they care in any case?

In other words a CA trying to be acredited by AICPA can lie through their teeth
on their CPS/policy statements, get established for a few years then do whatever
the hell they like for a buck and nothing will happen to them? What if anything
would happen to AICPA? If they don't request browsers revoke for blatent
breaches that's merely buck passing and all you do is stick your head in the
sand, with your fingers in your ears going la la la la till all the bad press
goes away, is this really being responsible netcitizen after all, or just
shifting blame when shit hits the fan? to an organisation that does nothing, and
has no say after the fact.

I agreed with Frank about pre and post, after all if there is no wacking stick
there is no incentive to be a good corperate citizen.

OCSP for check revoked CAs sounds like a pretty good idea to me, it would reduce
the time that any breaches could spread.

Well SSL shouldn't be trusted as the sugar coated version some companies put
out, there are flaws in all systems where people are involved, for any number of
reasons and intentions. The security itself is fine, but the actual CA processes
well unless there was an indepth study, something I doubt Frank or many have the
time to do on a volunteer basis, then we are all in serious trouble, see above
with my comments about AICPA.

[Support-cacert (support-cacert)]

I forgot to note why should ssl be purely about ecommerce, there is no dollar
value in me using SMTP-TLS, however it's been more then proven home cable
networks and wireless networks are extremely vulnrable to sniffing, CAcert
sprung up to help provide end to end encryption for connections over wireless
networks, and not just for web pages...

[Nelson-bolyard (nelson-bolyard)]

The answers to the questions raised in comments 37 and 38 may now be found in
news://news.mozilla.org:119/netscape.public.mozilla.crypto
Please take this discussion there.

[Iang-iang (iang-iang)]

(In reply to comment #33)
> But Nelson's points are still valid, one mistake on CAcert's part, and you may
> have the press all over the place.

One needs to be aware of where the failure is here. It is not, or will not be, on CACert's
part.

The failure is in the PKI design.

(As Peter Gutmann points out that) there is one security policy within browsers, and it is
shared amongst all CAs. That is, when a browser encounters a cert from a website, it
accepts the signature on that cert from *any one* of the CAs that happen to be in its
database.

This means that any CA can cause breaches. It also means that all security statements
are homogonised to one level. Lowest common denominator, if you will. It matters not if
one CA has a high standard, if another has a low standard.

In this environment, there are two choices - either set a high standard, and *stick to it*,
or, set a low standard, and don't rely on the results.

Setting a high standard is the choice of CAs that are trying to make a business of this.
But, regardless of their attempts to do this, it is implausible to believe that all of those
hundred or so top level certs are in fact managed and protected according to some
high standard.

The high standard approach implies that Mozilla and every other browser maker has to
vet and approve every CA, and monitor them along their life cycle. It's not adequate to
simply shift the burden to some standards body like a club of accountants, unless one is
paying them money to do that, and one is then vetting their activities.

The alternate, setting a low standard, is more realistic. Firstly, it's cheap in terms of time
and effort. Secondly, there are no unrealistic nor unrealised expectations. Thirdly, it is
aligned to the security delivered by browsers.

(SSL security as delivered within HTTPS between browser and server is vastly
overrated in its efficacy. There are no reportings of MITM attacks over unprotected
credit card transmissions, and in practice, the vast majority of attacks on browser users
bypass and ignore the SSL barrier (successfully). That is, there is no practical threat
that needs certificates, and, at the same time, there are real life losses occurring daily
due to the browser's poor security model.)

In this context, it only makes sense to set a simple minimal set of rules for new CAs to
be vetted by. Something that can be checked by one guy in less than an hour, maybe.

In the meantime, there is a lot of work needed to add security to the browsing domain.
It involves migrating the CA-cert regime across to the approach of SSH, and
incorporating GUI enhancements, and drawing the user more into the security model.
There was a rather fine paper on this done in 2001 or so, which was got working in
Mozilla, but I lack the references for it.

iang

Interesting links:
http://www.cs.auckland.ac.nz/~pgut001/
http://iang.org/ssl/

[Dtownsend (dtownsend)]

*** Bug 436789 has been marked as a duplicate of this bug. ***

[Earle Martin (earlemartin)]

(In reply to comment #164)

For reference to readers, http://www.cacert.org/src-lic.php now displays the GPL v2, so CAcert appears to meet the definition of free software.

[C de-Avillez (hggdh2)]

Thank you for reporting this bug and helping make Ubuntu better. We have set this bug as wishlist, and opened http://bugzilla.gnome.org/show_bug.cgi?id=542436 upstream. Please comment upstream on this.

[Eriks-eglitis (eriks-eglitis)]

I represent Latvian State Joint Stock Company Latvia Post, which is owner of brand e-me (www.e-me.lv), under which it delivers CA cervices.
We are Trusted Certification Services Provider according to local and European laws for 2 years now, what can be verified at Latvian Data State Inspection (www.dvi.gov.lv, Trusted service providers list: http://www.dvi.gov.lv/edokumenti/pak_sniedz/). We do have our Root Cert included in MS IE Trusted Roots List.
We do follow following standards in our practice: ETSI TS 101 456; ETSI TS 102 023; ISO/IEC TR 13335-1, 2, 3; CWA 14167-1:2004; CWA 14167-2:2004; CWA 14171:2004.
Our certificates are located here: http://info.e-me.lv/en/atbalsts/CA_sertif/index.html
Our policy documents are available here: http://info.e-me.lv/en/pakalpojumi/dokumentacija/politikas/index.htm
Our compliance to standards, required to be followed by Latvian law, is verified by independent auditor (KPMG), using WebTrust for CA assessment methodology. Audit report is available upon request.

Therefore we would like you to consider inclusion of Latvia Post Root CA certificate in Mozilla.org CA list.

[Dirkjan Ochtman (dirkjan-ochtman)]

Erix: what the hell does that have to do with CAcert root cert inclusion?

Please file your own bug.

[Gervase Markham (gerv-mozilla)]

djc: that was unnecessarily offensive. Please be a little more understanding, OK?

Eriks: please see https://wiki.mozilla.org/CA:Root_Certificate_Requests for details of how to get your root included. Thank you.

Gerv

[Eriks-eglitis (eriks-eglitis)]

djc: I luv u 2!

Quick reading of http://www.mozilla.org/projects/security/certs/policy/ left impression, that I just file my req against the "CA Certificates" component; that text does not specifically say I should create my own bug.
So I opened bugzilla, found open item w matching 'component', and fired ahead... :-)

Thanx Gerv 4 helpful link!

Sorry guys 4 mixing up your thread! :-)

Peace,
Erix.

[Bernie Innocenti (codewiz)]

(In reply to comment #165)
> Marking as VERIFIED, with the understanding that we (CAcert, I'm a CAcert, Inc.
> member) will open a new bug when the audit is done.

It's been more than one year now. Is the audit done or does it need some more time? In the latter case, what's the ETA?

Thanks.

[David-rossde (david-rossde)]

Re comment #174: This is a closed bug report (reason: INVALID). CACert indicated (comment #165) they will submit a new bug report when they are indeed ready in terms of the Mozilla policy. Further comments on this report are inappropriate.

NOTE: Only certificate authorities (CAs) can submit bug reports to request addition of their root certificates to the Mozilla database. (Item 14 under <http://www.mozilla.org/projects/security/certs/policy/>.)

[Reed Loden (reed)]

(In reply to comment #174)
> It's been more than one year now. Is the audit done or does it need some more
> time? In the latter case, what's the ETA?

Audit is not done. See http://wiki.cacert.org/wiki/Audit.

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

*** Bug 475829 has been marked as a duplicate of this bug. ***

[Joel Goguen (jgoguen)]

Thank you for reporting this bug and helping make Ubuntu better. This bug has been reported upstream to the Mozilla Thunderbird bug tracker at https://bugzilla.mozilla.org/show_bug.cgi?id=475829. Please comment upstream on this.

[C de-Avillez (hggdh2)]

cacert.org has not yet fulfilled the MF requirements for inclusion as a root CA. Please see mozilla bug 475829, and the original mozilla bug 215243 for details on the MF requirements.

As such, marking as triaged/wishlist.

[C de-Avillez (hggdh2)]

The same happens with Evolution: Evo depends on NSS, from MF. As such, when MF accepts cacert.org as a CA, Evolution will also have it.

[Trev-moz (trev-moz)]

*** Bug 477787 has been marked as a duplicate of this bug. ***

[C de-Avillez (hggdh2)]

I am not sure this will ever be resolved, if left for upstream: Mozilla requires some actions from cacert.org, and cacert.org is taking a sweet long time to respond (or comply with MF requirements); Evo upstream is tending to consider this, then, as NOTGNOME (which makes sense).

And the Ubuntu users are still stuck.

Perhaps this could be set as a local patch on Ubuntu. But, probably, this will have to be discussed and agreed upon by the Ubuntu council.

[Alejandro Mery (amery)]

Mozilla requirements are thought for companies. CAcert.org clearly doesn't have the money or the human resources (they are all volunteers!) to write the policies (legal texts), perform a deep audit, reimplement it's software to follow all those new policies, and do the procedures related to the DPA in matter of months as companies with a much lower security level but with dedicated HR and large budget can.

http://iang.org/papers/open_audit_lisa.html
http://wiki.cacert.org/wiki/AuditToDo

[Micah Gersten (micahg)]

Moving to thunderbird package as the current mozilla-thunderbird package is for TB1.5 is no longer receiving patches.

[Webmaster-n4cer (webmaster-n4cer)]

Ca Cert does so much to grant trusts. You really should read the rules and implement it.

A warning that the sites can't be trusting can cause big damages to web presences. If you do not want to accept them, then please consider to change the "warning" message.

I do not see any reason why I should support money making of those "special" companies, only to get a highly paid signature. The payment does not grant any more security, at all!

[Eddy-nigg (eddy-nigg)]

(In reply to comment #179)
> I do not see any reason why I should support money making of those "special"
> companies, only to get a highly paid signature. The payment does not grant any
> more security, at all!

Markus, there are alternatives these days which don't require any fees for perfectly valid certificates. You are absolutly right that payments don't provide better security it all!

Check out https://www.startssl.com/ , I hope this helps.

[Paul Bryan (pbryan)]

@Markus: *You* don't have to support the for-profit companies if you don't want to. You can personally trust any CA you like, and reap the benefits/pitfalls of such decisions. It would be unwise to make trust decisions based on some misplaced desire to "stick it to the man."

Mozilla is making trust decision on behalf of all of its users. Its criteria should be based on the operational practices of the CA and RA. I don't think how profitable the entity is would even be a consideration.

As to the warning message, it's intended to protect the user first, not the web property. If result is "big damages" as you say, then presumably such large damage can be mitigated by such a web site selecting a CA that Mozilla trusts, for very little (even even no) money.

[Marcus-wolschon (marcus-wolschon)]

"then presumably such large
damage can be mitigated by such a web site selecting a CA that Mozilla trusts"

That is not an option for everyone.
Please name me one cheap or free CA that supports
vhosts (SubjectAltName) that is trusted by Mozilla.
Having more then one domain on one IPv4 is quite
common and it works very fine with CACert but
commercial ones charge you an arm and a leg for this
(every year and every time a subdomain is added/removed).

[Eddy-nigg (eddy-nigg)]

Marcus, sorry for the advert, but you really should look at this: https://www.startssl.com/?app=2

(One time very reasonable fee, unlimited certificates, unlimited domains and sub domains in SAN, wild cards)

[Kairo-kairo (kairo-kairo)]

1) Advertising a different CA in a CA inclusion bug is probably not too nice.
2) Nobody just does "not want to accept" CAcert at Mozilla, they just need to undergo an audit as said here in this bug report, and they are in the process of doing that, it just takes more paperwork and time than anticipated, from what I hear.

Please don't spam that bug with comment about who can or cannot do what, it doesn't help inclusion of CAcert any further.

[Paul Bryan (pbryan)]

@Marcus: If it's not an option for such parties, then it must not be causing the extensive damage that you portray.

[Eddy-nigg (eddy-nigg)]

(In reply to comment #184)
> 1) Advertising a different CA in a CA inclusion bug is probably not too nice.

Kairo, comment 182 explicitly asked for it. :-)
But my comment is certainly meant to be helpful - StartCom has been working hard to provide an viable alternatives to the Internet community.

> 2) Nobody just does "not want to accept" CAcert at Mozilla, they just need to
> undergo an audit as said here in this bug report, and they are in the process
> of doing that, it just takes more paperwork and time than anticipated, from
> what I hear.

That's complete nonsense. If it's just paperwork Mozilla wouldn't need it. As such CAcert has been promising an audit for years, but apparently it isn't that easy to satisfy this requirement.

[Cedric-corazza (cedric-corazza)]

(In reply to comment #186)
This is really not the place to advertize for your company.
As a reminder, Gerv wrote a very detailed post on his blog some time ago: http://www.gerv.net/security/self-signed-certs/

[Rich-thefreemanclan (rich-thefreemanclan)]

(In reply to comment #187)
> This is really not the place to advertize for your company.
> As a reminder, Gerv wrote a very detailed post on his blog some time ago:
> http://www.gerv.net/security/self-signed-certs/

Uh, if Security = Encryption * Authentication, then is it a valid bug to note that firefox fails to display a nasty banner every time a user browses a site that doesn't use SSL? In theory that is just as dangerous as a site that uses SSL with an untrusted certificate.

Don't get me wrong - I'm fine with informing the user about the security of a website, but it seems wrong to me that a site that uses no encryption or authentication at all is treated as perfectly safe when a site that uses strong encryption but a questionable form of authentication is treated as being extremely dangerous.

[Eddy-nigg (eddy-nigg)]

(In reply to comment #188)
> Uh, if Security = Encryption * Authentication, then is it a valid bug to note
> that firefox fails to display a nasty banner every time a user browses a site
> that doesn't use SSL?

Did you already try the upcoming beta for FF3.5? More positive indicators are produced by the UI now.

> Don't get me wrong - I'm fine with informing the user about the security of a
> website, but it seems wrong to me that a site that uses no encryption or
> authentication at all is treated as perfectly safe when a site that uses strong
> encryption but a questionable form of authentication is treated as being
> extremely dangerous.

There is a setting in Firefox to warn always before submitting any data over plain text. It's extremely useful to prevent sending information unsecured.

[Nelson-bolyard (nelson-bolyard)]

STOP! This bug report is NOT a discussion forum. It is NOT a place for
people to advocate for the inclusion of some CA they like. There are
mozilla newsgroups for that, such as mozilla.dev.security.policy.

According to Mozilla policy, ONLY official representatives of a CA can apply for that CA to be included. This bug is EXCLUSIVELY for use by those official
representatives of the CA applicant and the people whose job is to evaluate
applications for inclusion and implement them if they pass the criteria.
It is for those people to track the work in progress to that end.

In this case, CACert has WITHDRAWN its request for inclusion. See comment 158.
Ian Grigg, the auditor for CACert, officially withdrew the request for
inclusion until the audit is completed satisfactorily.

At such time as CACert passes its audit, an official representative for CACert will undoubtedly file a new bug, making a new request for inclusion. Until
then, there is NOTHING MORE TO BE SAID IN THIS BUG!

[Micah Gersten (micahg)]

Upstream bug changed.

[Micah Gersten (micahg)]

Per upstream, this request can only be made by CaCert. Please report any other bugs you may find.

[Sid-bugzilla (sid-bugzilla)]

*** Bug 546881 has been marked as a duplicate of this bug. ***

[Thomas Zahreddin (thomas-zahreddin)]

it is unbeliveable for me that this issue is discussed since 2003 !! and it is not solved until now -> just import the certificates and it's done.

This is not a question to be discussed in that length.

Do people need this certificate?
Yes, sure.

Is it easier for users if the certificate is delivered as all the other certificates?
Yes, of course.

So why not?
Why from certain Instances like cacert? (Btw. how do you check there identity?)

i can't understand issues like this…

[David Ayers (ayers)]

Even if cacert.org cannot be installed by default, there should by an end user application to manage the certificates so that they can easily be made available all applications (or specific applications for bonus points).

Currently one needs to import the certificate via Firefox, export them to files and import them info evolution. That's not feasible for the average user. What's even worse is that FF does not add the file extensions that evolution expects.

[Atowehvd (atowehvd)]

Australis es para niños, desarrollados de gays Mozilla UX gallos cabrones chupa! Profundizar en el culo de Google maldito idiotas descerebrados austhistic! Pendejos! Putas! Cocksucking Freaks Google! Vete a la mierda y salir del negocio Googlezilla putas! Y tomar Australisfuck con ustedes Gaylords! Que nuestro Amado Señor Dios y Jesucristo enviar sus cuerpos en descomposición directamente al infierno para tocar las Comunidades huevos de oro de la gloria! Vete a la mierda y besar Googles Ass! Si te gusta Chrome tanto en la clonación con Australis, hay que ir en serio y trabajar para Chrome Fucktards! Saludos desde España, ChiliConCarne1

[Jörg Frings-Fürst (jff-de)]

Bug from 2008. Version not longer supportet.
Change status to Invalid

[David Ayers (ayers)]

I can confirm that this issue still exists in Evolution 3.2.3 provided by 12.04 LTS

But I don't want to reopen this issue /in Evolution/ ... at least not quite yet, as I'm not sure it belongs here (or not just here).

I believe the correct approach would be to have an application like seahorse manage the CA's that a user trusts and then have other applications like Evolution, Thunderbird, Firefox, Epiphany, ... defer to gnome-keyring to verify the key's and CA's that a user trusts.

I'm uncertain whether gnome-key or seahorse have any support for CA's and I fear that most CA handling is within each application as is the case for Evolution. But then the handling of CA files must become much simpler that what is currently offered.

[Jörg Frings-Fürst (jff-de)]

Hi David,

I think thats not a problem of evolution.

CAcert's class 1 rootcertificat has only a md5 encryption and all audits failed. Therefore, the not recognized by mozilla

A all in one certficat - handling is good idea. But it is hard to get all on one table..

CU Jörg

[David Ayers (ayers)]

The important issue is not who Mozilla trusts, but who the user trusts.
The issue also doesn't solely apply to the class 1 root certificate but also to the class 3 server certificate used by mail servers.

There are a substantial set of users who use (often their own) mail servers that use certificates signed by CAcert class 3 certificate.

Any application should have easy was to add a CA which the user trusts, totally independent of the situation wrt CAcert, which is also a reason why I do not believe that reopening this particular bug is the right thing to do.

The correct thing would be to request an easy way for a user to manage her CA's for her applications.