Frank(_dot_)Schwab(_at_)tlc(_dot_)de wrote:
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
-----
The S/MIME Message Specification RFC's (2311 and 2633) state that your should
try to be "liberal in what you receive and conservative in what you send". I've
always interpreted the above sections to mean that a sending agent should always
include the correct S/MIME header information (i.e. application/pkcs7-mime or
application/pkcs7-signature), and that as a minimum a receiving agent should
recognize these. In addition, a receiving agent may recognize the p7m, p7s and
p7c file extensions as indicating S/MIME, in case the message has passed through
an environment (e.g. X.400 or MAPI) in which the MIME content types are dropped
(though in such a case, validation of the clear signature in the p7s file would
probably fail). Some gateways keep a table of file extensions, and when they
convert a message to MIME, they assign the corresponding content type to any
attachments based on their extensions. Other gateways treat all attachments as
generic, i.e. application/octet-stream.
The main problem with relying on file extensions to determine the content
type is that there is no regulation on the use of extensions. Anyone can create
a file with a .p7m extension regardless of its content (e.g. to them p7m might
stand for Payments in the 7th Month or Parking level 7 Map). A receiving agent
can never be certain that such an attachment contains a PKCS#7 object until it
is processed, and to have a receiving agent constantly reporting errors while
processing attachments which were never meant to contain secure content would be
annoying. Fortunately there are currently no major software products that use
the p7m extension for anything other than S/MIME.
In short, if you want to guarantee that your receiving agent recognizes all
inbound S/MIME messages, have it use the file extensions. If you want to be
certain that every processed attachment contains a PKCS#7 object, go by the MIME
content types only.
As for Outlook and Netscape, the Outlook client is forced to rely on the
Exchange server to identify MIME content types, since all it recognizes is the
MAPI message format which does not preserve the MIME structure of a message.
How the Outlook client can verify an S/MIME clear signature is a mystery,
considering that it doesn't receive the signed content intact and the server
doesn't have the public key required to verify the signature (perhaps the
Exchange server appends the original MIME text to the MAPI message object for
such messages). Netscape, on the other hand, has the entire original MIME
message to work with. It seems to look up content types for generic attachments
with known extensions, and to process them accordingly. I've noticed that
Netscape is extremely liberal in what it receives, and can even process messages
from Outlook that contain the annoying and otherwise unreadable winmail.dat
attachment that often plagues the acquaintances of Outlook users. Not that I'm
partial to either one; I usually use Lotus Notes with an Entrust-Ready secure
messaging add-in.