rhkelly wrote:
So this proposal would be that Mozilla would get away of imposing to all users a single built-in trusted CA, but instead distribute several trusted CA list, with a description of the origin of each list, how it is created, and let the users decide what is best for them.
This is clearly the way to do it.
In addition, the format of such list should be defined and documented, so that special-interest user communities can become their own "trust-list publishers".
That's a totally different proposition.
What's being discussed is the content of one or more built-in trusted certificates list.
Currently, the one built-in in list is contained in a PKCS#11 module that's compiled at the same time as NSS. This is a platform-specific file, and is not suitable for download or user installation.
It's already been pointed out that it's very difficult for the user to make rational trust decisions about a single root CA when connecting to a site, and making decision about lists of multiple root CAs at download time are even harder to make than for one.
Several formats already exist to distribute more than one certificate, such as PKCS#7. It would be up to Mozilla to bring up trust dialogs for each of the certs in the package. I don't know if it does that now, I have not tried creating a PKCS#7 of multiple root CA certs. But I think it would not be a good idea to have Mozilla trust all the certs in a package. Just giving this option is inviting security risks. Who is going to be able to really verify the entire list, if they don't even know how to trust one ?
Clearly the better model is to have the trust pre-installed in the client. That may mean using non mozilla.org-binaries in some applications (eg. government, corporate) with an alternate built-in root cert module, but it is much more secure than having the user install the trust manually afterwards.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
