ietf-smime
[Top] [All Lists]

RE: How to recognize an S/MIME message?

2001-07-03 13:58:38

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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Blake 
Ramsdell
Sent: Tuesday, June 19, 2001 12:14 PM
To: 'Frank(_dot_)Schwab(_at_)tlc(_dot_)de'; 'ietf-smime(_at_)imc(_dot_)org'
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: 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





<Prev in Thread] Current Thread [Next in Thread>
  • RE: How to recognize an S/MIME message?, Jim Schaad <=