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/

[Chofmann (chofmann)]

going to have to finalize this in 1.7b

[Brady Shea (bmatthewshea)]

Just would like this included.

[Chofmann (chofmann)]

looks like this is going to have to wait for 1.7 final or 1.8. out of time for 1.7b

[Vdvo (vdvo)]

Created an attachment (id=144044)
patch to add cacert.org's root cert to builtins

I haven't been following the discussions in the newsgroups so I don't know
whether this patch is even welcome, but here it is, take it or leave it.
Produced with "cvs diff -u security/nss/lib/ckfw/builtins/" in the SeaMonkey
tree, i.e. against NSS tag NSS_CLIENT_TAG. It won't normally apply because of
CVS keyword substitution - I don't know what I'm supposed to do to produce a
valid patch. (Any advice is welcome, of course.) I'll edit the diff to leave
out the hunks with the keywords and post that.

[Vdvo (vdvo)]

Created an attachment (id=144046)
the no-keyword patch that actually applies

[Nelson-bolyard (nelson-bolyard)]

No decision has yet been made on the admittance of ANY new CA certs to
the built-in trust list. What is appropriate and desired is that copies
of the CA's root certs be attached to the each of the enhancement request
bugs, so that IF and WHEN the decision is made, we can run our usual
script that does all the work.

[Support-cacert (support-cacert)]

