150978 - mime type application/pkix-cert not recognized

Status: RESOLVED WONTFIX

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

Description

[dominique gregoire]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.0) Gecko/20020529
BuildID:    2002052918

Certificate of mime type "application/pkix-cert" not recognized in the browser
and the mail client. This mime type is recognized, and is the default for ".crt"
certificate file under Windows NT.
Under Linux, Mozilla recognize only the netscape's "application/c-x509-ca-cert"
mime type.

Reproducible: Always
Steps to Reproduce:
1.sent a ".crt" file with mozilla under WIn NT an receive in from Mozilla under
Linux.

2) Or get an "application/pkix-cert" certificate from a web site using Mozilla/Linux


Actual Results:  MOzilla doesn't handle the file.

Expected Results:  Handle "application.pkix-cert" as certicate.... as it is done
under Windows NT.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Reassigning.

Comment 3

[Stephane Saux]

kai

Comment 4

[Kai Engert (:KaiE:)]

Dominique, I believe you refer to downloading certificates from a website. It is
correct, we currently seem to handle:
  application/x-x509-ca-cert
  application/x-x509-server-cert
  application/x-x509-email-cert
  application/x-x509-user-cert

I'm not sure yet format is used for
  application/pkix-cert

Do you know a website where I can download a cert in that format for testing?


In addition, I'm not sure what you mean when you mention mail. I think you talk
about incoming mail that has certificates attached? What behaviour do you expect?

Please give some more details. Thanks!

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Windows' registry keeps a mapping of file name extensions to mime types.
The default registry entry for the .cer extension maps it to 
application/pkix-cert.  That registry entry also says that the way to 
handle .cer files (or files of MIME type application/pkix-cert) is to
feed them to a windows application (cryptext.dll) that puts them into 
Windows' cert store.

When sending a file as an attachment on a windows box, mozilla looks in
the registry to find the mime type to use to send that file.  So, when
sending a .cer file from a windows box, mozilla sends it with the mime 
type application/pkix-cert.  

But when mozilla receives a file with an attachment of that mime type, 
mozilla doesn't recognize application/pkix-cert as a mime type that it
should handle specially.  On Linux, mozilla treats it like a generic 
binary file, I think.  On windows, mozilla looks it up in the registry, 
sees that it should be handled by feeding it to cryptext.dll, and feeds 
it to that library.  Either way, the cert does not end up in NSS's cert DB.
On windows, the result is that it goes into Windows' cert store!

Mozilla needs to recognize application/pkix-cert and override the registry's
handling of that mime type, and feed the cert to NSS instead of to where
the windows' registry says.


The format used for application/pkix-cert is a subset of what we use for
the other cert mime types listed above.  So, the code that handles those
mime types can also handle application/pkix-cert.  

As noted above, today mozilla recognizes a set of mime types that tell it
a) that the thing being downloaded is a cert or cert chain, AND
b) how the cert is to be used, which implies what kind of trust should be
applied, and what kind of DB records should be generated for it.

There are different dialogs (IINM) for each type.  For example, when 
downloading a CA cert, you get asked a different set of questions than 
when you download a "user" cert, IINM.  

Also, NSS generates different database records depending on the mime type.
For example, NSS generates a "SMIME Profile" record for an email cert,
but not for a CA or server cert.  

Microsoft uses one MIME type for all certs.  That mime type makes no 
distinction between user, CA, server, and email certs.  Consequently,
for mozilla to download a cert of that mime type, mozilla would have to
have some additional way to find out whether it should treat the cert as
a CA cert, or as a user cert, or as a server cert, etc.  It might require
that mozilla have an additional dialog that reads something like this:

  You have started to download a cert.  Please indicate the type of cert
  you are downloading:
  [ ] A Certificate Authority certificate
  [ ] One of your own personal certificates
  [ ] A certificate for an SSL server
  [ ] A certificate for an S/MIME email correspondent.

Comment 6

[Kai Engert (:KaiE:)]

Thanks for your work on this, Nelson.

Unless we could have a way to automatically detect automatically the type of
certificate we are downloading, I agree we would have to add an additional user
interface.

Comment 7

[Kai Engert (:KaiE:)]

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

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I think we could look at the cert and make a pretty good guess, one that 
would be right most of the time.  We could use a heuristic like this:

- if it is X509v3 and has basic constraints that say it is a CA, or 
  if it is X509v1 and is self-issued (subject name == issuer name), or 
  if it is X509v2 and is self-issued and the two "unique identifiers" match
    - then it is a CA cert, treat like application/x-x509-ca-cert
  else
- if it is a "user" cert (we have the private key for it already), 
    - then treat it like appliation/x-x509-user-cert,
  else do both of the following two tests:
- if it has an email address attribute (in subject name) or an RFC822name
  (in subject alternate name) and EKU does not forbid it to be an email cert, 
  then treat it as application/x-x509-email-cert
- if it has a a subject common name that looks like a valid DNS name 
  (how do we tell that?) or it has a DNSname in the subject Alt Name, and
  the EKU does not forbid it to be used as an SSL server, then treat it 
  as a application/x-x509-server-cert

   

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

After I wrote comment 8, I read bug 184649 comment 2 (which really is a 
duplicate of this bug) and was reminded that many badly constructed certs,
made by people pretending to be CAs, will end up being categorized in some
way other than what the pretend-CA expected it to be.  This will lead to 
lots of bugs complaining that mozilla clients are broken because they didn't
categorize the cert the expected way.  

I think this might be a reasonable solution.  For certs issued by any of 
mozilla's trusted CAs, we can assume the cert was properly constucted, 
apply the above heuristic to it and be done.  For certs that do not chain 
to any trusted CAs, ask the user, as suggested in comment 5 above.