Missing policy for CA certificates

Perhaps the mozilla ca certificate policy, reviewed and developed by the Mozilla community for over a year, would be a good starting point for Ubuntu:

http://www.mozilla.org/projects/security/certs/policy/

Though 9 months late, I'd like to express the same concern in this bug report. While there's a nice disclaimer in the package description (from Debian), users are ignorant of the security ramifications of inclusion.

I too suggest there should be a secure, objective inclusion critera. Continuing to include untrustable certificate authorities puts the security of communications at significant risk.

At the very least, can we have a stronger disclaimer, which properly informs the users of the risks of installing this package on their system? Something like:

"As the trustworthiness of the included CAs has not been established, the installation of this package on your system could result in a compromise in SSL/TLS secure communications. Install this package at your own risk."

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Yes, this is still an issue.

Thanks for the information.

Actually I intend to move to only having a selected set of CAs enabled by default. (I.e. Mozilla's and maybe some of Debian's because we want our users to be able to surf onto our SSL-protected sites. I can understand if you dislike the latter but we could also look for an Ubuntu-only change on this. And I want to ask debian-devel at some point about their opinion.) I target this for Karmic+1, though.

Philipp, this didn't make it into Lucid, did it?

https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

The recent incident with the UTN-USERFirst-Hardware certificates as reported in Bug #741729 shows again how important it is that this is getting addressed.
Comodo got to know about the problem on March 15th , Google blocked the fraudulent signatures on 16th, Mozilla and Microsoft followed. However to my knowledge, all Linux distributions, certainly those that use the debian ca-certificate still trust these certificates.
Any damage most likely already has been done. Even the next day response from Google likely had come to late and there certainly was a window of a few days between issuing the certs and Comodo being aware of the intrusion.

It's not the first time UTN-USERFirst-Hardware came up...
http://it.slashdot.org/story/08/12/23/0046258/Perfect-MITM-Attacks-With-No-Check-SSL-Certs

Now Mozill, Google and MS blacklisted the known compromised certificates. All other certificates they signed are still trusted. Any bets and guesses when the next incident involving a comodo reseller will occur?

to Paul C. Bryan, #2:
>At the very least, can we have a stronger disclaimer, which properly informs the users of the risks of installing this package on their system?

It's preinstalled on a default desktop installation of Ubuntu.
I'm not sure what the best course of action should be. I think it's clear the mentioned fraud certs should be blacklisted asap (I mean Microsoft beat you to it...). Apart from that maybe we should think about disabling these known "problematic" CAs.
I'd suggest still shipping them in the package but disabled by default so the user can make a conscious decision about trusting them or not.

Pending upload, README.Debian now includes the following in the collab-maint git repository:

How certificates will be accepted into the ca-certificates package
------------------------------------------------------------------

 - Get it included into Mozilla's trust store.
 - File a bug against ca-certificates stating this fact.

With the exception of SPI (http://www.spi-inc.org/) and CAcert
(http://www.cacert.org/), only those CAs included in the Mozilla trust
store will be included in the ca-certificates package in Debian.

--
Kind regards,
Michael Shuler

This bug was fixed in the package ca-certificates - 20130906

---------------
ca-certificates (20130906) unstable; urgency=low

  * Add ca-certificates-local source package example to documentation
  * Update local certificate handling in README.Debian.
    Closes: #718173, LP: #487845
  * Update CA inclusion policy for ca-certificates in README.Debian. With
    the exception of SPI and CAcert, only those CAs included in Mozilla's
    trust store will be included in ca-certificates in Debian.
    Closes: #647848, LP: #103074
  * Clarify that not all software that uses SSL uses ca-certificates in
    README.Debian. Closes: #664769
  * Add mozilla/nssckbi.h to source, since certdata.txt no longer contains
    a version number.
  * Update debian/copyright to "Copyright: Mozilla Contributors" for
    mozilla/{certdata.txt,nssckbi.h}.
  * Update mozilla/certdata.txt to version 1.94
    Certificates added (+) and removed (-):
    + "CA Disig Root R1"
    + "CA Disig Root R2"
    + "China Internet Network Information Center EV Certificates Root"
    + "D-TRUST Root Class 3 CA 2 2009"
    + "D-TRUST Root Class 3 CA 2 EV 2009"
    + "PSCProcert"
    + "Swisscom Root CA 2"
    + "Swisscom Root EV CA 2"
    + "TURKTRUST Certificate Services Provider Root 2007"
    - "Equifax Secure eBusiness CA 2"
    - "TC TrustCenter Universal CA III"

 -- Michael Shuler <email address hidden> Fri, 06 Sep 2013 11:31:06 -0500