(In reply to comment #46)
> No decision has yet been made on the admittance of ANY new CA certs to
> the built-in trust list. What is appropriate and desired is that copies
> of the CA's root certs be attached to the each of the enhancement request
> bugs, so that IF and WHEN the decision is made, we can run our usual
> script that does all the work.

Erm isn't that just a tad insecure, I mean can't anyone make an attachment with
any root certificate?

[Rolf-sponsel (rolf-sponsel)]

(In reply to comment #46)

Wouldn't it be better that once a decision has been made that you contact
<email address hidden> and ask for the "current" root cert(s)?

[Nelson-bolyard (nelson-bolyard)]

Guys, I didn't request any of the existing attachments.

I planned to ask for the certs after the decision was made, and confirm
them by various means involving cert "fingerprints" (a.k.a. thumbprints)
sent via email signed with certs from an already trusted CA.

Someone apparently thought the process would be accelerated by contributing
those patches. It wasn't. The process isn't blocked by the lack of a patch.
It's blocked by the lack of decisions by Mozilla Foundation, AFAIK.

Feel free to revive the discussions in the newsgroup, not here. Thanks.

[David-rossde (david-rossde)]

I would not ask Mozilla users to trust this (or any other certificate authority)
without some assurance (beyond self assertions) that its practices do indeed
meet the standards generally advocated for CAs.

This illustrates the need for a clear policy as requested in bug #233453.

[Rolf-sponsel (rolf-sponsel)]

(In reply to comment #50)
> I would not ask Mozilla users to trust this (or any other certificate authority)
> without some assurance (beyond self assertions) that its practices do indeed
> meet the standards generally advocated for CAs.

Could you please be a little more specific about the "standards generally
advocated for CAs" - which you vaguely refer to - are?

Then, what should MF do with those CAs, already included today, that do not meet
those standards? Should their root certificates be removed from the next Mozilla
release (i.e. Mozilla 1.7)?

> This illustrates the need for a clear policy as requested in bug #233453.

Yes, I too support a "clear policy" (I guess!? ;-)). But, until such a policy is
in place, there is no reason to block all new CAs (or even existing CA's new
Root Certificates). Rather, once that "clear policy" is in place all the CAs,
even those already included in Mozilla today, must be scrutinized against them.
I guess this will not happen within the foreseable future; will it?

Theoreticising is always a good thing to start with, but to avoid a full stop,
until the ultimate solution eventually has been unaimously agreed on, there is
need for some pragmatism. By accepting new CA Root Certificates to be included,
in the meantime until a "clear policy" has been established, allows the new CAs
to *gain* their trust (this in opposite to have to "purchase" their "trust").

[Nelson-bolyard (nelson-bolyard)]

mass reassign enhancement requests for root CA certs to mozilla.org product
and to Frank Hecker. This will take several steps, as component must be
changed separately :(

[Rolf-sponsel (rolf-sponsel)]

I just got the message below.

Would you please mind to inform me/us about where I/we can find that "different
product" mentioned in the message? I'm very interested in tracking the
development of this issue.

Kind Regards,
Rolf Sponsel

MESSAGE RECEIVED WAS:

You used to have a vote on bug 215243, but it has been removed.

Reason: This bug has been moved to a different product

Votes removed: 1
    You have no more votes remaining on this bug.

http://bugzilla.mozilla.org/show_bug.cgi?id=215243

[Hecker-hecker (hecker-hecker)]

Re the question "Would you please mind to inform me/us about where I/we can find
that 'different product' mentioned in the message?":

The "product" referred to is not an actual software product like Mozilla,
Firefox, etc. It simply refers to the fact that you can use bugzilla to submit a
request for mozilla.org staff (or their representatives) to take some action;
such bugs are filed by setting the "product" field to be "mozilla.org". We then
use the "component" field in bugzilla to track exactly which action is being
requested of mozilla.org. In this case it's now possible to submit requests for
CA certificates to be included by filing a bug with the "product" field set to
"mozilla.org" and the "component" field set to "CA certificates".

So, to sum up, what happened was that all the bugs relating to including CA
certificates were modified to set the product and component fields according to
the above scheme.

[Rolf-sponsel (rolf-sponsel)]

Frank,

Thus we do not need to take any action to continue monitoring this "bug"/NFR.
The only difference to us is that now that the 'product' has become
"mozilla.org" there is no longer a possibility to vote for the "bug"/NFR, and
therefore our votes have been "lost".

Thank you for your explanation.

Best Regards

[Sehh (sehh)]

Any luck with this? We are all waiting for the CACert to be included in mozilla.

[Mark-spamx (mark-spamx)]

Agreed. I have many uses for a certificate such as this. I would love to stop
paying through the nose on a yearly basis just to provide ssl encryption to my
webmail users, let alone the intranet site.

[Rouben (rouben)]

I'd like to see CACert root certificates in Mozilla (and all derivatives) as well.

[Sehh (sehh)]

I dont think this is comming. If they wanted, they would have already
included the certificate, a long time ago. I'm guessing some people
would oppose such a thing because it would give more power to CACert
and would remove the monopoly of the big guys.

Those excuses about the certificate not been submitted properly or that
CACert is not "trusted" or whatever... excuses. They are as trusted
as any other root certificate authority.

A simple YES or NO would solve this discussion so we can move on.

[Aha (aha)]

Guys, I don't see any benefit in including any CA without attestation of its
reputation and its certification processes. Frank Hecker is working on list of
CAs, you can see progress on http://www.hecker.org/mozilla/ca-certificate-list/
Futhermore, root certificate have to be added to NSS first. So please be patient.

[Cs-zip (cs-zip)]

Guys, you're all doing this wrong!

There are two things required here:

1: It should be possible for end users to easily add a arbitrary certificate
authority to their setup.

2: Mozilla's certificate table should include a "use me" flag.
   Then ship CAcert with that flag off until you've decided how much to trust
   their validation proedures etc.
   Allow users to toggle the flag.
   Probably still check against the unflagged cert auths and raise a dialogue
   saying "this cert signed by known but not trusted-by-default auth:
     use this time, trust the auth, etc?"

In this way the users get some choice, you retain control of indicating whether
_you_ trust the various auths, etc. Everybody wins!

[Rouben (rouben)]

My only comment with regards to this is that "users" should be people like
Network Administrators or IT professionals. No offence, but I highly doubt that
the average user would know enough about PKI to be able to handle a system like
that.

However, I do agree that a "Mozilla deployment toolkit" is a great idea.
Microsoft has a similar product (deployment toolkit) for Internet Explorer, and
lots of documentation for corporate users (i.e. IT staff). The web page below
shows this program in action (screenshots):
http://www.microsoft.com/technet/prodtechnol/IE/deploy/deploy5/stage4.mspx

Perhaps a separate bug should be opened for a "deployment toolkit" project?
Although it is related to CA Cert inclusion (as the deployment toolkit should
allow for inclusion of arbitrary CA root certs by IT staff), it probably
deserves its own bug.

[Sehh (sehh)]

No my friend, you've got it wrong.

Mozilla already allows users to add their own certificates.

Thats not the problem though!

This is about control of the root certificates that will ship
with the browser by default (and not disabled in any way).

People don't want their users to get confused by the popup
dialog that the website they are accessing is not recognized!

[Rouben (rouben)]

(In reply to comment #63)
> This is about control of the root certificates that will ship
> with the browser by default (and not disabled in any way).

Indeed. Mozilla should definitely have a policy of some sort (or a checklist of
minimum requirements from CAs, at the very least), and/or provide the means for
others to exercise their own policies by means of a "deployment toolkit" of some
sort, as one possible way to do it.

The bottom line, however, is that in the corporate environment (e.g. for
corporate Intranet certificates) nothing is stopping you from creating your own
custom certificate collection for Mozilla and deploying it to all your end-users
(essentially forcing it upon them). Unfortunately you can't do that to the
entire world. ;)

> People don't want their users to get confused by the popup
> dialog that the website they are accessing is not recognized!

Not really... What was suggested is that some CA root certs ship "flagged" (i.e.
not trusted out of the box). That way, if a user connects to a web server with
an SSL cert signed by a "flagged" root cert, they will be prompted.

To a user it makes absolutely no difference: they see a popup either way
(whether the root cert is included and flagged or not included at all). If they
choose to "always trust it" in the latter case, the certificate will be stored
in that user's certificate manager, which automatically will make it trusted (as
far as I understand). From the point of view of PKI, this is *bad*, because
ideally one is supposed to get the *root* certificate in their certificate
manager, so that any certificates that are signed by that root cert will
implicitly become trusted and won't have to be added in manually.

[Cs-zip (cs-zip)]

(In reply to comment #64)
> > People don't want their users to get confused by the popup
> > dialog that the website they are accessing is not recognized!
>
> Not really... What was suggested is that some CA root certs ship "flagged" (i.e.
> not trusted out of the box). That way, if a user connects to a web server with
> an SSL cert signed by a "flagged" root cert, they will be prompted.

Indeed. The idea is that for the end user without much knowledge it is
good to have a wide set of root certs available shipped with the browser,
though I agree that they should not all be equally trusted.

> To a user it makes absolutely no difference: they see a popup either way
> (whether the root cert is included and flagged or not included at all). If they
> choose to "always trust it" in the latter case, the certificate will be stored
> in that user's certificate manager, which automatically will make it trusted (as
> far as I understand). From the point of view of PKI, this is *bad*, because
> ideally one is supposed to get the *root* certificate in their certificate
> manager, so that any certificates that are signed by that root cert will
> implicitly become trusted and won't have to be added in manually.

Which is why it should ship with it, though disabled at mozilla.org's discretion.

[Kk-kjernsmo (kk-kjernsmo)]

> 1: It should be possible for end users to easily add a arbitrary
> certificate authority to their setup.

Actually, no.... :-)

Adding a root certificate is a serious matter, and if a user can easily
be fooled into accepting a bogus certificate it would be disastrous. If
you make it easy to add a root certificate, you open up for all kinds
of social engineering attacks, as well as virus attacks. I'm really
surprised that we're not hearing about viruses trying to add root
certificates allready...

Once a bogus root certificate is accepted, you open up for all kinds of
man-in-the-middle attacks. Someone can, for example, easily replace a
bank's website, and make it look legit, no popups warning about bogus
site certificates, the lock is in place and so on. Say for example that
you (you're now Evil) control the information flow between a customer
and a bank, and between the bank and the supplier. Since you've been
able to insert a root certificate at some point in the browser of the
customer and supplier, and through phishing, you've got them to use
your website rather than the true bank's. When they log in, everything
looks normal, but they are actually encrypting their information with
your certificate. So, you grab that, and use their session
authentication to transfer the customer's money to yourself, but at the
same time, you send a notification to the supplier that payment has
been received through his trusted encrypted channel from what he thinks is
his bank. So, the customer gets his goods, the supplier thinks he has
his money, but you have them. Everybody's happy, until the supplier makes an
audit based on data from a source you don't control. It could be never,
or next month. Either way, you're on a beach somewhere by then...

I've detailed this type of attack to my bank, there are easy ways to
protect against it (publish the fingerprints of the banks key in the
physical banks), but there's no way you're going to convince anybody to
take this extra precaution. They rely 100% on root certificates being
valid, trusted, irreplaceable, immune to viruses, socially
unengineerable and whatnot... :-/

The whole thing is built on sand as it is, and making it easier to add
root certificates is IMHO not the way to go. Root certificates should
only ever be added by somebody with a clue, and for them, it is easy
enough as it is.

But that is not to say CACert shouldn't be added, I think it should,
after due process.

Now, really, this bug isn't the real forum for discussing it, the
newsgroups are. Sorry, couldn't resist... :-)

Kjetil

[Ch-ey (ch-ey)]

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

[Peter-lairo (peter-lairo)]

Recently, some serious doubts have come up as to CAcert's "readyness" for being
included into Mozilla:

http://bugs.kde.org/show_bug.cgi?id=74290 (marked WONTFIX)
http://article.gmane.org/gmane.comp.security.cacert/1378
http://article.gmane.org/gmane.comp.security.cacert/1186
news://news.gmane.org:119/001a01c47b89$c4aee9f0$5718440a@barmalalapw2k
news://news.gmane.org:<email address hidden>
and, on the positive side:
news://news.gmane.org:<email address hidden>

One of the board members who resigned (Christian Barmala) I have known
*personally* for several years now, and I have a very high opinion in his
honesty, integrity, and technical knowledge in matters digital security.

I think we should wait *at least* until *after* the next (first?) CAcert board
meeting, to see if they can create a structure that is controlled by more than
just one person (as it is currently).

PS. I had high hopes for CAcert, and still hope Duane (the current *sole*
controller of CAcert) will make the right decisions to get things on track.

NOTE: I'm not suggesting WONTFIX; merely that we are cautious, and wait.

[Cs-zip (cs-zip)]

(In reply to comment #66)
> > 1: It should be possible for end users to easily add a arbitrary
> > certificate authority to their setup.
>
> Actually, no.... :-)
> Adding a root certificate is a serious matter, and if a user can easily
> be fooled into accepting a bogus certificate it would be disastrous. If
> you make it easy to add a root certificate, you open up for all kinds
> of social engineering attacks, as well as virus attacks. I'm really
> surprised that we're not hearing about viruses trying to add root
> certificates allready...
> Once a bogus root certificate is accepted, you open up for all kinds of
> man-in-the-middle attacks. [...]

Just for the record I want to say I am convinced by Kjetil's argument.

However, I still think Mozilla should ship with some "we think they may
be ok but haven't fully vetted them" certs and a GUI to activate them
(with big red letters saying "danger, danger, Will Robinson" so the user
realises that there is real risk in this, and perhaps also to suggest
that the existing trusted cert authorities are also points of weakness
in the scheme, though we trust them "more").

So while I agree that it should be difficult or highly discouraged to
add a root cert, I still think it should be possible for a user to tune
their trust, and offered a (discouraged) choice of extra auths to trust.

[Joschi Holaubek (erwin-zsi)]

(In reply to comment #68)
(...)
> PS. I had high hopes for CAcert, and still hope Duane (the current *sole*
> controller of CAcert) will make the right decisions to get things on track.
>
> NOTE: I'm not suggesting WONTFIX; merely that we are cautious, and wait.

meanwhile, several weeks ago a new board has been elected; the code on which the
cacert service is based has been opened for inspection and I for my part feel
that the issues critisized above have been more or less resolved.

Please, could some more knowlegable people than I re-evaluate the situation?

[Nelson-bolyard (nelson-bolyard)]

A reaading of the postings for the last few months in
news://news.gmane.org:119/gmane.comp.security.cacert
suggests otherwise, IMO.

[Lance-uklinux (lance-uklinux)]

Please could you post specifics relating to that comment, as I have read back to
11th August and see little cause for concern.

[Olivier-godart (olivier-godart)]

Cacert is better than the other 24 companies that have their root certificates
already included in mozilla.

[Rouben (rouben)]

(In reply to comment #73)
> Cacert is better than the other 24 companies that have their root certificates
> already included in mozilla.

With all due respect, just because they offer services for "free" doesn't mean
that they are better. CACert has just had a complete overhaul, and quite frankly
I think they are too fresh of a company to be completely trusted. But that's
just my personal opinion on the issue. :)

This bug has lots of interesting and good reasons for and against including
CACert's root cert into Mozilla's suite of products "by default".

[Duane-cacert (duane-cacert)]

(In reply to comment #74)

> I think they are too fresh of a company to be completely trusted. But that's
> just my personal opinion on the issue. :)

Age is irrellevant, and the only way you can call CAcert a company is if you
thought Mozilla Foundation was also a company. Until MF (or more specifically
Frank Hecker) comes up with and finalises a policy for inclusion that doesn't
involve webtrust things will still be in limbo on this topic, as it's a little
hard to comply with a policy that doesn't exist.

[Gershonnubour (gershonnubour)]

I am merely an interested techie with no connections to cacert or MF.
I can see the concerns of some who are apprehensive of undermining mozilla's
standing in the "community" and possibly the whole CA/ssl infrastructure.

cacert is also justified in its frustration at having no path through which it
can gain the inclusion of its root certificate, or even a set of viable
requirements it can work towards.

Personally I think their certificate should be included as long as:

1. Their hardware/network is hosted at an independant site at which 3 of their
board/team/authorised people have secure access.
(By independant I mean a location at which no one person with access has a
greater vested interest in than another - which rules out their respective
employers, partners employers etc.)

2. Their management/board structure is transparent with decisions requiring a
minimum of three people, and clear policies/procedures for ensuring the equal
distribution of power between board members

3. CaCert have clear policies/procedures for natural changes in board membership
and also policies/procedures for the removal of board members who have acted in
bad faith.

Whether cacert meets or surpasses these requirements I dont know but reading all
the other peoples posts, it appears that their technical implementation was not
the major concern, but more the trust element. The above suggestions are merely
designed to foster that trust at MF
Which in a nutshell is the whole point of being a certificate authority.

I believe the issue is worth re-examining as firefox 1.0 and thundebird 1.0 are
out of the door, and people at MF may have the time to look at the issues involved.
Feel free to disagree with anything I've said

Thanks Gersh
NB My views only apply to the cacert situation, other CA's would possibly need
to be looked at completely differently, once again its back to MF drafting a
clear policy on the issue for the future.

[David-rossde (david-rossde)]

Those who want this root certificate now can always go to the fist link listed
in comment #19 to obtain it. They will then take full responsibility for their
own actions rather than depending upon Mozilla.

In the meantime, it is appropriate for Mozilla to evaluate the practices of
CAcert. After all, Mozilla is trying to maintain the trust its users have in
its products. That trust includes relying on root certificates delivered with
those products.

Without doing my own validation of root certificates, I want to have some
confidence that a secure Web site indeed belongs to who it claims to belong.
That means the certificate authority (owner of the root certificate) exercises
some demonstrated care issuing site certificates.

By "demonstrated care", I mean demonstrated to some third party (e.g., an
examination conducted by the Mozilla Foundation) and not merely a self-serving
assertion. This is the whole point of the policy proposed under bug 233453.
The alternative -- accepting proposed certificates without any evaluation --
could open Mozilla to phishers and hackers and destroy all trust.

By the way (reference comment #75), the Mozilla Foundation is a corporation
(incorporated in California) and is thus a legal entity. CAcert is an
association (based in Australia); I don't know its legal status.

[Duane-cacert (duane-cacert)]

(In reply to comment #19)
> 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

We've recently (as of September) completed a change to a new web interface and
as a result numerous links listed above are no longer valid. To address a
request for current links please see below.

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=51
c) About CAcert: http://www.cacert.org/index.php?id=12
d1) CPS: http://www.cacert.org/cps.php
d2) Privacy statement: http://www.cacert.org/index.php?id=10
e) Contact: http://www.cacert.org/index.php?id=11

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

Folks here may be interested in the candidate CA policy that's been posted:

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

Roughly, it farms out criteria for a CA to WebTrust. There may be some product
liability concerns around this.

Some here have called for CAcert's cert to ship in a disabled fashioned 'if only
there was a gui to enable it'. It's there, in Firefox anyway.
Prefs...Advanced...Certs..Manage Certs...Authorities...Edit.

Also, I filed bug 276827 for removal of the one-click root-cert install to help
with phishing/MIM attacks.

[Duane-cacert (duane-cacert)]

(In reply to comment #79)

> Some here have called for CAcert's cert to ship in a disabled fashioned

I don't think this would help us at all, in fact it could be seen as if mozilla
foundation has included it already because it doesn't trust us which will give
the wrong impression. I don't know about you guys but we're trying to cut down
on end user support not increase it, which is all I can see this causing.

> Also, I filed bug 276827 for removal of the one-click root-cert install to
> help with phishing/MIM attacks.

How does this exactly prevent MITM or phising scams? phising scams usually don't
even have an SSL cert, and MITM attacks are very hard to sustain unless you're a
government agency. What would prevent MITM attacks or increase awareness that it
had occurred would be a database of fingerprints in the browser, and if the
fingerprint changed then the browser would warn the user about it.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

(In reply to comment #80)

> I don't think this would help us at all, in fact it could be seen as if mozilla
> foundation has included it already because it doesn't trust us which will give
> the wrong impression. I don't know about you guys but we're trying to cut down
> on end user support not increase it, which is all I can see this causing.

As I understand it CAcert doesn't meet the WebTrust criteria (please correct me
if I'm wrong here) which is what MF is going to use to judge CAcert. Don't get
me wrong, I don't think WebTrust CA's are more secure than CAcert but that's
MF's position on it, or at least they don't want to be seen as making a
judgement on their own. I just think it's better to get the CAcert root cert
distributed, turned off by default, than not distributed at all. CAcert is a
new model and the MF may need some time to get used to it. If the policy is
finalized as-is and CAcert doesn't meet WebTrust criteria, it would be time to
lobby for a lesser standard for MF to distribute certs not turned on.

> How does this exactly prevent MITM or phising scams?

have a look at comment #66 from Kjetil Kjernsmo.

[Duane-cacert (duane-cacert)]

(In reply to comment #81)
> As I understand it CAcert doesn't meet the WebTrust criteria (please correct me
> if I'm wrong here) which is what MF is going to use to judge CAcert. Don't get

We have the potential to get funding for Webtrust certified, BUT the biggest
problem people see with it is the ongoing yearly fee, and it's seen as a waste
of money for little/no benefit (although we're curious about how many CAs get
webtrust certified and then don't bother renewing after that and how many are
revoked by MF or MS)

> me wrong, I don't think WebTrust CA's are more secure than CAcert but that's
> MF's position on it, or at least they don't want to be seen as making a
> judgement on their own. I just think it's better to get the CAcert root cert
> distributed, turned off by default, than not distributed at all. CAcert is a
> new model and the MF may need some time to get used to it. If the policy is
> finalized as-is and CAcert doesn't meet WebTrust criteria, it would be time to
> lobby for a lesser standard for MF to distribute certs not turned on.

Frank has already stated publically Webtrust or equivilent and we're putting a
lot of focus on what it would take to pass an audit similar to webtrust

> have a look at comment #66 from Kjetil Kjernsmo.

Again, I don't see the point, all the phishing scams I know of have used browser
exploits or social engineering techniques, they haven't used SSL (Although I do
recall someone posting about a scam that did, 1 out of 50,000,000,000 isn't very
good odds that they will occur.)

Futher more if I was so inclined to do a phishing scam there are numerous CAs
out there that will issue 1 and 2 year certs with only needing proof of domain
ownership, which isn't likely to prove anything more then you can abuse credit
cards and the CA system.

Apparently quite a bit of the spyware these days is code signed, and the
majority of spammers have a better working Sender ID etc then most normal email
admins, so the things that are marketed as being able to prevent these things
generally don't live up to expectation.

[David-rossde (david-rossde)]

Please re-read not only the policy at
<http://www.hecker.org/mozilla/ca-certificate-policy/>, but also the meta-policy
at <http://www.hecker.org/mozilla/ca-certificate-metapolicy/> and the FAQ at
<http://www.hecker.org/mozilla/ca-certificate-faq/> (all proposed). Also, read
the discussion of these at
<news://news.mozilla.org/netscape.public.mozilla.crypto>, especially the thread
with the subject "New draft of CA certificate policy". A WebTrust audit will
not be the only way a root certificate gets added to the Mozilla database.

Alternative third-party reviews and "attestations" are provided in the policy.
This is a result of lengthy discussions in which the cost of a WebTrust audit
was deemed an unacceptable barrier against legitimate, low-cost certificate
authorities. In particular, CAcert is a non-profit that issues its certificates
for free, depending on donations (including membership dues, which does NOT
purchase certificates) for its funding.

Let's see if the policy can work (if it's officially adopted by the Mozilla
Foundation). Further general discussion of the proposed policy really belongs
in bug #233453 or (better) in the netscape.public.mozilla.crypto newsgroup.

[codeslinger (codeslinger)]

If I may be permitted to make a few observations

1) I am not related to MF or CACert. I am a programmer/computer consultant and
provide email services and webhosting to some of my clients. These are very
small sites not big buck companies, not one of them can justify paying the
prices verisign charges.

2) I think the CACert concept is excellent. I have long balked at the hiway
robbery of the Verisign$ monopoly.

