Enhanced Security Services for S/MIME
RFC 2634

Document Type RFC - Proposed Standard (June 1999; No errata)
Updated by RFC 5035
Author Paul Hoffman 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2634 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                P. Hoffman, Editor
Request for Comments: 2634                     Internet Mail Consortium
Category: Standards Track                                     June 1999

                 Enhanced Security Services for S/MIME

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Introduction

   This document describes four optional security service extensions for
   S/MIME. The services are:

    - signed receipts
    - security labels
    - secure mailing lists
    - signing certificates

   The first three of these services provide functionality that is
   similar to the Message Security Protocol [MSP4], but are useful in
   many other environments, particularly business and finance. Signing
   certificates are useful in any environment where certificates might
   be transmitted with signed messages.

   The services described here are extensions to S/MIME version 3 ([MSG]
   and [CERT]), and some of them can also be added to S/MIME version 2
   [SMIME2]. The extensions described here will not cause an S/MIME
   version 3 recipient to be unable to read messages from an S/MIME
   version 2 sender. However, some of the extensions will cause messages
   created by an S/MIME version 3 sender to be unreadable by an S/MIME
   version 2 recipient.

   This document describes both the procedures and the attributes needed
   for the four services. Note that some of the attributes described in
   this document are quite useful in other contexts and should be
   considered when extending S/MIME or other CMS applications.

Hoffman                     Standards Track                     [Page 1]
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",
   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

   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

Hoffman                     Standards Track                     [Page 2]
RFC 2634         Enhanced Security Services for S/MIME         June 1999

1.1.2 Steps for Triple Wrapping

   The steps to create a triple wrapped message are:

   1. Start with a message body, called the "original content".

   2. Encapsulate the original content with the appropriate MIME
      Content-type headers, such as "Content-type: text/plain". An
      exception to this MIME encapsulation rule is that a signed receipt
      is not put in MIME headers.

   3. Sign the result of step 2 (the inner MIME headers and the original
      content). The SignedData encapContentInfo eContentType object
      identifier MUST be id-data. If the structure you create in step 4
Show full document text