As reported in http://bugzilla.mozilla.org/show_bug.cgi?id=184052, the certificate MIME type used by those who only use one (MSIE, ...) is defaulted to a certification authority type cert. Suggestions: 1) Default application/pkix-cert to x-x509-email-cert because as Mozilla is intended for the masses, the most frequent key type users will click on short- and mid-term are e-mail certificates (see rationale below) 2) Before doing anything on the default, provide the user the choice to switch the treatment to what should be done with CA certificates or the users' own certificates alternatively. I will post a complementary suggestion to apache2 since they by default only activate x-x509-ca-cert, but not x-x509-email-cert nor x-x509-user-cert. Rationale for my above suggestions: The authors of PKI concepts appear to have believed that large institutions such as postal services, goverments' passport issuing authorities, or large corporations such as banks would issue billions end-user certificates. This unfortunately hasn't happened and pgp is probably still the largest publicly usable key base (with http://pgpkeys.mit.edu:11371 as their hub server). Professionally run directories for x509 certificates do not exist. Therefore, it is more likely in the future that users will put their own (free-mail or self-signed) certificates on their personal homepages. While at the times of Netscape-Mozilla/4.7, it may have been reasonable to silently map pkix-cert to x-x509-ca-cert and basically put the burden of which certificate is fit for which use (ca, email, user as in http://wp.netscape.com/eng/security/comm4-cert-download.html#communicator) on the publishing web-master, I contend that this is no longer appropriate today. If privacy is for desirable for the masses, we no longer can wait until large institutions have sorted out liability issues and created robust enough processes to manage large certification activities and public key directories. On the other hand, I think most users will not be able to instruct their webmasters to enable multiple MIME-TYPES for this, therefore having 3 types active may not be realistic.
the corresponding apache suggestion is at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15235
Severity: normal → enhancement
OS: Windows 2000 → All
Priority: -- → P5
Hardware: PC → All
Version: unspecified → 2.4
I have several thoughts on this subject. 1. Netscape Navigator/Communicator 3.x and 4.x do not, and never have, mapped application/pkix-cert to any of the mime types documented in http://wp.netscape.com/eng/security/comm4-cert-download.html#communicator . Consequently, when a Windows C4.x user visits a page of type application/pkix-cert, C4.x looks that mime type up in the registry and finds that windows maps it to Microsoft's cert manager, and so C4.x runs Microsoft's cert manager instead of its own built-in cert manager. The result is that the cert is downloaded into Windows' cert store, not into C4.x's cert store. 2. I believe that some versions of mozilla/N7 also behave that same way. If mozilla/N7 is now mapping application/pkix-cert to application/x-x509-email-cert, as you claim, I think that is a fairly recent behavior change. 3. If moz/N7 is going to intercept application/pkix-cert, the only reasonable way to handle it, IMO, is to give the user a GUI dialog, asking the user to tell us whether this cert is a CA cert, another user's email cert, the user's own cert, etc. One might argue that mozilla should be able to tell by inspection of the cert whether it is a leaf cert, a CA cert, or a root-CA cert. That would be true if all certs were properly constructed. But a large percentage of certs issued by people pretending to be CAs are improperly constructed. 4. Arguments that say, in essence, "mozilla should behave this way so that my self-issued cert will work the way I want it to" are not compelling, especially for https servers. 4a. A large percentage of self-issued certs (not from competent CAs) are improperly constructed. It is exceedingly common for home-grown CAs to issue multiple certs with the same issuer and serial number, or to issue both CA and non-CA certs with the same subject name, or to include both issuer's subject key ID _and_ issuer's issuer-name-and-serial-number in authority key ID extensions. These certs cause real problems for software that implements real security policies, and should not be encouraged. 4b. For email, there are free email cert CAs, and there is no good reason to use a self-signed email cert or an email cert issued by one's own play CA rather than a real cert from a real CA, given that real CA email certs are available for free. 4c. Netscape/mozilla browsers offer https for security, not for mere encryption interoperability. When a user accepts and trusts a cert that did not come from a real CA, the user may achieve interoperability with some https site (or some email user) using encryption, but the user loses all the assurances of the identity of his peer, and all protection against Man-In-The-Middle attacks. The user gets encryption interoperability, but loses real security. The user may have the impression that he has security, but it is a false sense of security. 5. I think this bug may be a duplicate of another PSM RFE (request for enhancement), but I don't know the number off-hand.
Thanks for the information, I guess your 1 and 2 explain http://bugzilla.mozilla.org/show_bug.cgi?id=184052#c6. Re 3: Do you say that is not possible to make an inspection algorithm resistant against "garbage in"? Re 4a: Could you elaborate on how "these certs cause real problems for software that implements real security policies, and should not be encouraged." Which are those problems? Or my question is probably: how can one expect a security infrastructure to fly if it is not able to sort out its own black sheep? Re 4b: As you may have noticed I went through the free email certificate process. It took me about 3 face-to-face meetings to get enough points just to have my name on my certificate, 6 paper copies of passports and alike, and one of the notaries would only do it for USD 20. Conclusion: Only a small fraction of a percent of worldwide e-mail users will ever do that unless they are forced to. Also, those CA's are implemented in a way that I am sure that the number of novices who will not suffer until the end and abandon this process is in the high 90ies percentiles. If we want private messaging for the masses short and mid-term, I guess there is no way other than a key management infrastructure evolution path that starts somewhere close to PGP's web-of-trust self-responsible key management. After all, the big advantage of a security implementation like the one in Mozilla/Netscape or MSIE/Outlook is that the software is already on the users' desktops and does not need an extra download and installation that may violate a corporate policy and cost $$ in license fees. Re 4c: I do agree that in today's implementation a naive user too easily accepts and trusts a cert that did not come from a real CA. I guess there should be two RFEs for such certificates: i) unbypassable warnings instructing the user to use some kind of out-of-band fingerprint verification (with multiple links instructing how to do that) and that it is the user's sole judgement to assess and decide whether the certificate is any good. ii) The Certificate Manager should clearly visualize in "Authorities", but also for "Web Sites", etc. which certificates are tied to good CAs (I guess as per http://webtrust.org/ originally shipped with the browser) and which are not. Agreed, just labeling some as "Builtin Object Token" as opposed to "Software Security Device" certainly won't do it. There probably needs to be colour coding, some icon visualizing the two key management approaches and links and help pages further elaborating on the differences of these key management approaches and pointing out transition paths from "web-of-trust" to "hierarchical". This is probably tied to the usability problem you mention in http://bugzilla.mozilla.org/show_bug.cgi?id=184659#c4. Perhaps even 4 MIME-Types are not enough, probably there is a set of types needed for the services of the professional CAs (guiding me blindly - although, even in the many big-name firms I worked at, I never saw one like that really functional) and a second set that puts the end-user more in charge. What do you think?
In bug 184052 it has come to light that mozilla is NOT intercepting and/or interpreting the MIME type application/pkix-cert at all. In light of that, I think _this_ bug report is asking mozilla to _start_ intercepting and interpreting that MIME type, as if it were application/x-x509-email cert. So, I'm changing the Summary of this bug report to reflect that. I concur that mozilla should intercept the MIME type application/pkix-cert. The only issue is what to do with it. I would like to continue to discussion that we started above. It's been better than most such discussions. But I don't think this bug report is the place to do it. So, I propose that we move this discussion to the netscape newsgroup news://news.mozilla.org/netscape.public.mozilla.crypto which is also accessible via a mailing list server. See http://www.mozilla.org/community.html#mozilla-crypto for more info. If you're amenable, please post a message about this topic in that list. Thanks.
Summary: Default application/pkix-cert to x-x509-email-cert instead of x-x509-ca-cert → RFE: Intercept and handle application/pkix-cert MIME type
*** Bug 186236 has been marked as a duplicate of this bug. ***
Bug 186236 is not exactly a duplicate of this bug. Please read the bugreport. I noted, that a submitbutton, which gives back a netscape-like cert mime type makes mozilla download the cert instead of importing it. As an additional note I added that mozilla should support the IANA assigned mime type for certificates, not just the netscape invented mime types. Just this additional note dups this bug.
shouldn't Mozilla in the first line implement standards? x509-* were mime types invented by Netscape, maybe because at that point IANA did not yet assign mime types to certs. Please take a look at http://www.isi.edu/in-notes/iana/assignments/media-types/application/ an the pkcs* and pkix* mime types they asigned to different kinds of x509 certs. Please implement the IANA mime types in first place. I think you missed this point in your discussion about all this, the IANA standards.
This bug and bug 150978 seem to have similar content, when somebody is going to work on this topic, the knowledge in both bugs should be combined.
Depends on: 150978
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.