3) This bug/request was entered/opened in August of 2003. It is now Jan 30,
2005!! For crying out loud... how about a little bit less heel dragging?!?...
  Just how the heck long does it take to make a decision anyway...?? See
Especially this link. http://www.heretical.com/miscella/parkinsl.html
It makes me wonder how the absolutely superlative FireFox ever managed to happen
to begin with, if this is typical of your decision making process...

4) I am strongly disinclined to install and configure a bunch of stuff just so
that I can access your news forum. Is it really too much trouble to use a web
based forum like the majority of people do these days? Am I the only person who
has made the observation that usenet type news services appear to be fading into
obscurity? Web forums are the new paridigm.

5) People keep harping on the idea of shipping a disabled certificate as a so
called "solution". At the risk of being insulting, may I point out that this is
an absurd and ill conceived notion showing a major lack of conceptual insight
into the actual goal... (that's the toned down version).

Now look, what is the goal? Te goal is that people can go to a site which uses
a CACert; and without any fuss or bother they can access that site using SSL.

Now, what happens when you go to a site for which there is no trusted
certificate installed? Well, you get a dialog that pops up and warns you that
there is no valid certificate and asks if you would like to install it. The
dialog itself looks kind of ominous and intimidating. So the very justifiable
concern is that users won't want to accept the certificate and won't be able to
access the site, and may very probably turn into a support contact phone/email
which then requires manpower to deal with; or else they just leave, never to be
seen again.

Now, what happens when you go to a site for which you have a disabled
certificate installed???? Well, gee whiz... the very same dialog, or a close
cousin pops up and ominously intimidates the user by warning them that there may
be a certificate available for this site but it's been disabled because MF
doesn't trust it enough to be willing to install it properly.... And it asks
the user the very similar question of whether or not to activate it.

Now the whole goal of all of this, is so that the end user does not have to get
all freaked out by all these strange pop up warnings. I think that most of the
people reading this bugzillia have a good appreciation for the discomfort level
of the typical novice computer user.

And then there is the fact that to implement this "installed but disabled"
thang, you will have to write quite a but of extra code, and add still more
functionality that few people will know how to use. And the net...

[Rouben (rouben)]

(In reply to comment #84):
Erik, I think you misunderstand the issue at hand. The problem is not that the
Mozilla Foundation is taking too long to include CACert's root certificate into
its products "by default" or the fact that end-users see a security warning when
visiting SSL sites secured by a certificate issued by an "untrusted" CA, such as
CACert.

The problem is that the Mozilla Foundation doesn't really have a solid policy
that governs these situations. Before we discuss CACert (or any other CA, be
they "open/free" or not), the Mozilla Foundation needs to come up with a policy
for reviewing CAs such as CACert.

One thing I'll hand to you, though: this issue has dragged on long enough. A
decision should be made relatively soon for the good of everyone involved.

P.S. Discussions of these sorts should really be held at the forums (usenet/web
forums).

[Rich-thefreemanclan (rich-thefreemanclan)]

Rouben - in response to "Before we discuss CACert (or any other CA, be
they "open/free" or not), the Mozilla Foundation needs to come up with a policy
for reviewing CAs such as CACert."

If that were really Mozilla's policy, then in the interest of fairness all CAs
should be stripped from the Mozilla browsers. It seems like incumbents are
being held to a lower standard than open and free CAs. Indeed, Verisign issued
a code signing key for Microsoft to a hacker, and little happened. I'm sure
that if CACert.org did such a thing it would be grounds to never speak to them
again.

I did not see any obvious discussion related to this particular issue in the
newsgroup, although I did see some discussion about the general policy that is
being set up - from December.

I think the issue is that the status quo is being treated as good enough for
now. A revised policy is proposed, after a month or two another revision is
posted, maybe in six months it will be done, and some board will vote on it and
suggest a few changes, maybe in another 6-9 months we'll be before the board
again, etc.

If the interim solution were to not put any certs at all in the browser pending
the creation of a policy, you can bet that the policy would be done in a month.
Companies like Verisign would probably be screaming restraint of trade and
threatening to sue.

So, perhaps the issue is that the free CAs just aren't noisy enough to worry
about?

(I'm not really suggesting that we should really strip out the root CAs that
are present now. However, it really doesn't look like this situation is going
to ever get resolved unless it is treated like a priority.)

[David-rossde (david-rossde)]

Debate about the appropriateness of adding new root certificates belongs in
<URL:news://news.mozilla.org/netscape.public.mozilla.crypto>, not here. For
this specific root certificate, I have started a thread there with the subject
"CAcert Root Certificate". Please make any further comments there and not in
this bug report.

Bug comments should be reserved for technical issues, not for rants (although I
am sometimes guilty of the latter).

[Sehh (sehh)]

I dont think that this issue belongs to a forum. The issue should be discussed
here and should be resolved in a short time. Erik (above) has clearly stated
what my poor English can't put to words. This has indeed taken too long and the
arguments are just not valid. CACert should be included like all the other root
certificates, you like it or not. Just stop hiding behind your fingers and get
on with it.

[Rouben (rouben)]

Given the way this discussion is going, perhaps this indeed is an issue of
simply assigning a priority level to this bug that everyone can agree to and
just getting it done?

One thing that bugs me (no pun intended) is that this bug still has a "null"
priority level. I can certainly agree with the severity rating (this is indeed
an "enhancement"), but I certainly do not agree with the fact that this issue
has an undefined priority level. Do CACert reps really need to make a big fuss
out here in order for that rating to be changed (as was suggested in the
previous comment)?

[Peter-lairo (peter-lairo)]

This should be good news to you guys:

http://www.hecker.org/mozilla/cert-policy-draft-9

[Nb (nb)]

I have used CACert, and their policies appear to be comparable to Thawte's.
They make you get your id verified before you can get a cert with your name in it.

I do not see what the real problem is with putting cacert's root certificate in
mozilla/nss by default.

BTW, they are working on making a CPS now. See the CA Cert mailing lists for
more details.

[Eddy-nigg (eddy-nigg)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 (ax)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 (ax)

I'd like to suggest to you, the inclusion of the "Free SSL Certification
Authority" offered and run by http://cert.startcom.org/ at your KDE
browser. The project is hardly a month old and caused quite some
interest and "noise" at some news web sites. The StartCom Free SSL
Certificate Project aims to be a viable alternative to commercial
128/256 bit SSL certificates and grows currently by almost 80 issued
certificates per day.

Efforts are being made, for the natural support by major web browsers of
the "Free SSL Certification Authority", but also continued development
and improvement of the services and certificates, including verification
processes etc. We try to get a market share of 1 % during the first 90 -
120 days, with reaching 3 - 5 % at the end of the year.

Reproducible: Always

Steps to Reproduce:

[Hecker-hecker (hecker-hecker)]

Kai, please feel free to re-assign this bug to me. It seems to be a pretty
straightforward request to add a new CA certificate to Mozilla et.al.

[Eddy-nigg (eddy-nigg)]

Of course I meant Mozilla browser(s) and applications and not *KDE* which I
obviously copied from the same request to KDE.org...really sorry for that glitch...

[Joshbirnbaum-mozil (joshbirnbaum-mozil)]

Moving to be with all the other CA requests.

[Hecker-hecker (hecker-hecker)]

Accepting this bug. Note that our current policy requires that CAs have
completed a WebTrust for CAs audit or equivalent third-party audit. We have a
newer policy in draft form, but it's not yet in effect; see

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

for more information.

[Eddy-nigg (eddy-nigg)]

The CA Policy as available at http://cert.startcom.org/policy.pdf and will
change its status from draft to final in the comming weeks.

Currently the operation will be under voluntary self control together with a
third-party (lawer) statement, confirming this. We make sure, that we confirm to
our own policy regarding every aspect and work in accordance to this policy.

In the future a qualified independent entity or person might conduct an audit
which is adequate for the current nature of this non-profit project.

[Eddy-nigg (eddy-nigg)]

All policies and relevant papers are published at
http://cert.startcom.org/index.php?app=111

Working papers are in preperation for an audit, which will be performed,
starting during this summer (2005) and will be published at the same location as
above.

CA certificates are published at page
http://cert.startcom.org/index.php?app=110#auth

Details of OCSP service are at page http://cert.startcom.org/index.php?app=110#ocsp

CRL's are at:

http://cert.startcom.org/crt1-crl.crl
http://cert.startcom.org/crt2-crl.crl
http://cert.startcom.org/crt3-crl.crl
http://cert.startcom.org/ca-crl.crl

[Eddy-nigg (eddy-nigg)]

Published an additional important document "Evaluation of Microsoft policy
compliance - AICPA Audit" (includes also Mozilla). This evaluation is a base for
discussion according to topic 12 of Mozilla CA Certificate Policy and a
self-audit as outlined in the CA policy.

http://cert.startcom.org/msie.htm

Comparable ETSI Policy Requirements document is under progress and will be
published as well.

[Dtownsend (dtownsend)]

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

[Jruderman (jruderman)]

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

[Florianmanschwetus (florianmanschwetus)]

so guys jo pointet ever and ever to your newsgroup, but today i tried to get to
it with thunderbird but i can't locate a thread about the thematics discussed in
this bug. so what goes on, poste an easy howto get in this newsgroup using
thunderbird (i mean it's your stuff, so you should know howto use it)

[Florianmanschwetus (florianmanschwetus)]

(In reply to comment #94)
> so guys jo pointet ever and ever to your newsgroup, but today i tried to get to
> it with thunderbird but i can't locate a thread about the thematics discussed in
> this bug. so what goes on, poste an easy howto get in this newsgroup using
> thunderbird (i mean it's your stuff, so you should know howto use it)

btw: it will be nice using ssl in this howto;)

[Eddy-nigg (eddy-nigg)]

Published and renamed "Evaluation of Microsoft and Mozilla policy compliance -
AICPA Audit" at http://cert.startcom.org/audit.htm, which is the evaluation and
self-audit performed by StartCom. An Independent Accountants Report is
confirming the audit, signed by StartCom's laywer
(http://cert.startcom.org/img/report.jpg).

The published papers might be reason for Mozilla to include and accept the
StartCom CA in its software.

A third party audit will be performed starting September 2005. The outcome and
all relevant papers will be published at the end of the process.

[Joshbirnbaum-mozil (joshbirnbaum-mozil)]

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

[Sfraser-bugs (sfraser-bugs)]

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

[Nb (nb)]

It appears from my personal experience that CAcert is still controlled by one
person (Duane Groth) and that the board is really just elected at the annual
meetings, and does not really do anything. If anyone would like more
information, email me direct.

I withdraw my endorsement of CAcert being included into Mozilla products (FWIW).

(In reply to comment #68)
> Recently, some serious doubts have come up as to CAcert's "readyness" for being
> included into Mozilla:
>
> http://bugs.kde.org/show_bug.cgi?id=74290 (marked WONTFIX)
> http://article.gmane.org/gmane.comp.security.cacert/1378
> http://article.gmane.org/gmane.comp.security.cacert/1186
> news://news.gmane.org:119/001a01c47b89$c4aee9f0$5718440a@barmalalapw2k
> news://news.gmane.org:<email address hidden>
> and, on the positive side:
> news://news.gmane.org:<email address hidden>
>
> One of the board members who resigned (Christian Barmala) I have known
> *personally* for several years now, and I have a very high opinion in his
> honesty, integrity, and technical knowledge in matters digital security.
>
> I think we should wait *at least* until *after* the next (first?) CAcert board
> meeting, to see if they can create a structure that is controlled by more than
> just one person (as it is currently).
>
> PS. I had high hopes for CAcert, and still hope Duane (the current *sole*
> controller of CAcert) will make the right decisions to get things on track.
>
> NOTE: I'm not suggesting WONTFIX; merely that we are cautious, and wait.

[Nb (nb)]

Since my previous posting, CAcert is working on addressing some of the issues.
I forsee the situation improving in the near future. These changes should make
the association more transparent in the way it is managed.

[Poolfish666 (poolfish666)]

I agree, Firefox needs to include the CACert root shipped. CACert's root cert is as secure as any commercial CA and allows for similar access as the Thawte "web of trust" program which is included in Firefox so I vote yes to include CACert's root.

[Tfejos-freemail (tfejos-freemail)]

(In reply to comment #100)
> I agree, Firefox needs to include the CACert root shipped. CACert's root cert
> is as secure as any commercial CA and allows for similar access as the Thawte
> "web of trust" program which is included in Firefox so I vote yes to include
> CACert's root.
>

Yes. I also agree. What shod we do for this?

[Sfraser-bugs (sfraser-bugs)]

(In reply to comment #101)
> Yes. I also agree. What shod we do for this?

You can start by reading the rest of this bug.

[Eddy-nigg (eddy-nigg)]

The StartCom Certification Authority underwent a third party audit as required by most software vendors, including Mozilla, based on the AICPA/CICA Webtrust for Certification Authorities Criteria. Information of the signed audit is available at http://cert.startcom.org/audit.pdf and as such we request to get approved for inclusion in all Mozilla software.

[Hecker-hecker (hecker-hecker)]

I've updated <URL:http://www.hecker.org/mozilla/ca-certificate-list> to reflect the updated StartCom information. I'm now going through the version 1.1 of the certificate policy/CPS.

[Dirkjan Ochtman (dirkjan-ochtman)]

Restarted this discussion on the new mozilla.dev.tech.crypto newsgroup.

[Jgzimmerle (jgzimmerle)]

(In reply to comment #29)
> 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.

I agree, but I think the lock icon is the wrong approach anyway, because it only allows for two states: A site is either trusted or not. I think a scale would be more apropriate, because it would allow for different trust-levels, ranging from encryption-only (for self-signed certificates) to high-level-authenticated (for organisations like banks). Mozilla could then add CAcert root certificates to the clients and assign the maximum possible trust level that CAcert-certified sites can get.

Also to get top trust-levels it could be a requirement that the site's public key must be signed by several CAs.

[Eddy-nigg (eddy-nigg)]

This bug is still open! Could you please approve the StartCom CA and integrate the StartCom CA Root within the Mozilla Software?

[David-rossde (david-rossde)]

Part of what is requested in comment #104 already exists. For each CA certificate, you can indicate any combination of use: authenticating Web sites, authenticating and encrypting E-mail, and authenticating software distributors.

I don't know if the overall standard for certificates supports degrees of trust. If not, then the requested capability would require software implementation within Firefox, Thunderbird, and SeaMonkey. It would also require an exercise of judgement relative to the trustworthiness of a certificate for which there is no published standard.

For degrees of trust relative to E-mail, you might consider using PGP. PGP allows two levels of validity: valid (you know that the key belongs to the asserted owner) and invalid (you don't know whether the key belongs to the asserted owner -- not that the key is bad, only that you don't know). Also, PGP allows three levels of trust: trusted (a signature by that key on another key is as good as your own signature), partially trusted (you need the signature of at least one other partially trusted key), and untrusted (you ignore signatures from that key). Note that these levels are part of the design of the PGP software (and likely other products conforming to RFC 2440 such as GPG) and not inherent in the keys themselves.

I'm not sure that requiring each CA to obtain the signatures of other CAs would work. The CAs are in competition with each other and would likely either decline to sign a competitor's certificate or charge an exhobitant fee. Since such signatures expire, this would be an ongoing point of contention whereby a dominant CA could actually drive smaller competitors out of business. It certainly would keep non-profit CAs (e.g., CACert) out of the market.

[Matej Cepl (matej-ceplovi)]

(with regards to comment# 100):

comparison between Thawte WOT and CACert.org is misleading -- Thawte provides for free only email certs, not websites' one, so you cannot many more dangerous things (like running webstore) on it.

[Erkdog (erkdog)]

Here's an idea, since any yohoo with $20 bucks can go to Verisign, GeoTrust, etc, and get a valid cert for signing and encrypting e-mails, why not add CACert to at least Thunderbird?

It would be alot easier for someone to pay $19.95 and get a valid cert, than it would be for someone to get at minimum two people to verify face to face their identity.

I mean seriously.

CACert / Thawte / PGP are all free, yet, MORE SECURE.

*rolls eyes*

[Amessina (amessina)]

Back when Netscape and IE came out, did the end user ever get a say in what root certificates were installed by default? Did the end user get to decide whether or not s/he wanted to "trust" Verisign or any other authority?

Myself, I do not recall ever being asked whether or not I wanted to trust a site that used a Verisign certificate.

Is there another place where one can subscribe to updates or find the progress of this inclusion?

[Sehh (sehh)]

cacert isn't going to be included in firefox, because of political issues (cacert being free and all, it would cause major damage to world-wide sales of certificates). Remember, firefox isn't exactly "open", its still being controled and managed by a group of people who are being told what to do.

This issue started YEARS ago and it will continue like this.

[Erkdog (erkdog)]

Thawte and Comodo are both free.

[Mozbugs (mozbugs)]

(In reply to comment #110)
> Thawte and Comodo are both free.

Not for SSL server certs :P

Is it feasible, and would it be acceptible to the "governing bodies", to include the cacert.org CA cert(s?), but only trust them for identifying email users by default? The act of a user going in and changing the trust level seems roughly equivalent to installing the CA cert(s) themselves...

[Rich-thefreemanclan (rich-thefreemanclan)]

Actually, an installation with a low level of trust by default would also eliminate the authentication issue with obtaining root certificates. In theory the untrusted-certificate dialog box could include a button to grant an additional level of trust to the associated root cert.

Honestly, I don't see what security is obtained by keeping out serious free cert providers when verisign doesn't do much to authenticate their certs other than making sure the check clears.

[Sehh (sehh)]

Nobody sees any logic in this. The inclusion of cacert in the mozilla suite has nothing to do with logic, its just a political play. If this was logical and democratic then we'd have cacert included years ago. Currently the plan is to delay this as long as possible, they already found several excuses to delay the inclusion of cacert and now they are just stalling. They'll try to keep this issue frozen as long as possible. There isn't much we can do, this isn't exactly an "open" project thus we can't add cacert ourselfs, its all about AOL, Time Warner, former Netscape or whoever is blocking cacert on purpose.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

adding Status Whiteboard:
  discussion here: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_frm/thread/7b13628f31177d64/20a7c5ad26c37eba?lnk=st&q=M-udnSYBis6Tkm7enZ2dnUVZ_tOdnZ2d%40mozilla.org&rnum=1#20a7c5ad26c37eba

if somebody can mangle that into a useful news: URL, go for it.

[Hecker-hecker (hecker-hecker)]

    I'm executive director of the Mozilla Foundation, and have been involved with the CAcert issue since it first came up. Here's the current situation; please feel free to confirm this with people directly associated with CAcert:

    We have a formal policy on the criteria for accepting new CA certificates into Mozilla; see

    http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html

    This policy was deliberately written so that it would not unfairly exclude nonprofit initiatives like CAcert. However the policy does require CAs, include CAcert, to undergo some sort of independent evaluation of their operations, according to some set of reasonable written criteria. CAcert has come up with a set of written criteria, analogous to the WebTrust criteria mentioned in the policy, and I told them the criteria were acceptable. However they have not yet had any luck in finding a third party who could do an evaluation of CAcert according to those criteria.

    So the holdup right now has to do with CAcert completing an independent evaluation of their operations. The holdup has nothing to do with Time Warner, AOL, Netscape, or anything else. I'm just asking CAcert to conform to the same policy we require every other CA to conform to, a policy that CAcert representatives had lots of opportunities to comment on and influence.

[Sehh (sehh)]

So it took you 3 years to write a policy... which has to be followed by cacert.

So when did all the other authorities pass this policy? I believe mozilla/firefox shipped with their certificates long before this policy was even around.

So why delay for cacert for so many years and ask them to have this evaluation when all the other authorities have been included no-queastions-asked?

Not to mention that forcing a cacert to find a 3rd party (and probably spend money on this) isn't exactly ideal for them i believe. They are giving free server certificates after all, not charging by the bucket load.

[Rich-thefreemanclan (rich-thefreemanclan)]

Perhaps the Mozilla Foundation would choose to be the necessary 3rd-party auditor? Obviously the foundation doesn't consider the expense of such an audit to be too great, so it certainly shouldn't mind taking this on. Plus, it should be able to meet the policy criteria... :)

Really, what is the worst that could happen if CaCert were included? Perhaps somebody would snatch control of the microsoft.com domain and obtain a certificate for them? In the case of verisign somebody was able to get an MS certificate without the trouble of even hijacking the domain. Should we consequently remove verisign, and anybody else audited by webtrust?

Having a policy is a good thing, but Mozilla really should be going out of its way to facilitate free and open SSL providers.

[David-rossde (david-rossde)]

I developed a checklist for an independent review of certificate authorities (CAs) in alignment with the new policy but distinct from a WebTrust audit. The checklist is in the form of a list of requirements with a trace to the WebTrust criteria. Frank Hecker reviewed my checklist and offered suggestions, which I incorporated.

With the approval of Hecker, I started a review of the CACert "Certificate Policy" based on my checklist. That review uncovered some deficiencies, which CACert has endeavored to correct. I became distracted from further review by my appointment to my county's Grand Jury (a year's assignment with a second year's extension), so I turned my notes over to another reviewer.

The primary issue is trust. If Mozilla includes a CA's root certificate, Mozilla implies that the rest of us should trust that certificate. My initial review of CACert's "Certificate Policy" did not give me a good feeling about trusting them. The start of my second review was more positive, but I did not complete that effort.

Several of those who have commented here appear dissatisfied with the Mozilla process for approving CAs and their root certificates. If you don't care about a thorough review of a certificate authority, you are free to go to <http://www.cacert.org/certs/root.crt>, download CACert's root certificate, and install it on your own PC. You would then bypass Mozilla, take control of the situation, and assume any risks. If you don't want to assume the risk that a CA is negligent or outright incompetent to control the use of its root certificate, however, don't ask Mozilla to assume that risk (and thus risk a lawsuit when someone loses money as the result of trusting an untrustworthy CA) without a thorough review.

By the way, comments here should be limited to technical issues and status reports. Flame wars, conspiracy theories, etc are not appropriate.

[Sehh (sehh)]

Understood, but in the same spirit why should we trust the existing authorities that exist in mozilla/firefox in the first place?

Their commercial nature and methods of verificiation and authenticity aren't trustworthy as far as anyone here is conserned.

Did they pass a similar level of scrutiny? I don't believe so.

Or maybe we are forced to accept them because if we didn't then mozilla/firefox would be in a difficult position market-wise since most secure websites wouldn't work and thus make the browser seem incompatible to the user?

[Finlay-dobbie (finlay-dobbie)]

This has been discussed at some length. Please read the entirety of the comments in the bug, and the corresponding non-technical discussions in the forums pointed to by the comments and continue this discussion in those forums.

[Nelson-bolyard (nelson-bolyard)]

(In reply to comment #114)

> if somebody can mangle that into a useful news: URL, go for it.

news://news.mozilla.org:119/mozilla.dev.tech.crypto

[Phr-mozilla (phr-mozilla)]

I got here by way of visiting a site using a cacert.org certificate, then trying to figure out what the heck kind of assurance such a certificate provides. After something like an hour of surfing around the cacert.org site, I haven't found an answer. There is no way I'm going to install the cacert.org root in my browser under these circumstances and I certainly wouldn't want MF installing it by default.

Nelson Bolyard's comments on this thread are well taken, as are others that expressed severe reservation towards those advocating opening up the Mozilla distro's default CA root store to contamination by any dweeb with a PC calling himself a CA. AIPCA audit is probably the right way to do this. There has to be not only technical evaluation of the CA, but also of its financial resources, to attest that it can incur liability if something goes wrong. That really means this is the wrong business for a small nonprofit to be in.

The story about someone fooling Verisign is overblown: it's a "dog bites man" story. And as I remember, the root that signed that cert (it was an IE code signing cert so it didn't affect NS) got replaced in the next IE update, which may have been pushed out early. I have no idea how much (if anything) Verisign paid Microsoft to make that replacement happen, but if I have to guess I'd say "a lot". Is Cacert ready to do that if it finds that it issued a bogus cert?

I agree with whoever said that Mozilla and Firefox's credibility will be shot if it installs this root in the current state of things. I dislike the relentless advocacy of the cacert.org ideologues pressing for inclusion. Cacert doesn't seem to operate at the level of the commercial ca's, even the cheesy ones like InstantSSL. It's at about the level of a typical in-house CA, which normally would put its root into a small set of browsers (those used only by people in the organization with the CA), not spread far and wide into the general browser population, presenting a huge target.

Also, the "included but disabled" notion is silly, as others have described. Importing a .crt file is no big deal technically--the scary part is the warning dialogs describing the extremely dangerous operation in process, and those should NOT be toned down. Any "enable the included disabled cert" dialog should be equally scary, and therefore inclusion without enablement does nothing.

I've been getting FreeSSL certificates (low end brand of Geotrust), now a root but formerly chained to the Equifax root, for $15/year, which I find pretty affordable. If cacert's certs are ever going to be anything other than free, there's not much point to cacert's existence.

[Malcolm Scott (malcscott)]

(In reply to comment #122)
> I've been getting FreeSSL certificates (low end brand of Geotrust), now a root
> but formerly chained to the Equifax root, for $15/year, which I find pretty
> affordable.

Such certificates are also easy to obtain without much more identity verification than CAcert performs - when I signed up for such a certificate, I needed to prove I could receive email for my domain (as CAcert does) and prove that I had a valid phone number. These certificates are trusted by Mozilla (and other browsers).

I think more consistency is needed: personally I trust CAcert about as much as FreeSSL/RapidSSL, as the assurance / identity verification that they provide is similar, but Mozilla differentiates them.

[Rich-thefreemanclan (rich-thefreemanclan)]

It really comes down to whether mozilla.org is willing to assume liability for vetting certificate providers. If so, they need to have a policy and apply it evenly. If not they should probably not include any certificates, or should include anything that anybody sends them.

Personally, I'm not inclined to trust AIPCA to make an assurance that a CA provider is trustworthy. After all, the various standards bodies certified that Verisign knows what it is doing, and yet they issued an MS code signing certificate.

That is a VERY big deal - if they had issued one for anybody other than MS, I doubt that MS would have sent out an update. MS didn't do it out of concern for Verisign, or even for a chunk of change most likely. They did it because they didn't want their name associated with the latest virus, and because they had the power to do it.

In fact, the MS debacle shows just how backwards Verisign actually is. They should just maintain a CRL and require that it be queried routinely (instead of off by default like it is in most apps). Then they could revoke the cert without cooperation from anybody.

As far as CACert goes - it provides an assurance that whoever is using the certificate was able to maintain control of the domain/email it is assuring. I'd probably alter the algorithm to require a 1 week waiting period on certs, during which the domain would be tested several times randomly - this would prevent somebody from hijacking the domain for 5 minutes and getting a cert - holding onto it for a week would be much harder.

Personally I put more stock in something like this rather than somebody who only assures that you were able to write a check for $15-200 and send in some convincing-looking letterhead (which can be generated on a laser printer for 25 cents these days).

If on the other hand we want to take a leave-it-up-to-the-users approach with regard to trust, the only neutral position really is to just not include certs at all.

[Helm-fionn (helm-fionn)]

> And as I remember, the root that signed that cert (it was an IE code
> signing cert so it didn't affect NS) got replaced in the next IE update ....
> Is Cacert ready to do that if it finds that it issued a bogus cert?

Surely that is not our standard for dealing with a bogus cert.

I don't remember the "root CA replacement" component - I remember a lot
of arguing about process and CRL management - but it's been quite a while.

It seems like people are searching for infallibility ("assumes liability"
sounds like, in practice, another requirement for infallibility). But maybe
it would be more useful to look at how issuers deal with certificate
validation, challenges, and other matters related to revocations.

[Rich-thefreemanclan (rich-thefreemanclan)]

This is starting to drift a little off the topic of cacert, but the MS certificate wasn't resolved by issuing a new root (to my knowledge), but rather by hard-coding the bad certificate ID into IE so that it would be automatically rejected by the browser.

If anything this highlights a key weakness in the whole certificate process - revocation. The problem is that many/most browsers do not check CRLs by default, and many CAs do not properly support this (I used to get numerous errors when checking CRLs due to CRL servers having problems).

If a goal is to drive CAs to be more secure, one mechanism would be to make the default be to check CRLs, and not include root CAs unless they maintain CRL servers with good availability.

[Olek Wojnar (olekw)]

> If a goal is to drive CAs to be more secure, one mechanism would be to make the
> default be to check CRLs, and not include root CAs unless they maintain CRL
> servers with good availability.

I personally use CAcert and they actually have a very good CRL system. Couldn't understand from the previous posts why the bogus certificate wasn't just revoked...

[Rich-thefreemanclan (rich-thefreemanclan)]

Unfortunately, IE does not check CRLs by default, so 99.9% of home users would have not detected the revoked cert. Hence the move by MS to sidestep the CRL and hard-code the invalid cert into IE. My guess is that if Verisign had issued the certificate for "Oracle Corporation" MS would have been happy to leave their users vulnerable...

[Phr-mozilla (phr-mozilla)]

I think it comes down to: MF is probably open to more trouble if it ships a root that MS doesn't ship, than if it only ships roots that are also in IE. If there's going to be a race to the bottom in root acceptance laxness, let Microsoft lead it.

As for FreeSSL, yeah, I wish they'd tighten up their procedures, but they do get a voice examplar from the phone call, plus a traceable financial transaction through the credit card payment.

The AICPA audit apparently includes a number of procedural and physical security checks, which I expect them to be good at doing if they do it to banking operations.

I just don't sympathize that much with the desire to put semi-home-made CA roots into the default browser distro with no serious auditing. It's like asking drugstore chains to sell cough syrup that was made in somebody's bathtub with no FDA approval. If there's something one can point to as "best practices", I'd rather follow that. It's certainly a way of putting the heat somewhere else.

[Hecker-hecker (hecker-hecker)]

My apologies for the delay in getting to this bug. I updated my list at <http://www.hecker.org/mozilla/ca-certificate-list> to note that the current versions of the root and CA policies are 1.2, dated February 22, 2006.

At this point we have enough information to evaluate this CA for inclusion, per the official CA policy at

http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html

Here are my quick thoughts on StartCom vis-a-vis the policy's requirements:

Section 4. I'm not aware of any technical issues with StartCom-issued certificates. If any sees any technical problems with the certs themselves please note it in this bug report.

Section 6. StartCom appears to provide a service relevant to Mozilla users: It issues no-charge certificates for SSL server use as well an personal email certificates. Policies are documented in the overall policy document and intermediate CA document published on the StartCom site and listed in the ca-certificate-list page referenced above.

Section 7. StartCom appears to meet the minimum requirements for subscriber verification: For class 1 personal certificates Startcom verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate. (See page 16 of the policy document.) For class 1 SSL server certificates StartCom verifies domain control by sending an email to one of the standard addresses (webmaster@domain, etc.) associated with the domain. (See page 15 of the policy document.) StartCom also issues class 2 personal and server certs, with additional verification required. StartCom does not currently issue code signing certs.

Section 8-10. StartCom has successfully completed an independent audit using the WebTrust for CAs criteria. The auditors were We! Consulting.

Section 13. StartCom has multiple intermediate CAs under a single root. Class 1 certificates are issued under different intermediates than class 2, etc.

Other: StartCom issues CRLs (on a 12-hour schedule) and also has an OCSP responder.

Some open questions:

1. Given the obvious possibility of StartCom's service being used to obtain free SSL certs for phishing sites, what is StartCom's strategy to deal with possible fraudulent use of the service? Is it limited to certificate revocation based on reports of possible fraud, or are other measures in place or planned?

2. StartCom doesn't appear to have an official WebTrust seal. why?

3. CRL publication is on a 12-hour schedule. Is the OCSP responder's data from the CRLs (and thus might be up to 12 hours old) or is it more up-to-date?

I'm opening up a period of public discussion of this request. I'll post on the mozilla.dev.tech.crypto newsgroup to start the discussion.

[John-jlgodfrey (john-jlgodfrey)]

I just wanted to say that I've used startcom's free ssl certs for over a year, and have found eddy and company to be extrememly helpful and patient. They have responded quickly to any question I've had. When I've needed a cert revoked, due to an updated distro (and poor backups on my part), they've taken care of this very quickly, too. They have a good forum for answers, respond quickly to emails, and you can even 'skype' them if the need is there.

Thanks Eddy & startcom for a great product!

John F. Godfrey, Pastor
Valley Christian Center

[Eddy-nigg (eddy-nigg)]

(In reply to comment #12)
>
> Some open questions:
>
> 1. Given the obvious possibility of StartCom's service being used to obtain
> free SSL certs for phishing sites, what is StartCom's strategy to deal with
> possible fraudulent use of the service? Is it limited to certificate revocation
> based on reports of possible fraud, or are other measures in place or planned?
>

The pricing policy of StartCom, and the fact that certain products and certificates
are provided free of chare, is not relevant to the question above. The validation
of certificates is a function of the controls, verification procedures and validation
in place, not the cost of the certificate.

Example: In the past we used to issue Class 2 certificates without charging any fees
(and we might do so again in the future). Did this change the validity of the
certificates issued? Or were the certificates issued according to a certain criteria
and procedure, in this case according to our definition of Class 2?

StartCom conforms or exceeds to the minimum requirements of the Mozilla CA
Certificate Policy section 7, even in the free Class 1 settings. So the question
about fraudulent use affects any Certification Authority which provides "so called"
domain validated certification and is not unique to StartCom.

With the exception of domain validation, StartCom has additional measures in place
to minimize the risk of misuse and fraud:

    * The StartCom CA and the process of certificate issuance are constantly
      monitored.
    * The process of certificate issuance may, under certain circumstances,
      be stopped manually or automatically. At that point, the request requires
      manual intervention and review by StartCom personnel.
      Additional information might be requested and any verification procedure
      implemented (Similar to Class 2 verification). Any certificate request in
      the Class 1 settings can get "flagged" for such a human review.
    * All certificate details are reviewed by StartCom personnel and additional
      information may be requested from the certificate holder. If in doubt,
      the certificate could get revoked immediately.
    * Random visits of the web sites are performed by StartCom to detect fraudulent
      sites.
    * Fraudulent websites, as well as sites that damage the reputation of the CA
      may be reported to the proper authorities and prosecuted to the full-extent
      of the law.

> 2. StartCom doesn't appear to have an official WebTrust seal. why?
>

A third party audit was performed by the "We! Consulting Group", which is a respected
solution and consulting provider in Israel, with great expertise in Public Key
Infrastructure solutions and renowned costumers. The audit performed was based on the
AICPA/CICA Webtrust for Certification Authorities Criteria and confirmed as such.
However the We! Consulting Group is not a licensed WebTrust provider.

> 3. CRL publication is on a 12-hour schedule. Is the OCSP responder's data from
> the CRLs (and thus might be up to 12 hours old) or is it more up-to-date?
>

In practice CRL's get updated every 12 hours or when a certificate is revoked,
especially...

[David-rossde (david-rossde)]

I posted my somewhat lengthy analysis in the <news://news.mozilla.org:119/mozilla.dev.tech.crypto> newsgroup, in the "StartCom CA inclusion request" thread.

[Hecker-hecker (hecker-hecker)]

Eddy, thanks for your reply. I have at least one other question, as noted below.

(In reply to comment #14)
> A third party audit was performed by the "We! Consulting Group", which is a
> respected solution and consulting provider in Israel, with great expertise
> in Public Key Infrastructure solutions and renowned costumers. The audit
> performed was based on the AICPA/CICA Webtrust for Certification Authorities
> Criteria and confirmed as such. However the We! Consulting Group is not a
> licensed WebTrust provider.

Could you point us to relevant public documentation in English demonstrating We! Consulting's expertise in information security audits and evaluations and CA and PKI issues in particular? Their web site <http://www.we-can.co.il/> is in Hebrew, and I can't find an English version; also Google was not helpful in terms of turning up third-party references to We! Consulting (e.g., news stories, case studies, etc.).

Given that We! Consulting is not an authorized WebTrust auditor we need something else to give us confidence that they're competent to perform an audit against the WebTrust criteria (or similar criteria, for that matter).

[Eddy-nigg (eddy-nigg)]

(In reply to comment #16)
>
> Could you point us to relevant public documentation in English demonstrating
> We! Consulting's expertise in information security audits and evaluations and
> CA and PKI issues in particular?

This information is not publicly accessible by the Internet. I'll forward all relevant and available information to you.

[Hecker-hecker (hecker-hecker)]

Thanks to Tsahi Asher I have more info on We! Consulting. The page

http://www.we-can.co.il//heb/pagesContent/content.aspx?pageID=3&Scroll=true

(in Hebrew) mentions some of We!'s customers for which they've done security-related work; they include two banks, two cellphone
companies (including Orange), a food company, an insurance company, an academic institute, and Tower Semiconductor. Apparently We! has done deployment of PKI implementations (including CA deployment), auditing of existing PKI deployments, and provided consulting support to assist enterprises operating CAs in operating according to relevant standards and guidelines. So I think that we can accept We! Consulting Group as being an independent and competent third party evaluator as required by the CA certificate policy.

[Krash (gkrasovic)]

Just as a thought here,

What if, instead of including more root CA's in the browser, you include NO CA's in the browser, and come up with a more intelligent way of notifying the user that they're accessing a site, and walk them through verifying the CA that signed that servers key?

Maybe a dialog box like:

"an organisation known as CACert is verifying that ptywidgets.com belongs to PTY Widgets Inc. - click _here_ for more information about PTY Widgets Inc, or _here_ for informmation on CACert"

(buttons)
"*trust CACert's verifications always* - *trust PTYWidgets.com always* - *cancel*

let the first button install the CA's root cert, let the second button install ptywidgets.com's cert,

I would have to think this would make users in general more aware of the twofold nature of SSL transactions, rather than the confusing dialog boxes that are present in modern browsers when you hit a site signed with a non-stock CA.

[Hecker-hecker (hecker-hecker)]

Based on the information I have thus far, I'm approving inclusion of the StartCom CA root certificate in NSS/Mozilla. I'll now go off and file a bug against NSS for the actual work.

[Hecker-hecker (hecker-hecker)]

Per my comments in bug 289077 I'm approving inclusion of the StartCom root CA certificate in NSS/Mozilla; trust bits should be set for SSL server use and S/MIME email use. The bit for object signing should be OFF, as StartCom does not issue object signing certificates at present and is not planning to do so in the foreseeable future.

The CA certificate itself is located at <http://cert.startcom.org/ca.crt>. Its SHA-1 fingerprint is 95E6 ADF8 D771 4602 4DD5 6A21 B2E7 3FCD F23B 35FF as listed on the StartCom FAQ page <http://cert.startcom.org/?lang=en&app=110>, and computed by NSS when downloading the cert in question. I've double-checked the fingerprint via a phone call with Eddy Nigg of StartCom.

[Hecker-hecker (hecker-hecker)]

Created an attachment (id=222630)
StartCom root CA certificate in PEM format

Attaching a copy of StartCom's root CA certificate as downloaded from <http://cert.startcom.org/ca.crt> today.

[Evaldo Gardenali (evaldo-gardenali)]

Nice!

All those policies, all those expensive audits, all those papers, then the fingerprint is checked by phone? Is that the security I should expect from Mozilla?

This has really let me a bit upset, and it means I really should disable every CA when I install my desktop, as I use to do. Then I can re-enable the ones I verify/trust, and add the others that dont have 75k/year to throw away with WebTrust but dont rely on phone for security :/

Also, I would obtain the root certificate using offline, trusted medium, since collision attacks are highly improbable and theoretical, but still possible. I dont know what 3-letter-agencies or multi-billion-dollar-companies have in their basements.

Sure, the policies and other documents are somewhat necessary/useful, but totally useless once the key is downloaded via untrusted medium and checked via untrusted medium (there are many guys that could fake a voice over the phone, you know?).

[Nelson-bolyard (nelson-bolyard)]

Reassigning bug to default assignee until we can figure out who will do this.

[Hecker-hecker (hecker-hecker)]

(In reply to comment #2)

I've had multiple communications with StartCom both via email and by phone, with independent verification of the phone number and email address. I have no reason to believe that my communications have been spoofed or other maliciously manipulated.

Note that I'm not opposed on principle to adding additional communications channels to ensure we're getting the right root CA certificates. However I'm not going to do this in an ad hoc manner in this particular instance. Feel free to open a thread on the mozilla.dev.tech.crypto newsgroup (dev-tech-crypto mailing list) on this topic, and we can discuss what particular mechanisms might be appropriate for future use. (Just saying "offline, trusted medium" begs the question somewhat, especially if your threat model includes a TLA as the attacker.)

[herrold (herrold)]

It seems the high level chain of trust is satisfied with a a cert inclusion on a simple telephone call ... too bad cacert is not so loved

https://bugzilla.mozilla.org/show_bug.cgi?id=289077
https://bugzilla.mozilla.org/show_bug.cgi?id=338552

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

Thanks for posting those links. Your comment notwithstanding (there was lots of process involved), it looks like StartCom has cleared the hurdle of getting Mozilla inclusion without an official WebTrust audit, but using the 'equivalent audit' mechanism of the new Mozilla policy document.

This is *good* news for CACert. Now, StartCom appears to have a linux distro business that probably funded the We! Consulting audit, an advantage over a community group like CACert, but it's precedent and shows that if CACert can get an audit done the prospects look good!

[Hecker-hecker (hecker-hecker)]

(In reply to comment #132)
> This is *good* news for CACert.

In this regard please see my comment 115 above.

https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c115

To repeat: Per our current policy, CAs need to have independent evaluations/audits of their operation; this does *not* have to be an official WebTrust audit. (See the policy itself for the actual details.) CAcert has not yet had such an evaluation/audit, so it's not yet in a position where I can consider it for approval. (Note that StartCom made their original request over a year ago, and also had to wait until they got an evaluation/audit done.)

(Incidentally, I forgot to accept this bug as being officially assigned to me; I'm doing that now.)

[Eddy-nigg (eddy-nigg)]

Created an attachment (id=223625)
Proposed patch for adding StartCom CA

This is a proposed patch. Please contact me in case 1) Any developer of Mozilla prefers to make the match 2) The patch has a problem (can not be applied etc) 3) Trust settings are not correct. For No 3, I was not sure and documentation is somewhat unclear concerning that one...

Patch should apply to the current cvsroot (checkout): patch -p0 -i startcom-ca.patch

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 223625)
Eddy, you can't give your own patch r+, but you can request review with r?
(I've done that for you here.)
Your patch should be a "unified diff", the output of
cvs diff -u filename

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 223625)
unfortunately, this patch is not in a format that enables bugzilla's patch reviewing tools to work on it.
In your cvs source tree, please replace the originaql file with your modified file, then do
cvs diff -u9 <filename> > patchfile
and then attach patchfile here. Thanks.

[Eddy-nigg (eddy-nigg)]

(In reply to comment #7)
> (From update of attachment 223625 [edit])

OK, tried it again with your instructions (I hope the path is correct). Please verify and check...

[Eddy-nigg (eddy-nigg)]

Created an attachment (id=223666)
certdata.txt with StartCom CA

[Eddy-nigg (eddy-nigg)]

Created an attachment (id=223667)
certdata.c with StartCom CA

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 223666)
These unified diffs have the right format to be reviewed. Thanks.

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 223667)
I'm not sure why these diffs show different RCS revision numbers. But I'm not sure it's important.
Requesting review, on your behalf.

[Wan-Teh Chang (wtc-google)]

(From update of attachment 223666)
I verified that this is the same as the output of
    addbuiltin -n "StartCom Ltd." -t CT,C,c

[Wan-Teh Chang (wtc-google)]

(From update of attachment 223667)
It's not necessary to review the patch of a generated
file.

The different RCS file names and revision numbers in
the CVS_ID string are an artifact of our checking in
this generated file. The generated value is correct;
it shows that certdata.c is generated from this version
of certdata.txt using this version of certdata.perl.
When you check this in to CVS, the file names "certdata.txt"
and "certdata.perl" get changed to "certdata.c", and
their revision numbers changed to that of certdata.c.

The reason we checked this file in to CVS was that we
had problem running certdata.perl during the build in
the classic Mac build system. Now that all the platforms
we support use GNU makefiles, we can go back to running
certdata.perl during the build. On the other hand, the
CVS_ID string is only used in debug builds, so it may
not be worthwhile to make this change.

[Nelson-bolyard (nelson-bolyard)]

Wan-Teh, I agree there's no need to review computer generated files IFF
you trust their source, e.g. if you generate them yourself. Given that
you've obsoleted the certdata.c file, I gather you intend to do just that.

[Wan-Teh Chang (wtc-google)]

I added StartCom CA to the NSS trunk (NSS 3.12).

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c
new revision: 1.37; previous revision: 1.36
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.tx
t
new revision: 1.38; previous revision: 1.37
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h
new revision: 1.15; previous revision: 1.14
done

[Wan-Teh Chang (wtc-google)]

I added StartCom CA to the NSS_3_11_BRANCH (NSS 3.11.2).
Note that the CA still needs to be propagated to the
Mozilla trunk and the MOZILLA_1_8_BRANCH (for Firefox 2.0).

Checking in certdata.c;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c
new revision: 1.36.24.1; previous revision: 1.36
done
Checking in certdata.txt;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.tx
t
new revision: 1.37.24.1; previous revision: 1.37
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h
new revision: 1.14.2.1; previous revision: 1.14
done

[Paul Bryan (pbryan)]

According to the CAcert web site [1], the root key is stored on a root store server. While the server has employed various methods to avoid external compromise, it seems to fail to address a signifcant flaw in its trust model. Namely, the integrity of the trust model for CAcert.org relies on trusting those who manage this server, and most especially, those who have both physical access to the server and have the password.

In my opinion, it is unacceptable to have the trust model of a root certificate rely on any single individual (or group of individuals with full access) to manage a root certificate private key. It probably goes without saying here that in a PKI, a breach of the root private key is a catastrophic, unrecoverable, systemic breach of security for those who rely on it.

I strongly urge Mozilla to consider very carefully the consequences of accepting a root certificate, where the trust model relies on an individual not to abuse access to the root private key, without any apparent checks and balances in place to mitigate such unadulterated access.

[1] CAcert Root Protection
http://www.cacert.org/help.php?id=7

Please do not hesitate to contact me personally to discuss this matter in more detail.

[Trejkaz (trejkaz)]

Unfortunately, this issue of having to trust the people with access to the key is present in any CA, or at least any CA which employs a system administrator.

[Gunnar Wagenknecht (g-u-w)]

(In reply to comment #134)
> In my opinion, it is unacceptable to have the trust model of a root certificate
> rely on any single individual (or group of individuals with full access) to
> manage a root certificate private key.

So I don't see a difference there to the StartCom procedure except that the individual is called "CEO". But according to a German news site (http://www.heise.de/newsticker/meldung/73850) Mozilla seems to trust this procedure (bug 338552).

[Finlay-dobbie (finlay-dobbie)]

(In reply to comment #136)
> So I don't see a difference there to the StartCom procedure except that the
> individual is called "CEO". But according to a German news site
> (http://www.heise.de/newsticker/meldung/73850) Mozilla seems to trust this
> procedure (bug 338552).

From bug 289077, StartCom has undergone a 3rd party audit showing it adheres to the relevant criteria. As far as I am aware, CACert has still not undergone such an audit. Frank Hecker has stated this as the current hold-up.

[Bugzilla+nospam (bugzilla+nospam)]

Wan-Teh,

Is there any reason to keep this bug open now that the checkin was completed ?

[Wan-Teh Chang (wtc-google)]

Kai, please remember to add the fixed1.8.1 keyword to this
bug when you check in a new NSS_3_11_BRANCH snapshot on the
MOZILLA_1_8_BRANCH.

[Kai Engert (kaie)]

fixed1.8.1 with bug 340724

[Allison Karlitskaya (desrt)]

any word on progress here? closing this bug would make an awful lot of people happy.

[JLeaf (a-dessalvi)]

In Italy there's a growing interest for this initiative, their notary are very serious, everything seems to be well organized and checked. Their site is fast and reliable, their policy seems good.

Please support them, there is no reason to feed thawte-verisign for something that everyone needs like air: safety on internet.

I'm trying to collect enought trust point to sign my java software, many of my friends appreciate this idea: a software that you can trust.

I know that Mozilla can really understand this need (and we all appreciate you work but also your mentality)

Please check and then support them.

[Mozilla-kodespace (mozilla-kodespace)]

To me this problem could perhaps be solved in a completely new and enlightened way.

Rather than having all this banter: 'is this CA worthy', 'who decides the worthiness', 'this CA is better than that one'. What seems quite obvious is that:
a) Mozilla does not want to tarnish it's name by adding untrustworthy CA's
b) New CA's who may (or may not) be worthy need to be trusted, ultimately, by one body.
c) Root CA's that are not listed as part of a product (eg Mozilla) as pretty much as good as a self-signed certificate, to the standard end-user. (they get prompted with lots of dialog boxes they must click OK in order to continue)

To me it seems obvious that Mozilla could add an automatic lookup in it's browser for unknown Root CAs. This lookup would be hosted on Mozilla's own site. In essence, it would operate like spamcop, or similar, where the community (and not individuals) has a say in who is trustworthy. A mandatory timeout (like a DNS) for a root cert would ensure that root CAs can also be blacklisted.

Here's a basic 'mud map' of how a system might work:
i) end user browses to a page with a site cert that requires root cert for XYZ.
ii) If the browser doesn't have XYZ, it contacts Mozilla for the cert.
iii) Mozilla responds with the cert with 2 extra items: how 'trustworthy' this cert is (like a spam level filter) and how often this root should be checked agaist the mozilla database (like a DNS lookup).
iv) If the cert isn't recognised, Mozilla can respond in VERY terse language suggesting that continuing may be really really bad (which is all most end user's want to know about).
v) Mozilla would also need to introduce a 'report a bad SSL site'. Clicking on this would report back to mozilla, the site cert and the root cert of the offending site. It's database would then be updated and the 'spam level'/trustworthyness indicatator may be adjusted accordingly.
vi) Root CA's would contact mozilla when they wish to announce themselves. Mozilla could then analyse requests for sites using this new root and then decide if it should be listed or not...and using what trusworthyness.

voila! problem solved. This system has the benefit of:
a) Allowing new roots (eg CA Cert) to become registered without needing to wait for another version
b) Blacklist Root Certs if they prove to be completely untrustworthy
c) Warn end users of highly suspicious site certs
d) Mozilla doesn't need to relay upon 3rd parties for arbitrage. They themselves decide an initial trustworthyness (probably just one level above 'blacklisted') and the community then decides for itself.

To me, this is would be the open community -style solution that we should expect from Mozilla.

Hope you like it.

[Finlay-dobbie (finlay-dobbie)]

Stop commenting on this bug.

[Sehh (sehh)]

I don't see why we should stop commenting on this bug. It is rather important even though the mozilla people seem to want this forgotten.

Appart from mozilla's silly excuses for not including cacert in their products, does anyone know the current status? Last time i checked they wanted cacert to go through some external audit.

[webograph (webograph)]

kodespace: the model sounds nice and i like it, but i doubt that the mozilla developers could agree with such a model, especially as to suit business users (the model seems more oriented towards end users).

personally, i think mozilla should use availible libraries such as openssl, thus delegating the question of trustworthiness to the surrounding system. on debian gnu/linux users, for example, firefox would trust all authorities accepted by the user in the debian openssl setup (or the default configuration).

finlay: could you give details on why we should stop posting on this topic? if you don't want to get mails concerning this bug any more, you can remove yourself from the cc list!

[Eyalroz (eyalroz)]

(In reply to comment #140)
Please open a separate bug about that.

[Justin Alan Ryan (justizin)]

kodespace: i'm not against the model you propose, but I feel rather strongly that this bug should not be dependent on a new vaporware system. I can't even estimate how many times I've updated my FireFox and Camino binaries since adding myself to the copy list on this bug.

webograph: finlay is gone, good riddance.

[David-rossde (david-rossde)]

Those demanding immediate action to install the CAcert root certificate need recognize not only why that is not happening but also a very effective work-around.

The process of installing a new root certificate follows a Mozilla policy that was thoroughly reviewed by the general public (via a newsgroup) over well more than a year. During that review, the policy went through 10 or more revisions because of comments from both developers and users. The goal of the policy is to ensure that users of Mozilla products can indeed trust new root certificates installed in those products. See the final policy at <http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html>.

The work-around is simple. For this -- or any other root certificate under evaluation for installation in Mozilla products -- go to <http://www.hecker.org/mozilla/ca-certificate-list>. Under the column "Certificate(s)", right-click the link of the certificate and select Save Link Target As to download the certificate. Then, within each Mozilla product where you want to install the certificate, import the file you just downloaded. As I noted before (comment #118), this means that you assume full responsibility for using the certificate without putting any liability for misuse by others on the Mozilla Foundation or the Mozilla Corporation.

[Sehh (sehh)]

Thanks for the garbage, we already know how to install a certificate.

The whole issue here is to have the CACERT root certificate installed in firefox/mozilla by default, we don't care about installing it by hand.

The whole idea is to by-pass the commercial certificates and allow people to use free CACERT certificates. Ofcourse, you already know that...

[David-rossde (david-rossde)]

If you already know how to obtain and install a root certificate, what is the urgency of having it pre-installed in Mozilla products? If the point is to have the implication of a stamp of approval by Mozilla, that stamp can be obtained only by following the Mozilla policy.

By the way, success is more easily obtained by refraining from rude comments.

[webograph (webograph)]

most people voting for the bug know how to install the certificate and, i guess, already did so.
in my opinion, this bug exists for two purposes:
- launch the process of certificate inclusion (i don't know what the sequence of events was exactly, maybe cacert was already in contact w/ the mozilla foundation before this bug was filed. by the way, is there any official document showing the status of negotiations?)
- underline the importance of cacert as an organization providing affordable secure communication for whomever needs such, by active participation of users in the progress and their votes for this bug.
in case the mozilla policies concerning trustworthy authorities will ever need re-thinking (which could be the case if no satisfactory agreement can be found with cacert), this discussion could also provide an initial discussion base (think of kodespace's suggestion)

[Sehh (sehh)]

I like it how you avoid the issue at hand and go around it by mentioning the policy.

Are you in politics by any chance?

By the way, success is more easily obtained by just adding the CACERT root certificate.

[Swbrown (swbrown)]

"If you already know how to obtain and install a root certificate, what is the
urgency of having it pre-installed in Mozilla products?"

That if you use CACert certificates, /other people/ will have them trusted. That of course means CACert needs properly audited and structured in a way to prevent a disaster, but the progress of that is unclear. Such a progress report would be welcome.

[Rich-thefreemanclan (rich-thefreemanclan)]

(In reply to comment #148)
> If you already know how to obtain and install a root certificate, what is the
> urgency of having it pre-installed in Mozilla products?

Well, that logic would suggest that we not include ANY root certs in the browser, so that every secured website pops up all kinds of alarm bells. Except, by doing that you're going to relegate Mozilla products to irrelevance to the common user.

In the same way, by not including the CACert in the brower, you're relegating their certificates to irrelevance to the common website owner. Would amazon.com want to have Firefox pop up all kinds of bells and whistles when a customer drops by?

It seems strange that Mozilla wouldn't see CACert as a natural partner. In theory both have a goal of creating an open community solution to web standards.

Offering workaround solutions to those tracking this bug isn't very useful - having CACert listed as a trusted root CA doesn't help CACert users who using Mozilla products. It helps website owners who are CACert users who have visitors using Mozilla products. Those visitors have never heard of CACert, just as they've never heard of Verisign/Thawte/etc, and it is very unlikely that they'd be able to implement these sorts of workarounds.

[Peter-lairo (peter-lairo)]

Please stop spamming this bug. Before placing a comment in this bug, please read:

- The "Status Whiteboard" (discussion here: http://tinyurl.com/ye67xs)

- comment #115 !!!

- comment #118

- Last, but not least: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

[Mozilla-kodespace (mozilla-kodespace)]

(In reply to comment #144)
bug#363305 has been opened as requested.

Note that I modified the description to include that well-known root CA's (Verisign,Thawte, etc) should be included in the product when shipped. (That was my initial intention anyhow...but I neglected to mention it).

[Rich-thefreemanclan (rich-thefreemanclan)]

(In reply to comment #153)
> Please stop spamming this bug. Before placing a comment in this bug, please
> read:
>
> - The "Status Whiteboard" (discussion here: http://tinyurl.com/ye67xs)
>

Not much new there - just that it is pending.

> - comment #115 !!!

Regarding 115 - would it be possible for Mozilla to perform the independant 3rd-party audit of CACert? Finding somebody willing to perform audits of CAs not involving thousands of dollars seems to be a problem. If it isn't too much to ask free CAs to go through this then Mozilla certainly should be able to help out. If it is too much to ask, then perhaps the policy could be adjusted in some way that would make it work.

Perhaps one solution would be to charge commercial CAs to have their certs included, and use the resulting revenue to provide free audits to free CAs. After all, the only reason people pay for commercial CAs is because they're listed in browsers, so the value is actually being generated by Mozilla - so why not recoup some of this value?

>
> - comment #118
>
> - Last, but not least: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
>

Couldn't agree more - there really is no need to be rude when posting here - and comments should attempt to make forward progress in resolving the bug. Obviously the bug has been open for a long time and that will tend to lead to frustration, but I'm sure that somebody will eventually come up with a workable way to get CACert added to the Mozilla CA list.

[Nelson-bolyard (nelson-bolyard)]

Frank filed bug Bug 338552 to fulfil this request, and it was completed in
mid 2006. So I am marking this request resolved/fixed.

Subsequent to this request, another request has been made to include an
additional startcom CA cert. That is the subject of bug 362304.

[Hecker-hecker (hecker-hecker)]

Adding a priority to this bug for consistency with other CA-related bugs. Assigning priority P3 given that this request is currently in limbo pending resolution of the audit question.

[Gervase Markham (gerv-mozilla)]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

[Iang-iang (iang-iang)]

I've just been made aware of comments on this bugtrack that deserve some response, apologies for the delay.

As brief as I can make it: in December of 2005 I took on the role of Independent Auditor of CAcert's Certificate Authority. This task is guided by David Ross's Criteria ("DRC"), mentioned earlier by David Ross himself, and earlier pre-approved by Mozilla for their purposes.

Around June 2006, the audit process discovered severe imbalances in the contractual relationships between CAcert, its user community, Assurers and the world at large, as found by DRC. In October 2006, server issues arose which caused a difficult migration, still on-going. These also do not meet DRC.

Although these combined issues are being worked through, they caused CAcert to realise that it had outgrown its ability to manage as a tight, developer-driven open source organisation. Although the community is very keen, and the product is very valuable to its users, it now needs a stronger and broader management structure.

In December 2006, I therefore suspended the audit until that could be put in place to handle the difficult international responsibilities. Until resolved, CAcert is formally not seeking access to root lists, partnerships or the like, at the current time. This includes the list managed by Mozilla Foundation. Until CAcert's many tasks are complete, everything is in a "holding pattern" including any addition to browsers.

I can observe, but not promise, current progress: Members of the Association and others are working to meet the requirement for management over the coming months. Work is ongoing on the server transition, and announcements may happen on that.

For all CAcert's promise, the audit remains a serious process and a difficult hurdle. It works to a criteria that is objective and repeatable. The result is intended to be reliable and comparable. We may have our comments to make outside, but inside, we have a defined task. It is up to CAcert to do what is required, and they will get there in due course, or choose another path.

In the meantime, there is no point in pressuring Mozilla on the issue. Better if you wish to help, join CAcert as a user and contribute on their large task list.

Ian Grigg, Independent Auditor for CAcert's CA.

[Nelson-bolyard (nelson-bolyard)]

Gerv,

In light of IanG's statement:
> Until resolved, CAcert is formally not seeking access to root lists,
> partnerships or the like, at the current time. This includes the list
> managed by Mozilla Foundation.

I propose that this RFE be marked WONTFIX or INVALID. Then, if and when
CACert is ready to pass the audit and try again, I'd suggest they file a
new RFE for that request.

[Gervase Markham (gerv-mozilla)]

I concur. Section 14 of our policy
http://www.mozilla.org/projects/security/certs/policy/
says:

"We will reject requests where the CA does not provide such information within a reasonable period of time after submitting its request."

I consider this to be true of CACert, and Ian's comment #158 confirms that the information is not likely to be forthcoming shortly. I just hope that this won't result in too many duplicate bug reports from people who don't search carefully enough.

Note to any potential easily-excitable readers from Slashdot: this is not a "No", this is an "both sides agree CACert is not ready to formally apply yet".

Gerv

[Rich-thefreemanclan (rich-thefreemanclan)]

You say that both sides agree.

Has CACert indicated that they aren't seeking approval at the moment. The previous post was by an auditor independant of CACert.

Also - should CAs be required to seek approval - is there a problem with users requesting that CAs be added if the CA does not seek this approval? Shouldn't users of CACert and mozilla products be able to request the approval of the root cert?

I haven't seen any concerns raised with how CACert issues certs or verifies identity, but just general issues regarding their ownership structure and whether they have been audited. If mozilla were held to the same standards during the early days it probably would have never taken off. It just seems like as an organization we should be trying to foster open source projects. If CACert can't meet mozilla's requirements, perhaps mozilla ought to help them out a bit, or start a free certificate authority of their own?

[Gervase Markham (gerv-mozilla)]

(In reply to comment #161)
> Has CACert indicated that they aren't seeking approval at the moment. The
> previous post was by an auditor independant of CACert.

...who seems to be the only person capable of producing the audit documents. Unless CACert has a secret auditor no-one knows about who has nearly finished their audit?

> Also - should CAs be required to seek approval - is there a problem with users
> requesting that CAs be added if the CA does not seek this approval? Shouldn't
> users of CACert and mozilla products be able to request the approval of the
> root cert?

No. We require that the CA request approval themselves. This is because the inclusion process always requires some interaction with the CA, and so they need to be on board to provide it and answer questions. It also means we can be certain that we do not set a trust bit that the CA would not want set.

> I haven't seen any concerns raised with how CACert issues certs or verifies
> identity,

Perhaps because I have not examined their practices in this regard. It would be highly wrong to conclude that, because CACert has not undergone formal analysis by the MoFo, it would therefore pass such analysis!

> If
> CACert can't meet mozilla's requirements, perhaps mozilla ought to help them
> out a bit, or start a free certificate authority of their own?

I don't think CACert has stated that they can't meet the Mozilla requirements. And as far as I am aware, they haven't asked for our help either.

Bottom line: this bug has been open nearly four years, and all the information needed has not yet been presented. I consider four years more than "a reasonable time", and so have closed this bug. When and if CACert would like to present the information necessary, they can open another bug and do so.

Gerv

[Hecker-hecker (hecker-hecker)]

Gerv and I were trying to add comments at the same time. His comments in large part duplicated what I wrote, so I'll skip repeating his points. However I did want to add one comment to supplement Gerv's:

(In reply to comment #161)
> Also - should CAs be required to seek approval - is there a problem with users
> requesting that CAs be added if the CA does not seek this approval? Shouldn't
> users of CACert and mozilla products be able to request the approval of the
> root cert?

As Gerv wrote, we've previously indicated that we will accept requests only from CAs, not from users; if users want a particular CA to be included then the users should contact the CA directly. Here some reasons we do this, besides the reasons Gerv mentioned:

1. As a matter of common courtesy, if a CA explicitly doesn't want its root
cert to be included then we should respect that wish.

2. If a CA is unresponsive to others' requests regarding whether or not it
wants to be included, then it is also very likely to be unresponsive to our
requests for the information we need to evaluate whether that CA meets our
policies.

3. Some CAs consider their root CA certs to be copyrighted material subject to
limitations on redistribution. By requiring that CAs explicitly ask us to
include their certs, and by explicitly making them aware of our policies on
inclusion, we help ensure that we have any necessary permissions from the CA,
and that the CA is fully aware of how their certs will be used (or not used, as
the case may be).

[David-gigawatt (david-gigawatt)]

Rich Freeman <email address hidden> wrote:
>
> It just seems like as an organization we [The Mozilla Foundation]
> should be trying to foster open source projects.

Whoa, there. I'd just like to point out that CaCert is not an open source project in any sense of the term. It uses open source software *internally* to provide a free (as in beer) service, but CaCert distributes no free (as in *freedom*) software, and no software that could even remotely be considered open source. Just the opposite in fact, see the license here, on their site: http://www.cacert.org/src-lic.php

It clearly states that you:
  1. may NOT modify the source code [...]
  2. may NOT make copies of the source code [...]
  3. may NOT give, sell, loan, distribute, or transfer the source code files
     to anyone else, an, my favorite:
  4. may NOT use [CaCert] software created for any purpose or reason other than verifying that there are no unknown vulnerabilities or the like or otherwise making your own assessment of the integrity of the source code and the security features of the CaCert software

Furthermore, below it goes on: "All rights not expressly granted to you [editorial comment: which would be "none"] in these license terms are reserved by CAcert. CaCert retains ownership of all copyrights and other intellectual property rights throughout the world in the CAcert source code and software. You agree that CAcert will be given a perpetual non-exclusive rights to any and all derived code, and you hereby assign rights in any modifications you make to the source code and in any bug reports you submit to CAcert."

This just may be the single most disgusting and ill-advised hybrid software license I have ever read. The author apparently seeks to keep the software 100% proprietary, guarding it from "competitors", and protecting potential future licensing revenue, while simultaneously benefiting from the efforts the open source developer community to fix its bugs, and attest that it is not malware, for free.

Although I wrote an impassioned comment (#12 above, of 161 so far!)
https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c12 in *support* of CaCaert, uh, 4 years ago now, and was a CaCert user and Assurer, I discontinued my involvement because the source code was released by the founder only months later, after much prompting and delay, and when it was finally unveiled, these onerous licensing restrictions were "slipped in" with zero community discussion.

When I asked why the code was not made open source, the founder described his perceived threat that if it was made open source, then other free CA's would start popping up out of nowhere to run our code and to compete with CaCert and he felt that this would decrease CaCert's chances of getting its root cert into Mozilla, and then IE.

This seemed a paranoid and protectionist attitude and I've no longer participated in the Assurer program or the CaCert community since, though I have monitored the mailing lists. After the founder's recently announced resignation, perhaps the new board of directors (or whatever governing body structure they adopt) will revisit this anti-competitive, closed source positio...

[Nb (nb)]

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.

[Dtownsend (dtownsend)]

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

[denis labregere (ikerc)]

you must include cacert = ikerc

[iroli (roland-lezuo)]

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.

[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.