RFC 2634 (rfc2634) - Page 2 of 58


Enhanced Security Services for S/MIME



Alternative Format: Original Text Document



RFC 2634         Enhanced Security Services for S/MIME         June 1999


   The format of the messages are described in ASN.1:1988 [ASN1-1988].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD].

1.1 Triple Wrapping

   Some of the features of each service use the concept of a "triple
   wrapped" message. A triple wrapped message is one that has been
   signed, then encrypted, then signed again. The signers of the inner
   and outer signatures may be different entities or the same entity.
   Note that the S/MIME specification does not limit the number of
   nested encapsulations, so there may be more than three wrappings.

1.1.1 Purpose of Triple Wrapping

   Not all messages need to be triple wrapped. Triple wrapping is used
   when a message must be signed, then encrypted, and then have signed
   attributes bound to the encrypted body. Outer attributes may be added
   or removed by the message originator or intermediate agents, and may
   be signed by intermediate agents or the final recipient.

   The inside signature is used for content integrity, non-repudiation
   with proof of origin, and binding attributes (such as a security
   label) to the original content. These attributes go from the
   originator to the recipient, regardless of the number of intermediate
   entities such as mail list agents that process the message. The
   signed attributes can be used for access control to the inner body.
   Requests for signed receipts by the originator are carried in the
   inside signature as well.

   The encrypted body provides confidentiality, including
   confidentiality of the attributes that are carried in the inside
   signature.

   The outside signature provides authentication and integrity for
   information that is processed hop-by-hop, where each hop is an
   intermediate entity such as a mail list agent. The outer signature
   binds attributes (such as a security label) to the encrypted body.
   These attributes can be used for access control and routing
   decisions.









Hoffman                     Standards Track