363305 - Generic method of introducing new root CA's

Status: RESOLVED WONTFIX

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

Description

[cmroanirgo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

This is a copy of a comment added to bug#215243 (CACert root inclusion), although this is a generalised/alternate solution to the problem listed there.

It is apparent that root CA's will not be accepted into the general public (ie those who do not understand what a root cert is) until that root cert is included within a product. 

Other faults have clearly stated the following issues that arise in adding new roots. 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) are 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. 

Note that existing root CA's could still be shipped with each product, thereby reducing the need to download root CA's for well-known established CA's (eg. Verisign, Thawte, etc), although technically, these CA's should probably be subject to the above system.


Reproducible: Always

Steps to Reproduce:
This is new functionality.


Expected Results:  
The user should be able to see what the community as a whole thinks about a particular site cert/root cert, enabling the user to be better informed as to whether to proceed to a site or not.
A user should be able to vote (thumbs up/down) on the site if they wish.

Comment 1

[cmroanirgo]

From the business perspective, mozilla could also allow (perhaps at a cost), access to the results of the user voting system to registered root CA's, allowing those root CA's to update their revocation lists in a more timely manner.

Comment 2

[desrt]

any design for a solution to this bug should consider the rather serious privacy issues involved in the browser calling home with information about every secure site it is attempting to access...

also: the bandwidth and database server power required to handle such calls home...

Comment 3

[Frank Hecker]

(In reply to comment #2)
> any design for a solution to this bug should consider the rather serious
> privacy issues involved in the browser calling home with information about
> every secure site it is attempting to access...

I have no opinion at this time on the general merits of the proposal, but I will note that the proposal is apparently to query a central point only in cases where the browser encounters a certificate from a CA previously not known to it. Also, I presume the query would not need to expose the domain name for the web site itself, but only the name of the root CA for which a root CA certificate is desired.

By the way, this bug shouldn't be assigned to me, since I have no power to either implement it or command that it be implemented. I'll reassign it to someone else once I figure out who'd be best to handle it (likely someone on the NSS team).

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Frank, such an enhancement would definitely NOT be an NSS feature, but 
rather a PSM feature.  

The feature seems only to be a new distribution channel for root CA certs
that have been approved according to our policy.  I'm not aware that there
is any particular problem with the existing distribution channels.  

Comment 5

[David E. Ross]

When a root certificate is approved for inclusion in Mozilla products (as noted in the bug report requesting such inclusion), I go to <http://www.hecker.org/mozilla/ca-certificate-list/>, download the certificate, and import it.  That way, I don't wait until the next product release for "good" root certificates.  

For root certificates that are not yet approved because their CAs have not yet undergone the audit required by the Mozilla policy, this RFE should include a way for the user to waive any ability to sue the Mozilla Foundation or Mozilla Corporation for damages when the use of a proposed certificate results in a financial or other loss.  That feature should require users to identify themselves in a manner that can be authenticated so that, if a lawsuit is launched, the Mozilla organizations can defend themselves.  This feature is quite reasonable if users are insisting that Mozilla provide them with root certificates of unknown trustworthiness rather than installing those certificates themselves.  

Comment 6

[Martin von Gagern]

(In reply to comment #5)
> When a root certificate is approved for inclusion in Mozilla products
> (as noted in the bug report requesting such inclusion), I go to
> <http://www.hecker.org/mozilla/ca-certificate-list/>, download the
> certificate, and import it.

This is a viable solution for you as a sophisticated user. But on the other hand, you are capable of installing a certificate in the first place.
The main problem addressed by all this inclusion discussion is the large public that doesn't know about hot to install root certificates in the first place and thus is unlikely to update their list.

> That feature should require users to identify
> themselves in a manner that can be authenticated so that, if a lawsuit is
> launched, the Mozilla organizations can defend themselves.

Why would you need this identification? Any lawsuit would mention the root certificate in question. If this certificate is on some list of highly trusted certificates (i.e. the ones shipped with mozilla products or ones marked in a CA distribution sheme like the one suggested here with a trust level higher than any achievable through a community process) then Mozilla checked it, otherwise you know the user either installed it himself or used the suggested community based exchange, including the waiver you suggested. Which of these methods he actually used does not matter, as long as you know he assumed responsibility.

I see no need to identify him before he files a lawsuit.

Comment 7

[Gervase Markham [:gerv]]

Whatever you may think about it, the current model is that the Mozilla project approves CAs based on our policy, which leverages objective audit criteria.
http://www.mozilla.org/projects/security/pki/nss/ca-certificates/policy.html

I see no call for expending serious amounts of engineering resource to set up a robust system to allow end-users access to a complex process where they can, if they click the wrong buttons, shoot themselves in the foot.

There are two states for a CA: approved and not. To paraphrase Yoda: "Is, or is not. There is no 'sort of'."

Gerv