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.
Regards,
Frank Schwab
TLC GmbH