Subject: RE: How to recognize an S/MIME message?

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2001 13:58:31 -0700

I would agree that Outlook is out of spec.  It is forced on the product by
the Exchange server as previously stated.

I don't agree that this can be clarifed by an example.  However, I do think
that language should be included that applications MUST NOT generate the
octet-stream version of a message.  This is strictly left for "unfriendly"
gateways.

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Blake Ramsdell
> Sent: Tuesday, June 19, 2001 12:14 PM
> To: [email-masked]'; [email-masked]'
> Subject: RE: How to recognize an S/MIME message?
>
>
>
> 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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 4:14 AM
> To: [email-masked]
> 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
>
>
>