184649 - RFE: Intercept and handle application/pkix-cert MIME type

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, enhancement, P5)

Description

[Ralf Hauser]

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.

Comment 1

[Ralf Hauser]

the corresponding apache suggestion is at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15235

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 3

[Ralf Hauser]

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?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 5

[John Unruh]

*** Bug 186236 has been marked as a duplicate of this bug. ***

Comment 6

[bjoern]

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.

Comment 7

[bjoern]

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.

Comment 8

[Kai Engert (:KaiE:)]

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.

Comment 9

[John G. Myers]

Mass reassign ssaux bugs to nobody