“firefox crash on exit if client certificates used for ssl auth”

--> Security/General

you must include

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.

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

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.

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

This bug was filed against the incorrect product. Reassigning.

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.

.

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

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

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

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.

For comment #14:
<email address hidden> bounces

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

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

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

(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...?

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.

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.

(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

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.

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.

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?

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?

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.

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

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

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.

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

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?

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

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.

(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

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

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

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.

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

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.

(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/

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.

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

Gerv

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.

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.

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

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?

(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

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

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

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.

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

you must include cacert = ikerc

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

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

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.

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

Please file your own bug.

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

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.

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

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/>.)

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

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

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

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!

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

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

"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).

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)

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.

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

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

(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/

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

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

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!

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

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