Closed Bug 215243 Opened 21 years ago Closed 17 years ago

CAcert root cert inclusion into browser

Categories

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

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: admin, Assigned: gerv)

References

()

Details

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

Attachments

(2 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

There is a growing need to secure servers via SSL/TLS, and, in many 
cases, self signed certificates aren't appropriate. CAcert's aim is to 
cover the more traditional applications such as web and email, but is 
also extensible enough to be used in IRC and many wireless 
applications. Current commercial offerings are discriminatory toward 
individuals and unincorporated bodies, due largely to their high 
cost along with the practice of proving domain ownership through proof 
of business registrations, and articles of incorporation. 

The number of issued CAcert certificates grows daily, and number of 
people relying on these CAcert certificates is a multiple of that. We 
are not without troubles, though; continued growth is going to be 
difficult without having a root certificate in mainstream applications 
like web browsers and email programs. 

We believe that having our root certificate included in your browser 
would be beneficial to both of our organisations. Since your browser 
would be the first to ship with CACert root certificate included, it 
would be listed as our recommended browser. We see a huge potential 
for cross referrals - our users choosing your browser, recommending it 
to friends who use personal certificates as well as colleges and other 
not for profit institutions; your users having instant access to a 
free certificate authority for their websites. 

I'd like to thank you all in advance for your consideration and I look 
forward to the possibility of working with you in the future. Please 
contact support@cacert.org with any additional questions or concerns you may 
have regarding this system. 

I believe, after reviewing and using first hand, the CACert Certificate 
Authority system, I find this system to be fabulous. I would like to request 
that the root certificate key be included with Mozilla Firebird to help both 
Mozilla and CACert. This would make a wonderful addition for everyone. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
--> Security/General
Assignee: general → security-bugs
Component: Browser-General → Security: General
QA Contact: general → carosendahl
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Summary: [RFE] Cacert root cert inclusion into browser. → [RFE] CAcert root cert inclusion into browser.
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
Summary: [RFE] CAcert root cert inclusion into browser. → CAcert root cert inclusion into browser
Blocks: majorbugs
This bug was filed against the incorrect product. Reassigning.
Component: Security: General → Libraries
Product: Browser → NSS
Version: Trunk → 3.8
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. 
.
Assignee: security-bugs → wchang0222
QA Contact: carosendahl → bishakhabanerjee
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 the very critical responsibility for deciding who we trust, to the 
signer of those certificates.  

A non-commercial entity like CACert.org is and has been needed for some time, 
in my opinion, and I for one would be quite relieved to see a group that I 
really do trust, such as The Mozilla Organization, take the all-important first 
step in dispelling this myth (that the commercial software and service 
companies would like the public to believe) that SSL certificates are only 
as "trustworthy" as the price one pays for them, or that big corporations are 
the only places I can feel safe placing my trust.  Mozilla and other open 
large, quality open source software projects are already shattering similar 
myths about the relationship between *good* software and commercially developed 
software, and it would be great to have Mozilla blaze the trail toward the 
creation of a network of Truly Trust-worthy Certificate Signing authorities, 
whose missions are clear and transparently, actually honest trust and 
integrity, rather than merely a shroud of apparent trust cloaking the true 
purpose of pure profit.

By installing the CACert.org root certificate in the most popular and 
successful open source alternatives to commercial browsers, the Mozilla 
Organization has an opportunity to provide an alternative to paid-for trust, to 
endorse grass-roots trusts networks, and to make a conscientious statement to 
it's users.  Such a very responsible reminder to the browsing public at large, 
that no SSL certificate should *ever* be trusted any more than the user trusts 
the *signer* of the certificate, I feel is needed sooner rather than later.  
More and more mass-market consumers have already come to depend on their 
internet access software to conduct their daily financial tasks via the 
internet, and thus to protect their sensitive personal communications from 
whatever technical threats may exist to the privacy and security of their 
internet use.  They look to Mozilla to set the standards, to provide and to 
recommend the best practices that are in the best interest of the user, as 
opposed to those of the organization developing the software.  Even non-
technical users already understand that open source projects like Mozilla 
define quality.  Therefore I believe Mozilla owes it to users to advise and 
educate them to any alternatives that exist to placing their privacy in the 
hands of any one organization, 

To the extent that commercial software companies ship their products configured 
to only trust the services of commercial "Trust Providers", users are led to 
assume that true security, truly reliable encryption, and true identity are 
technically only *possible* using the commercial software and service providers 
involved.  Such assumptions are disproven by the mere fact that users are using 
Mozilla!  

They (in our opinion, rightly) trust Open Source software more than 
commercially developed software, and The Mozilla Organization owes it to it's 
users to lead the way by demonstrating that their Open Source software does not 
equate true security, reliable encryption, and trust itself, with the purchase 
of a signature from one of the "trust provider" corporations whose sole 
purposes for existence begin and end with increasing shareholder value.  

Organizations that exist for the one purpose of profit do not have any interest 
in providing technically sound encryption software, or trustworthy certificate 
signing services, beyond that which is profitable to them, which means that it 
*is* in their financial interest to discourage, discredit and foster fear 
uncertainty and doubt upon any non-commercial organization such as CACert.org 
whose expressly stated mission *is* solely to provide technically sound and 
truly trustworthy certificate signing service to everyone, even to those (I 
dare say, especially to those) who cannot afford to, or will not choose to 
purchase trust from them.  

Individuals, entrepreneurs, small businesses, unincorporated nonprofit 
organizations are all perfect examples of entities who just as likely to 
*need*, and to many, *more* likely to deserve, but yet far less likely to be 
able to afford, say, a wildcard certificate from a trusted certificate signing 
authority to secure the membership, donations or payment pages of their web 
sites.  

Is it right that, just because a person or group is unable or unwilling to pay 
an annual fee to a certain corporation, visitors to their web sites, the sites 
of these less-profitable entities, are made to feel less trusting, or outright 
suspicious of the integrity of their security systems, because they could 
afford "true trust" of a Verisign certificate, even though they use very same 
open source Apache, Mozilla, OpenSSL and other free software systems that 
Amazon relies on for security?

Like the phenomenon of open source itself, the concept of non-profit CA's (or 
Open Certificate Authorities) has an obvious spirit of fairness, an intuitive 
sense of correctness, the potential to provide a *far* higher quality service 
to far more of the public and the world's population in general, and at far 
lower cost than existing commercial alternatives, and therefore the power to 
severely disrupt existing commercial industries.  

