[Top] [All Lists]

How to recognize an S/MIME message?

2001-06-19 03:17:10

My company is currently evaluating PKI and S/MIME components and we came across
an apparent contradiction in the S/MIME v2 and v3 RFCs (RFC2311 and RFC2633).

   Both documents have the following words in section 3.2.1:

   Including a file name serves two purposes. It facilitates easier use
   of S/MIME objects as files on disk. It also can convey type
   information across gateways. When a MIME entity of type
   application/pkcs7-mime (for example) arrives at a gateway that has no
   special knowledge of S/MIME, it will default the entity's MIME type
   to application/octet-stream and treat it as a generic attachment,
   thus losing the type information. However, the suggested filename for
   an attachment is often carried across a gateway. This often allows
   the receiving systems to determine the appropriate application to
   hand the attachment off to, in this case a stand-alone S/MIME
   processing application. Note that this mechanism is provided as a
   convenience for implementations in certain environments. A proper
   S/MIME implementation MUST use the MIME types and MUST NOT rely on
   the file extensions.

   This clearly states that an S/MIME-capable E-Mail client must only recognize
S/MIME messages when they use the correct MIME types. However, section 3.8 of
both documents seem to contradict section 3.2.1:

3.8 Identifying an S/MIME Message

   Because S/MIME takes into account interoperation in non-MIME
   environments, several different mechanisms are employed to carry the
   type information, and it becomes a bit difficult to identify S/MIME
   messages. The following table lists criteria for determining whether
   or not a message is an S/MIME message. A message is considered an
   S/MIME message if it matches any below.

   The file suffix in the table below comes from the "name" parameter in
   the content-type header, or the "filename" parameter on the content-
   disposition header. These parameters that give the file suffix are
   not listed below as part of the parameter section.

   MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any

   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any

   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c

   This clearly states that a MIME type application/octet-stream with a file
suffix of e.g. p7m is a valid S/MIME message.

   It seems that not only we but also the vendors are confused by this apparent
contradiction. Microsoft's Outlook adheres to section 3.2.1 and does not
recognize S/MIME messages with MIME type application/octet-stream and file
suffix p7m while Netscape's Messenger does.

   Can anybody shed some light on this? Maybe it would be a good idea to clarify
the standard on this topic.


   Frank Schwab
   TLC GmbH

<Prev in Thread] Current Thread [Next in Thread>