[Top] [All Lists]

RE: How to recognize an S/MIME message?

2001-06-19 12:14:05

Perhaps this can be clarified with an example in the new RFC2633:

1. If the Content-Type is application/pkcs7-mime, then the content should be
interpreted as a CMS object as specified in section 3.2

2. If the Content-Type is application/octet-stream, and the file extension
is P7M, then the content ahould be interpreted as a CMS object as specified
in section 3.2

3. If the Content-Type is application/pkcs7-signature then the content
should be interpreted per sction

4. If the Content-Type is application/octet-stream, and the file extension
is P7S, then the content should be interpreted per section

Personally, I think that Outlook is out-of-spec, but I can see how section
3.8 could be misunderstood.


-----Original Message-----
From: Frank(_dot_)Schwab(_at_)tlc(_dot_)de 
Sent: Tuesday, June 19, 2001 4:14 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: How to recognize an S/MIME message?

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

   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
S/MIME messages when they use the correct MIME types. However, section 3.8
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
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
the standard on this topic.


   Frank Schwab
   TLC GmbH

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