So what, then, is The Mozilla Organization waiting for?

-dave

-- 
David Kaufman <david@power-data.com>

www.Gigawatt.com / Power Data Development \ www.ClickSQL.com
         Hosting         Scriptage          Databasics

www.Power-Data.com
87 East 21st Street, Bayonne, NJ  07002
(201) 436-0668

Flags: blocking1.6?
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 certificates@mozilla.org 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. 
Flags: blocking1.6? → blocking1.6-
For comment #14:
certificates@mozilla.org bounces

Michael Helm (helm@es.net)
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 certificates@mozilla.org 

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.
Flags: blocking1.7a?
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, as
opposed to putting all of our effort into the initial selection process for CAs,
is it possible to divide efforts between an initial selection process and a
post-selection process for dealing with CA-related problems? Such an approach
would seem to be more in keeping with the way the Mozilla project works in other
areas. (And from a selfish point of view it wouldn't put all the burden on me or
whomever else does the initial selection.)

Anyway, some thoughts for now. Rather than continuing in this vein, I'll go back
to trying to get a draft policy finished and out for comment. And if this debate
over CAcert acts as a forcing function to get me to do that, that's a good thing :-)
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 **** 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/ 
 
going to have to finalize this in 1.7b  
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
Just would like this included.
looks like this is going to have to wait for 1.7 final or 1.8.  out of time for 1.7b
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
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.
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.
(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?
(In reply to comment #46)

Wouldn't it be better that once a decision has been made that you contact
support@cacert.org and ask for the "current" root cert(s)?
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.
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.  
(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").





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 :(
Assignee: wchang0222 → hecker
Component: Libraries → CA Certificates
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
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.
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
Assignee: hecker → hecker
Flags: blocking1.7?
Any luck with this? We are all waiting for the CACert to be included in mozilla.
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.
I'd like to see CACert root certificates in Mozilla (and all derivatives) as well.
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.
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.
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!
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.
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!
(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.

(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.
> 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
*** Bug 252093 has been marked as a duplicate of this bug. ***
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:119/41134493.8050702@adambutler.net
and, on the positive side:
news://news.gmane.org:119/41144540.6010301@cacert.org

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.
(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.
(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?
A reaading of the postings for the last few months in
news://news.gmane.org:119/gmane.comp.security.cacert 
suggests otherwise, IMO.
Please could you post specifics relating to that comment, as I have read back to
11th August and see little cause for concern.




Cacert is better than the other 24 companies that have their root certificates
already included in mozilla.
(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".
(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.
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. 
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.  
(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
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.
(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.
(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.
(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.
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.  
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 effect is that
the user must go through just as much effort, if not more.  And the overall
complexity of the software increases, with no net benefit.


6) So the question is....  Shall big buck unscrupulous corporate monopolies
(Verisign) be allowed to control and dominate the security of the internet.  Or
shall we embrace a viable and open alternative?

7) Now I can certainly appreciate the very legitimate concern that you do not
want to open the floodgates to an anything goes environment.  But as has been
ably pointed out elsewhere in this discussion, it is also not fair to hold
newcomers to a higher standard of entry then what the established companies have
had to meet.  And it is not fair to impose financially burdensome procedures
onto applicants.  The financial burden does nothing to ensure the integerity of
the applicant, all it does is to raise the bar so high as to ensure the
continuation of the monopoly.  And that only companies with deep pockets and
strong profit motives shall ever succeed in getting approved.


If that was the kind of world you wanted to live in, then you would have never
written the superb FireFox.

By all appearances the CACert endeavour is a legitimate and very worthwhile
solution.  It saddens me to see how much foot dragging has occurred.  Surely in
the year and a half that this bug has been active, people could have reached
level of agreement?  A great opportunity was lost when the CACert failed to ship
with the 1.0 release.  Perhaps it can be added to the auto-updater?


Well, that's my 3 cents worth.  It's not my intention to be insulting, but as an
outsider giving an objective view of this situation, I feel a lot of frustration
with the way in which it was handled.  And I believe that Duane is deserving of
a lot of credit for his restraint and enduring patient persistance.  This alone
speaks quite well of his endeavour.  And if you think that the little tiff, that
occurred with their board meeting is a basis for disqualifying them.  Then allow
me to ask what is you basis of comparision? What is your frame of reference? 
Have you ever been privy to the board meeting of Verisign?  Why do you think
that they are free of polotical maneuvering and clashes of opinion?  Most
assuredly they are not.  You want transparency?  Verisign won't even tell you
what they are up to; but for better or worse CACert has the courage to show you
every wart.


Again, I say, it is not my intention to be insulting. MF has made a fantastic
contribution to the world, and people have worked very hard to do it.  But it is
my hope that this somewhat acerbic commentary will light a F I R E  and get this
thang moving forward.  It's long overdue...
 
Ciao,
-- Erik
(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).
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.) 
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).  
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.
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)?
This should be good news to you guys: 

http://www.hecker.org/mozilla/cert-policy-draft-9
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.
No longer blocks: majorbugs
*** Bug 301719 has been marked as a duplicate of this bug. ***
*** Bug 304308 has been marked as a duplicate of this bug. ***
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)
(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;)
*** Bug 306851 has been marked as a duplicate of this bug. ***
*** Bug 307079 has been marked as a duplicate of this bug. ***
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:119/41134493.8050702@adambutler.net
> and, on the positive side:
> news://news.gmane.org:119/41144540.6010301@cacert.org
> 
> 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.
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.
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.
(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?
(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.
Restarted this discussion on the new mozilla.dev.tech.crypto newsgroup.
(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.
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.  
(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.
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*
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?
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.
Thawte and Comodo are both free.
(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...

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

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.
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.  
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.
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?
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.
(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
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.
(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.
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.  
> 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.
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.
> 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...
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...
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.
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.
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
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!
(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.)
Status: NEW → ASSIGNED
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.
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.
(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).
(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.
any word on progress here?  closing this bug would make an awful lot of people happy.
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.
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.

Stop commenting on this bug.
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.
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!
(In reply to comment #140)
Please open a separate bug about that.
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.
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.  
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...

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.  
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)
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.
"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.
(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.
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
(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).
(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.
QA Contact: bishakhabanerjee → ca-certificates
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.
Priority: -- → P3
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
Status: ASSIGNED → NEW
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
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 <rich@thefreemanclan.net> 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 position.  

I had though a free CA would be a good thing, and if one is good, then two is better, and hundred would be fantastic!  So if they all *do* pop up, and share code and development effort, I believe that all will benefit and perhaps, someday, all will be accepted by all the browsers, and Verisign and the small number of others who dominate and control the Industry of Trust will no longer be able to levy their "security tax" on every ecommerce transaction on the internet.  SSL and WiFi encryption are made possible by open source software and public key encryption which came from the grass-roots volunteer development efforts of developers who believed the decision of who to trust belongs with the user, not the government and certainly not, uh large multinational corporations.

So I still believe that CaCert's root certificate should ship with Mozilla, because I belive that users, given the choice, users would choose to trust the network of well-intentioned volunteers that make up CaCert over Verisign and GE any day.  And if The Mozilla Foundation does not institute SOME policy by which a grassroots volunteer CA such as CaCert can be considered as trustworthy as a fly-by-night company whose only purpose is to make a buck by investing $50,000 to get in on a piece of Trust Tax, then Mozilla is sending the message to its users, to the public, that only companies and governements ought to have the keys to the public's trust.

-dave

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." --Howard Aitken <http://en.wikipedia.org/wiki/Howard_Aiken>
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. 
Status: RESOLVED → VERIFIED
you must include cacert = ikerc
(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.
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!
Restrict Comments: true
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.