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 3.4.3.1
4. If the Content-Type is application/octet-stream, and the file extension
is P7S, then the content should be interpreted per section 3.4.3.1
Personally, I think that Outlook is out-of-spec, but I can see how section
3.8 could be misunderstood.
Blake
-----Original Message-----
From: Frank(_dot_)Schwab(_at_)tlc(_dot_)de
[mailto: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
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