tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2634

Proposed STD
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SMIME

Enhanced Security Services for S/MIME

Part 1 of 2, p. 1 to 26
None       Next RFC Part

Updated by:    5035


Top       Page 1 
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.

Top       Page 2 
   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.

Top       Page 3 
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
      is multipart/signed, then the SignedData encapContentInfo eContent
      MUST be absent. If the structure you create in step 4 is
      application/pkcs7-mime, then the SignedData encapContentInfo
      eContent MUST contain the result of step 2 above. The SignedData
      structure is encapsulated by a ContentInfo SEQUENCE with a
      contentType of id-signedData.

   4. Add an appropriate MIME construct to the signed message from step
      3 as defined in [MSG]. The resulting message is called the "inside
      signature".

    - If you are signing using multipart/signed, the MIME construct
      added consists of a Content-type of multipart/signed with
      parameters, the boundary, the result of step 2 above, the
      boundary, a Content-type of application/pkcs7-signature,
      optional MIME headers (such asContent-transfer-encoding and
      Content-disposition), and a body part that is the result of
      step 3 above.

    - If you are instead signing using application/pkcs7-mime, the MIME
      construct added consists of a Content-type of
      application/pkcs7-mime with parameters, optional MIME headers
      (such as Content-transfer-encoding and Content-disposition), and
      the result of step 3 above.

   5. Encrypt the result of step 4 as a single block, turning it into an
      application/pkcs7-mime object. The EnvelopedData
      encryptedContentInfo contentType MUST be id-data.
      The EnvelopedData structure is encapsulated by a ContentInfo
      SEQUENCE with a contentType of id-envelopedData. This is called
      the "encrypted body".

Top       Page 4 
   6. Add the appropriate MIME headers: a Content-type of
      application/pkcs7-mime with parameters, and optional MIME headers
      such as Content-transfer-encoding and Content-disposition.

   7. Using the same logic as in step 3 above, sign the result of step 6
      (the MIME headers and the encrypted body) as a single block

   8. Using the same logic as in step 4 above, add an appropriate MIME
      construct to the signed message from step 7. The resulting message
      is called the "outside signature", and is also the triple wrapped
      message.

1.2 Format of a Triple Wrapped Message

   A triple wrapped message has many layers of encapsulation. The
   structure differs based on the choice of format for the signed
   portions of the message. Because of the way that MIME encapsulates
   data, the layers do not appear in order, and the notion of "layers"
   becomes vague.

   There is no need to use the multipart/signed format in an inner
   signature because it is known that the recipient is able to process
   S/MIME messages (because they decrypted the middle wrapper). A
   sending agent might choose to use the multipart/signed format in the
   outer layer so that a non-S/MIME agent could see that the next inner
   layer is encrypted; however, this is not of great value, since all it
   shows the recipient is that the rest of the message is unreadable.
   Because many sending agents always use multipart/signed structures,
   all receiving agents MUST be able to interpret either
   multipart/signed or application/pkcs7-mime signature structures.

   The format of a triple wrapped message that uses multipart/signed for
   both signatures is:

   [step 8] Content-type: multipart/signed;
   [step 8]    protocol="application/pkcs7-signature";
   [step 8]    boundary=outerboundary
   [step 8]
   [step 8] --outerboundary
   [step 6] Content-type: application/pkcs7-mime;             )
   [step 6]    smime-type=enveloped-data                      )
   [step 6]                                                   )
   [step 4] Content-type: multipart/signed;                 | )
   [step 4]    protocol="application/pkcs7-signature";      | )
   [step 4]    boundary=innerboundary                       | )
   [step 4]                                                 | )
   [step 4] --innerboundary                                 | )
   [step 2] Content-type: text/plain                      % | )

Top       Page 5 
   [step 2]                                               % | )
   [step 1] Original content                              % | )
   [step 4]                                                 | )
   [step 4] --innerboundary                                 | )
   [step 4] Content-type: application/pkcs7-signature       | )
   [step 4]                                                 | )
   [step 3] inner SignedData block (eContent is missing)    | )
   [step 4]                                                 | )
   [step 4] --innerboundary--                               | )
   [step 8]
   [step 8] --outerboundary
   [step 8] Content-type: application/pkcs7-signature
   [step 8]
   [step 7] outer SignedData block (eContent is missing)
   [step 8]
   [step 8] --outerboundary--

   % = These lines are what the inner signature is computed over.
   | = These lines are what is encrypted in step 5. This encrypted result
       is opaque and is a part of an EnvelopedData block.
   ) = These lines are what the outer signature is computed over.

   The format of a triple wrapped message that uses application/pkcs7-
   mime for the both signatures is:

   [step 8] Content-type: application/pkcs7-mime;
   [step 8]    smime-type=signed-data
   [step 8]
   [step 7] outer SignedData block (eContent is present)        O
   [step 6] Content-type: application/pkcs7-mime;             ) O
   [step 6]    smime-type=enveloped-data;                     ) O
   [step 6]                                                   ) O
   [step 4] Content-type: application/pkcs7-mime;           | ) O
   [step 4]    smime-type=signed-data                       | ) O
   [step 4]                                                 | ) O
   [step 3] inner SignedData block (eContent is present)  I | ) O
   [step 2] Content-type: text/plain                      I | ) O
   [step 2]                                               I | ) O
   [step 1] Original content                              I | ) O

   I = These lines are the inner SignedData block, which is opaque and
       contains the ASN.1 encoded result of step 2 as well as control
       information.
   | = These lines are what is encrypted in step 5. This encrypted result
       is opaque and is a part of an EnvelopedData block.
   ) = These lines are what the outer signature is computed over.

Top       Page 6 
   O = These lines are the outer SignedData block, which is opaque and
       contains the ASN.1 encoded result of step 6 as well as control
       information.

1.3 Security Services and Triple Wrapping

   The first three security services described in this document are used
   with triple wrapped messages in different ways. This section briefly
   describes the relationship of each service with triple wrapping; the
   other sections of the document go into greater detail.

1.3.1 Signed Receipts and Triple Wrapping

   A signed receipt may be requested in any SignedData object. However,
   if a signed receipt is requested for a triple wrapped message, the
   receipt request MUST be in the inside signature, not in the outside
   signature.  A secure mailing list agent may change the receipt policy
   in the outside signature of a triple wrapped message when that
   message is processed by the mailing list.

   Note: the signed receipts and receipt requests described in this memo
   differ from those described in the work done by the IETF Receipt
   Notification Working Group. The output of that Working Group, when
   finished, is not expected to work well with triple wrapped messages
   as described in this document.

1.3.2 Security Labels and Triple Wrapping

   A security label may be included in the signed attributes of any
   SignedData object. A security label attribute may be included in
   either the inner signature, outer signature, or both.

   The inner security label is used for access control decisions related
   to the plaintext original content. The inner signature provides
   authentication and cryptographically protects the integrity of the
   original signer's security label that is in the inside body. This
   strategy facilitates the forwarding of messages because the original
   signer's security label is included in the SignedData block which can
   be forwarded to a third party that can verify the inner signature
   which will cover the inner security label. The confidentiality
   security service can be applied to the inner security label by
   encrypting the entire inner SignedData block within an EnvelopedData
   block.

   A security label may also be included in the signed attributes of the
   outer SignedData block which will include the sensitivities of the
   encrypted message. The outer security label is used for access
   control and routing decisions related to the encrypted message. Note

Top       Page 7 
   that a security label attribute can only be used in a
   signedAttributes block.  An eSSSecurityLabel attribute MUST NOT be
   used in an EnvelopedData or unsigned attributes.

1.3.3 Secure Mailing Lists and Triple Wrapping

   Secure mail list message processing depends on the structure of
   S/MIME layers present in the message sent to the mail list agent. The
   mail list agent never changes the data that was hashed to form the
   inner signature, if such a signature is present. If an outer
   signature is present, then the agent will modify the data that was
   hashed to form that outer signature. In all cases, the agent adds or
   updates an mlExpansionHistory attribute to document the agent's
   processing, and ultimately adds or replaces the outer signature on
   the message to be distributed.

1.3.4 Placement of Attributes

   Certain attributes should be placed in the inner or outer SignedData
   message; some attributes can be in either. Further, some attributes
   must be signed, while signing is optional for others, and some
   attributes must not be signed. ESS defines several types of
   attributes.  ContentHints and ContentIdentifier MAY appear in any
   list of attributes. contentReference, equivalentLabel,
   eSSSecurityLabel and mlExpansionHistory MUST be carried in a
   SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
   UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
   msgSigDigest, receiptRequest and signingCertificate MUST be carried
   in a SignedAttributes, and MUST NOT be carried in a AuthAttributes,
   UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.

Top       Page 8 
   The following table summarizes the recommendation of this profile. In
   the OID column, [ESS] indicates that the attribute is defined in this
   document.

                     |                              |Inner or  |
   Attribute         |OID                           |outer     |Signed
   ------------------|----------------------------- |----------|--------
   contentHints      |id-aa-contentHint [ESS]       |either    |MAY
   contentIdentifier |id-aa-contentIdentifier [ESS] |either    |MAY
   contentReference  |id-aa-contentReference [ESS]  |either    |MUST
   contentType       |id-contentType [CMS]          |either    |MUST
   counterSignature  |id-countersignature [CMS]     |either    |MUST NOT
   equivalentLabel   |id-aa-equivalentLabels [ESS]  |either    |MUST
   eSSSecurityLabel  |id-aa-securityLabel [ESS]     |either    |MUST
   messageDigest     |id-messageDigest [CMS]        |either    |MUST
   msgSigDigest      |id-aa-msgSigDigest [ESS]      |inner only|MUST
   mlExpansionHistory|id-aa-mlExpandHistory [ESS]   |outer only|MUST
   receiptRequest    |id-aa-receiptRequest [ESS]    |inner only|MUST
   signingCertificate|id-aa-signingCertificate [ESS]|either    |MUST
   signingTime       |id-signingTime [CMS]          |either    |MUST
   smimeCapabilities |sMIMECapabilities [MSG]       |either    |MUST
   sMIMEEncryption-
     KeyPreference   |id-aa-encrypKeyPref [MSG]     |either    |MUST

   CMS defines signedAttrs as a SET OF Attribute and defines
   unsignedAttrs as a SET OF Attribute. ESS defines the contentHints,
   contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
   receiptRequest, contentReference, equivalentLabels and
   signingCertificate attribute types. A signerInfo MUST NOT include
   multiple instances of any of the attribute types defined in ESS.
   Later sections of ESS specify further restrictions that apply to the
   receiptRequest, mlExpansionHistory and eSSecurityLabel attribute
   types.

   CMS defines the syntax for the signed and unsigned attributes as
   "attrValues SET OF AttributeValue". For all of the attribute types
   defined in ESS, if the attribute type is present in a signerInfo,
   then it MUST only include a single instance of AttributeValue. In
   other words, there MUST NOT be zero, or multiple, instances of
   AttributeValue present in the attrValues SET OF AttributeValue.

   If a counterSignature attribute is present, then it MUST be included
   in the unsigned attributes. It MUST NOT be included in the signed
   attributes. The only attributes that are allowed in a
   counterSignature attribute are counterSignature, messageDigest,
   signingTime, and signingCertificate.

Top       Page 9 
   Note that the inner and outer signatures are usually those of
   different senders. Because of this, the same attribute in the two
   signatures could lead to very different consequences.

   ContentIdentifier is an attribute (OCTET STRING) used to carry a
   unique identifier assigned to the message.

1.4 Required and Optional Attributes

   Some security gateways sign messages that pass through them. If the
   message is any type other than a signedData type, the gateway has
   only one way to sign the message: by wrapping it with a signedData
   block and MIME headers. If the message to be signed by the gateway is
   a signedData message already, the gateway can sign the message by
   inserting a signerInfo into the signedData block.

   The main advantage of a gateway adding a signerInfo instead of
   wrapping the message in a new signature is that the message doesn't
   grow as much as if the gateway wrapped the message. The main
   disadvantage is that the gateway must check for the presence of
   certain attributes in the other signerInfos and either omit or copy
   those attributes.

   If a gateway or other processor adds a signerInfo to an existing
   signedData block, it MUST copy the mlExpansionHistory and
   eSSSecurityLabel attributes from other signerInfos. This helps ensure
   that the recipient will process those attributes in a signerInfo that
   it can verify.

   Note that someone may in the future define an attribute that must be
   present in each signerInfo of a signedData block in order for the
   signature to be processed. If that happens, a gateway that inserts
   signerInfos and doesn't copy that attribute will cause every message
   with that attribute to fail when processed by the recipient. For this
   reason, it is safer to wrap messages with new signatures than to
   insert signerInfos.

1.5 Object Identifiers

   The object identifiers for many of the objects described in this memo
   are found in [CMS], [MSG], and [CERT]. Other object identifiers used
   in S/MIME can be found in the registry kept at
   <http://www.imc.org/ietf-smime/oids.html>. When this memo moves to
   standards track within the IETF, it is intended that the IANA will
   maintain this registry.

Top       Page 10 
2. Signed Receipts

   Returning a signed receipt provides to the originator proof of
   delivery of a message, and allows the originator to demonstrate to a
   third party that the recipient was able to verify the signature of
   the original message. This receipt is bound to the original message
   through the signature; consequently, this service may be requested
   only if a message is signed. The receipt sender may optionally also
   encrypt a receipt to provide confidentiality between the receipt
   sender and the receipt recipient.

2.1 Signed Receipt Concepts

   The originator of a message may request a signed receipt from the
   message's recipients. The request is indicated by adding a
   receiptRequest attribute to the signedAttributes field of the
   SignerInfo object for which the receipt is requested. The receiving
   user agent software SHOULD automatically create a signed receipt when
   requested to do so, and return the receipt in accordance with mailing
   list expansion options, local security policies, and configuration
   options.

   Because receipts involve the interaction of two parties, the
   terminology can sometimes be confusing. In this section, the "sender"
   is the agent that sent the original message that included a request
   for a receipt. The "receiver" is the party that received that message
   and generated the receipt.

   The steps in a typical transaction are:

   1. Sender creates a signed message including a receipt request
      attribute (Section 2.2).

   2. Sender transmits the resulting message to the recipient or
      recipients.

   3. Recipient receives message and determines if there is a valid
      signature and receipt request in the message (Section 2.3).

   4. Recipient creates a signed receipt (Section 2.4).

   5. Recipient transmits the resulting signed receipt message to the
      sender (Section 2.5).

Top       Page 11 
   6. Sender receives the message and validates that it contains a
      signed receipt for the original message (Section 2.6). This
      validation relies on the sender having retained either a copy of
      the original message or information extracted from the original
      message.

   The ASN.1 syntax for the receipt request is given in Section 2.7; the
   ASN.1 syntax for the receipt is given in Section 2.8.

   Note that a sending agent SHOULD remember when it has sent a receipt
   so that it can avoid re-sending a receipt each time it processes the
   message.

   A receipt request can indicate that receipts be sent to many places,
   not just to the sender (in fact, the receipt request might indicate
   that the receipts should not even go to the sender). In order to
   verify a receipt, the recipient of the receipt must be the originator
   or a recipient of the original message. Thus, the sender SHOULD NOT
   request that receipts be sent to anyone who does not have an exact
   copy of the message.

2.2 Receipt Request Creation

   Multi-layer S/MIME messages may contain multiple SignedData layers.
   However, receipts may be requested only for the innermost SignedData
   layer in a multi-layer S/MIME message, such as a triple wrapped
   message. Only one receiptRequest attribute can be included in the
   signedAttributes of a SignerInfo.

   A ReceiptRequest attribute MUST NOT be included in the attributes of
   a SignerInfo in a SignedData object that encapsulates a Receipt
   content.  In other words, the receiving agent MUST NOT request a
   signed receipt for a signed receipt.

   A sender requests receipts by placing a receiptRequest attribute in
   the signed attributes of a signerInfo as follows:

   1. A receiptRequest data structure is created.

   2. A signed content identifier for the message is created and assigned
      to the signedContentIdentifier field. The signedContentIdentifier
      is used to associate the signed receipt with the message requesting
      the signed receipt.

   3. The entities requested to return a signed receipt are noted in the
      receiptsFrom field.

Top       Page 12 
   4. The message originator MUST populate the receiptsTo field with a
      GeneralNames for each entity to whom the recipient should send the
      signed receipt. If the message originator wants the recipient to
      send the signed receipt to the originator, then the originator MUST
      include a GeneralNames for itself in the receiptsTo field.
      GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a
      SEQUENCE OF GeneralNames in which each GeneralNames represents an
      entity.  There may be multiple GeneralName instances in each
      GeneralNames.  At a minimum, the message originator MUST populate
      each entity's GeneralNames with the address to which the signed
      receipt should be sent. Optionally, the message originator MAY
      also populate each entity's GeneralNames with other GeneralName
      instances (such as directoryName).

   5. The completed receiptRequest attribute is placed in the
      signedAttributes field of the SignerInfo object.

2.2.1 Multiple Receipt Requests

   There can be multiple SignerInfos within a SignedData object, and
   each SignerInfo may include signedAttributes. Therefore, a single
   SignedData object may include multiple SignerInfos, each SignerInfo
   having a receiptRequest attribute. For example, an originator can
   send a signed message with two SignerInfos, one containing a DSS
   signature, the other containing an RSA signature.

   Each recipient SHOULD return only one signed receipt.

   Not all of the SignerInfos need to include receipt requests, but in
   all of the SignerInfos that do contain receipt requests, the receipt
   requests MUST be identical.

2.2.2 Information Needed to Validate Signed Receipts

   The sending agent MUST retain one or both of the following items to
   support the validation of signed receipts returned by the recipients.

    - the original signedData object requesting the signed receipt

    - the message signature digest value used to generate the original
      signedData signerInfo signature value and the digest value of the
      Receipt content containing values included in the original
      signedData object. If signed receipts are requested from multiple
      recipients, then retaining these digest values is a performance
      enhancement because the sending agent can reuse the saved values
      when verifying each returned signed receipt.

Top       Page 13 
2.3 Receipt Request Processing

   A receiptRequest is associated only with the SignerInfo object to
   which the receipt request attribute is directly attached. Receiving
   software SHOULD examine the signedAttributes field of each of the
   SignerInfos for which it verifies a signature in the innermost
   signedData object to determine if a receipt is requested. This may
   result in the receiving agent processing multiple receiptRequest
   attributes included in a single SignedData object, such as requests
   made from different people who signed the object in parallel.

   Before processing a receiptRequest signedAttribute, the receiving
   agent MUST verify the signature of the SignerInfo which covers the
   receiptRequest attribute. A recipient MUST NOT process a
   receiptRequest attribute that has not been verified. Because all
   receiptRequest attributes in a SignedData object must be identical,
   the receiving application fully processes (as described in the
   following paragraphs) the first receiptRequest attribute that it
   encounters in a SignerInfo that it verifies, and it then ensures that
   all other receiptRequest attributes in signerInfos that it verifies
   are identical to the first one encountered. If there are verified
   ReceiptRequest attributes which are not the same, then the processing
   software MUST NOT return any signed receipt. A signed receipt SHOULD
   be returned if any signerInfo containing a receiptRequest attribute
   can be validated, even if other signerInfos containing the same
   receiptRequest attribute cannot be validated because they are signed
   using an algorithm not supported by the receiving agent.

   If a receiptRequest attribute is absent from the signed attributes,
   then a signed receipt has not been requested from any of the message
   recipients and MUST NOT be created. If a receiptRequest attribute is
   present in the signed attributes, then a signed receipt has been
   requested from some or all of the message recipients. Note that in
   some cases, a receiving agent might receive two almost-identical
   messages, one with a receipt request and the other without one. In
   this case, the receiving agent SHOULD send a signed receipt for the
   message that requests a signed receipt.

   If a receiptRequest attribute is present in the signed attributes,
   the following process SHOULD be used to determine if a message
   recipient has been requested to return a signed receipt.

Top       Page 14 
   1. If an mlExpansionHistory attribute is present in the outermost
      signedData block, do one of the following two steps, based on the
      absence or presence of mlReceiptPolicy:

       1.1. If an mlReceiptPolicy value is absent from the last MLData
            element, a Mail List receipt policy has not been specified
            and the processing software SHOULD examine the
            receiptRequest attribute value to determine if a receipt
            should be created and returned.

       1.2. If an mlReceiptPolicy value is present in the last MLData
            element, do one of the following two steps, based on the
            value of mlReceiptPolicy:

           1.2.1. If the mlReceiptPolicy value is none, then the receipt
                  policy of the Mail List supersedes the originator's
                  request for a signed receipt and a signed receipt MUST
                  NOT be created.

           1.2.2. If the mlReceiptPolicy value is insteadOf or
                  inAdditionTo, the processing software SHOULD examine
                  the receiptsFrom value from the receiptRequest
                  attribute to determine if a receipt should be created
                  and returned. If a receipt is created, the insteadOf
                  and inAdditionTo fields identify entities that SHOULD
                  be sent the receipt instead of or in addition to the
                  originator.

   2. If the receiptsFrom value of the receiptRequest attribute
      allOrFirstTier, do one of the following two steps based on the
      value of allOrFirstTier.

       2.1. If the value of allOrFirstTier is allReceipts, then a signed
            receipt SHOULD be created.

       2.2. If the value of allOrFirstTier is firstTierRecipients, do
            one of the following two steps based on the presence of an
            mlExpansionHistory attribute in an outer signedData block:

           2.2.1. If an mlExpansionHistory attribute is present, then
                  this recipient is not a first tier recipient and a
                  signed receipt MUST NOT be created.

           2.2.2. If an mlExpansionHistory attribute is not present,
                  then a signed receipt SHOULD be created.

   3. If the receiptsFrom value of the receiptRequest attribute is a
      receiptList:

Top       Page 15 
       3.1. If receiptList contains one of the GeneralNames of the
            recipient, then a signed receipt SHOULD be created.

       3.2. If receiptList does not contain one of the GeneralNames of
            the recipient, then a signed receipt MUST NOT be created.

   A flow chart for the above steps to be executed for each signerInfo
   for which the receiving agent verifies the signature would be:

   0. Receipt Request attribute present?
          YES -> 1.
          NO  -> STOP
   1. Has mlExpansionHistory in outer signedData?
          YES -> 1.1.
          NO  -> 2.
   1.1. mlReceiptPolicy absent?
          YES -> 2.
          NO  -> 1.2.
   1.2. Pick based on value of mlReceiptPolicy.
          none -> 1.2.1.
          insteadOf or inAdditionTo -> 1.2.2.
   1.2.1. STOP.
   1.2.2. Examine receiptsFrom to determine if a receipt should be
       created, create it if required, send it to recipients designated
       by mlReceiptPolicy, then -> STOP.
   2. Is value of receiptsFrom allOrFirstTier?
          YES -> Pick based on value of allOrFirstTier.
                allReceipts -> 2.1.
                firstTierRecipients -> 2.2.
          NO  -> 3.
   2.1. Create a receipt, then -> STOP.
   2.2. Has mlExpansionHistory in the outer signedData block?
          YES -> 2.2.1.
          NO  -> 2.2.2.
   2.2.1. STOP.
   2.2.2. Create a receipt, then -> STOP.
   3. Is receiptsFrom value of receiptRequest a receiptList?
          YES -> 3.1.
          NO  -> STOP.
   3.1. Does receiptList contain the recipient?
          YES -> Create a receipt, then -> STOP.
          NO  -> 3.2.
   3.2. STOP.

Top       Page 16 
2.4 Signed Receipt Creation

   A signed receipt is a signedData object encapsulating a Receipt
   content (also called a "signedData/Receipt"). Signed receipts are
   created as follows:

   1. The signature of the original signedData signerInfo that includes
      the receiptRequest signed attribute MUST be successfully verified
      before creating the signedData/Receipt.

       1.1. The content of the original signedData object is digested as
            described in [CMS]. The resulting digest value is then
            compared with the value of the messageDigest attribute
            included in the signedAttributes of the original signedData
            signerInfo. If these digest values are different, then the
            signature verification process fails and the
            signedData/Receipt MUST NOT be created.

       1.2. The ASN.1 DER encoded signedAttributes (including
            messageDigest, receiptRequest and, possibly, other signed
            attributes) in the original signedData signerInfo are
            digested as described in [CMS]. The resulting digest
            value, called msgSigDigest, is then used to verify the
            signature of the original signedData signerInfo. If the
            signature verification fails, then the signedData/Receipt
            MUST NOT be created.

   2. A Receipt structure is created.

       2.1. The value of the Receipt version field is set to 1.

       2.2. The object identifier from the contentType attribute
            included in the original signedData signerInfo that
            includes the receiptRequest attribute is copied into
            the Receipt contentType.

       2.3. The original signedData signerInfo receiptRequest
            signedContentIdentifier is copied into the Receipt
            signedContentIdentifier.

       2.4. The signature value from the original signedData signerInfo
            that includes the receiptRequest attribute is copied into
            the Receipt originatorSignatureValue.

   3. The Receipt structure is ASN.1 DER encoded to produce a data
      stream, D1.

Top       Page 17 
   4. D1 is digested. The resulting digest value is included as the
      messageDigest attribute in the signedAttributes of the signerInfo
      which will eventually contain the signedData/Receipt signature
      value.

   5. The digest value (msgSigDigest) calculated in Step 1 to verify the
      signature of the original signedData signerInfo is included as the
      msgSigDigest attribute in the signedAttributes of the signerInfo
      which will eventually contain the signedData/Receipt signature
      value.

   6. A contentType attribute including the id-ct-receipt object
      identifier MUST be created and added to the signed attributes of
      the signerInfo which will eventually contain the
      signedData/Receipt signature value.

   7. A signingTime attribute indicating the time that the
      signedData/Receipt is signed SHOULD be created and added to the
      signed attributes of the signerInfo which will eventually contain
      the signedData/Receipt signature value. Other attributes (except
      receiptRequest) may be added to the signedAttributes of the
      signerInfo.

   8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
      possibly, others) of the signerInfo are ASN.1 DER encoded and
      digested as described in [CMS]. The resulting digest value is used
      to calculate the signature value which is then included in the
      signedData/Receipt signerInfo.

   9. The ASN.1 DER encoded Receipt content MUST be directly encoded
      within the signedData encapContentInfo eContent OCTET STRING
      defined in [CMS]. The id-ct-receipt object identifier MUST be
      included in the signedData encapContentInfo eContentType. This
      results in a single ASN.1 encoded object composed of a signedData
      including the Receipt content. The Data content type MUST NOT be
      used.  The Receipt content MUST NOT be encapsulated in a MIME
      header or any other header prior to being encoded as part of the
      signedData object.

   10. The signedData/Receipt is then put in an application/pkcs7-mime
       MIME wrapper with the smime-type parameter set to
       "signed-receipt".  This will allow for identification of signed
       receipts without having to crack the ASN.1 body. The smime-type
       parameter would still be set as normal in any layer wrapped
       around this message.

Top       Page 18 
   11. If the signedData/Receipt is to be encrypted within an
       envelopedData object, then an outer signedData object MUST be
       created that encapsulates the envelopedData object, and a
       contentHints attribute with contentType set to the id-ct-receipt
       object identifier MUST be included in the outer signedData
       SignerInfo signedAttributes.  When a receiving agent processes the
       outer signedData object, the presence of the id-ct-receipt OID in
       the contentHints contentType indicates that a signedData/Receipt
       is encrypted within the envelopedData object encapsulated by the
       outer signedData.

   All sending agents that support the generation of ESS signed receipts
   MUST provide the ability to send encrypted signed receipts (that is,
   a signedData/Receipt encapsulated within an envelopedData). The
   sending agent MAY send an encrypted signed receipt in response to an
   envelopedData-encapsulated signedData requesting a signed receipt. It
   is a matter of local policy regarding whether or not the signed
   receipt should be encrypted.  The ESS signed receipt includes the
   message digest value calculated for the original signedData object
   that requested the signed receipt. If the original signedData object
   was sent encrypted within an envelopedData object and the ESS signed
   receipt is sent unencrypted, then the message digest value calculated
   for the original encrypted signedData object is sent unencrypted. The
   responder should consider this when deciding whether or not to
   encrypt the ESS signed receipt.

2.4.1 MLExpansionHistory Attributes and Receipts

   An MLExpansionHistory attribute MUST NOT be included in the
   attributes of a SignerInfo in a SignedData object that encapsulates a
   Receipt content. This is true because when a SignedData/Receipt is
   sent to an MLA for distribution, then the MLA must always encapsulate
   the received SignedData/Receipt in an outer SignedData in which the
   MLA will include the MLExpansionHistory attribute. The MLA cannot
   change the signedAttributes of the received SignedData/Receipt
   object, so it can't add the MLExpansionHistory to the
   SignedData/Receipt.

2.5 Determining the Recipients of the Signed Receipt

   If a signed receipt was created by the process described in the
   sections above, then the software MUST use the following process to
   determine to whom the signed receipt should be sent.

   1. The receiptsTo field must be present in the receiptRequest
      attribute. The software initiates the sequence of recipients with
      the value(s) of receiptsTo.

Top       Page 19 
   2. If the MlExpansionHistory attribute is present in the outer
      SignedData block, and the last MLData contains an MLReceiptPolicy
      value of insteadOf, then the software replaces the sequence of
      recipients with the value(s) of insteadOf.

   3. If the MlExpansionHistory attribute is present in the outer
      SignedData block and the last MLData contains an MLReceiptPolicy
      value of inAdditionTo, then the software adds the value(s) of
      inAdditionTo to the sequence of recipients.

2.6. Signed Receipt Validation

   A signed receipt is communicated as a single ASN.1 encoded object
   composed of a signedData object directly including a Receipt content.
   It is identified by the presence of the id-ct-receipt object
   identifier in the encapContentInfo eContentType value of the
   signedData object including the Receipt content.

   Although recipients are not supposed to send more than one signed
   receipt, receiving agents SHOULD be able to accept multiple signed
   receipts from a recipient.

   A signedData/Receipt is validated as follows:

   1. ASN.1 decode the signedData object including the Receipt content.

   2. Extract the contentType, signedContentIdentifier, and
      originatorSignatureValue from the decoded Receipt structure to
      identify the original signedData signerInfo that requested the
      signedData/Receipt.

   3. Acquire the message signature digest value calculated by the sender
      to generate the signature value included in the original signedData
      signerInfo that requested the signedData/Receipt.

       3.1. If the sender-calculated message signature digest value has
            been saved locally by the sender, it must be located and
            retrieved.

       3.2. If it has not been saved, then it must be re-calculated based
            on the original signedData content and signedAttributes as
            described in [CMS].

   4. The message signature digest value calculated by the sender is then
      compared with the value of the msgSigDigest signedAttribute
      included in the signedData/Receipt signerInfo. If these digest
      values are identical, then that proves that the message signature
      digest value calculated by the recipient based on the received

Top       Page 20 
      original signedData object is the same as that calculated by the
      sender. This proves that the recipient received exactly the same
      original signedData content and signedAttributes as sent by the
      sender because that is the only way that the recipient could have
      calculated the same message signature digest value as calculated by
      the sender.  If the digest values are different, then the
      signedData/Receipt signature verification process fails.

   5. Acquire the digest value calculated by the sender for the Receipt
      content constructed by the sender (including the contentType,
      signedContentIdentifier, and signature value that were included in
      the original signedData signerInfo that requested the
      signedData/Receipt).

       5.1. If the sender-calculated Receipt content digest value has
            been  saved locally by the sender, it must be located and
            retrieved.

       5.2. If it has not been saved, then it must be re-calculated. As
            described in section above, step 2, create a Receipt
            structure including the contentType, signedContentIdentifier
            and signature value that were included in the original
            signedData signerInfo that requested the signed receipt. The
            Receipt structure is then ASN.1 DER encoded to produce a data
            stream which is then digested to produce the Receipt content
            digest value.

   6. The Receipt content digest value calculated by the sender is then
      compared with the value of the messageDigest signedAttribute
      included in the signedData/Receipt signerInfo. If these digest
      values are identical, then that proves that the values included in
      the Receipt content by the recipient are identical to those that
      were included in the original signedData signerInfo that requested
      the signedData/Receipt. This proves that the recipient received the
      original signedData signed by the sender, because that is the only
      way that the recipient could have obtained the original signedData
      signerInfo signature value for inclusion in the Receipt content. If
      the digest values are different, then the signedData/Receipt
      signature verification process fails.

   7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
      signerInfo are digested as described in [CMS].

   8. The resulting digest value is then used to verify the signature
      value included in the signedData/Receipt signerInfo. If the
      signature verification is successful, then that proves the
      integrity of the signedData/receipt signerInfo signedAttributes and
      authenticates the identity of the signer of the signedData/Receipt

Top       Page 21 
      signerInfo. Note that the signedAttributes include the
      recipient-calculated Receipt content digest value (messageDigest
      attribute) and recipient-calculated message signature digest value
      (msgSigDigest attribute). Therefore, the aforementioned comparison
      of the sender-generated and recipient-generated digest values
      combined with the successful signedData/Receipt signature
      verification proves that the recipient received the exact original
      signedData content and signedAttributes (proven by msgSigDigest
      attribute) that were signed by the sender of the original
      signedData object (proven by messageDigest attribute). If the
      signature verification fails, then the signedData/Receipt signature
      verification process fails.

   The signature verification process for each signature algorithm that
   is used in conjunction with the CMS protocol is specific to the
   algorithm.  These processes are described in documents specific to
   the algorithms.

2.7 Receipt Request Syntax

   A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use
   the receiptRequest attribute only within the signed attributes
   associated with a signed message.

ReceiptRequest ::= SEQUENCE {
  signedContentIdentifier ContentIdentifier,
  receiptsFrom ReceiptsFrom,
  receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }

ub-receiptsTo INTEGER ::= 16

id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}

ContentIdentifier ::= OCTET STRING

id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}

   A signedContentIdentifier MUST be created by the message originator
   when creating a receipt request. To ensure global uniqueness, the
   minimal signedContentIdentifier SHOULD contain a concatenation of
   user-specific identification information (such as a user name or
   public keying material identification information), a GeneralizedTime
   string, and a random number.

Top       Page 22 
   The receiptsFrom field is used by the originator to specify the
   recipients requested to return a signed receipt. A CHOICE is provided
   to allow specification of:

    - receipts from all recipients are requested
    - receipts from first tier (recipients that did not receive the
      message as members of a mailing list) recipients are requested
    - receipts from a specific list of recipients are requested

   ReceiptsFrom ::= CHOICE {
     allOrFirstTier [0] AllOrFirstTier,
     -- formerly "allOrNone [0]AllOrNone"
     receiptList [1] SEQUENCE OF GeneralNames }

   AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
     allReceipts (0),
     firstTierRecipients (1) }

   The receiptsTo field is used by the originator to identify the
   user(s) to whom the identified recipient should send signed receipts.
   The message originator MUST populate the receiptsTo field with a
   GeneralNames for each entity to whom the recipient should send the
   signed receipt. If the message originator wants the recipient to send
   the signed receipt to the originator, then the originator MUST
   include a GeneralNames for itself in the receiptsTo field.

2.8 Receipt Syntax

   Receipts are represented using a new content type, Receipt. The
   Receipt content type shall have ASN.1 type Receipt. Receipts must be
   encapsulated within a SignedData message.

Receipt ::= SEQUENCE {
  version ESSVersion,
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}

ESSVersion ::= INTEGER  { v1(1) }

   The version field defines the syntax version number, which is 1 for
   this version of the standard.

Top       Page 23 
2.9 Content Hints

   Many applications find it useful to have information that describes
   the innermost signed content of a multi-layer message available on
   the outermost signature layer. The contentHints attribute provides
   such information.

Content-hints attribute values have ASN.1 type contentHints.

ContentHints ::= SEQUENCE {
  contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  contentType ContentType }

id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}

   The contentDescription field may be used to provide information that
   the recipient may use to select protected messages for processing,
   such as a message subject. If this field is set, then the attribute
   is expected to appear on the signedData object enclosing an
   envelopedData object and not on the inner signedData object. The
   (SIZE (1..MAX)) construct constrains the sequence to have at least
   one entry. MAX indicates the upper bound is unspecified.
   Implementations are free to choose an upper bound that suits their
   environment.

   Messages which contain a signedData object wrapped around an
   envelopedData object, thus masking the inner content type of the
   message, SHOULD include a contentHints attribute, except for the case
   of the data content type. Specific message content types may either
   force or preclude the inclusion of the contentHints attribute. For
   example, when a signedData/Receipt is encrypted within an
   envelopedData object, an outer signedData object MUST be created that
   encapsulates the envelopedData object and a contentHints attribute
   with contentType set to the id-ct-receipt object identifier MUST be
   included in the outer signedData SignerInfo signedAttributes.

Top       Page 24 
2.10  Message Signature Digest Attribute

   The msgSigDigest attribute can only be used in the signed attributes
   of a signed receipt. It contains the digest of the ASN.1 DER encoded
   signedAttributes included in the original signedData that requested
   the signed receipt. Only one msgSigDigest attribute can appear in a
   signed attributes set. It is defined as follows:

msgSigDigest ::= OCTET STRING

id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}

2.11 Signed Content Reference Attribute

   The contentReference attribute is a link from one SignedData to
   another. It may be used to link a reply to the original message to
   which it refers, or to incorporate by reference one SignedData into
   another. The first SignedData MUST include a contentIdentifier signed
   attribute, which SHOULD be constructed as specified in section 2.7.
   The second SignedData links to the first by including a
   ContentReference signed attribute containing the content type,
   content identifier, and signature value from the first SignedData.

ContentReference ::= SEQUENCE {
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-aa-contentReference   OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }

3. Security Labels

   This section describes the syntax to be used for security labels that
   can optionally be associated with S/MIME encapsulated data. A
   security label is a set of security information regarding the
   sensitivity of the content that is protected by S/MIME encapsulation.

   "Authorization" is the act of granting rights and/or privileges to
   users permitting them access to an object. "Access control" is a
   means of enforcing these authorizations. The sensitivity information
   in a security label can be compared with a user's authorizations to
   determine if the user is allowed to access the content that is
   protected by S/MIME encapsulation.

Top       Page 25 
   Security labels may be used for other purposes such as a source of
   routing information. The labels often describe ranked levels
   ("secret", "confidential", "restricted", and so on) or are role-
   based, describing which kind of people can see the information
   ("patient's health-care team", "medical billing agents",
   "unrestricted", and so on).

3.1 Security Label Processing Rules

   A sending agent may include a security label attribute in the signed
   attributes of a signedData object. A receiving agent examines the
   security label on a received message and determines whether or not
   the recipient is allowed to see the contents of the message.

3.1.1 Adding Security Labels

   A sending agent that is using security labels MUST put the security
   label attribute in the signedAttributes field of a SignerInfo block.
   The security label attribute MUST NOT be included in the unsigned
   attributes. Integrity and authentication security services MUST be
   applied to the security label, therefore it MUST be included as a
   signed attribute, if used. This causes the security label attribute
   to be part of the data that is hashed to form the SignerInfo
   signature value. A SignerInfo block MUST NOT have more than one
   security label signed attribute.

   When there are multiple SignedData blocks applied to a message, a
   security label attribute may be included in either the inner
   signature, outer signature, or both. A security label signed
   attribute may be included in a signedAttributes field within the
   inner SignedData block.  The inner security label will include the
   sensitivities of the original content and will be used for access
   control decisions related to the plaintext encapsulated content. The
   inner signature provides authentication of the inner security label
   and cryptographically protects the original signer's inner security
   label of the original content.

   When the originator signs the plaintext content and signed
   attributes, the inner security label is bound to the plaintext
   content. An intermediate entity cannot change the inner security
   label without invalidating the inner signature. The confidentiality
   security service can be applied to the inner security label by
   encrypting the entire inner signedData object within an EnvelopedData
   block.

   A security label signed attribute may also be included in a
   signedAttributes field within the outer SignedData block. The outer
   security label will include the sensitivities of the encrypted

Top       Page 26 
   message and will be used for access control decisions related to the
   encrypted message and for routing decisions. The outer signature
   provides authentication of the outer security label (as well as for
   the encapsulated content which may include nested S/MIME messages).

   There can be multiple SignerInfos within a SignedData object, and
   each SignerInfo may include signedAttributes. Therefore, a single
   SignedData object may include multiple eSSSecurityLabels, each
   SignerInfo having an eSSSecurityLabel attribute. For example, an
   originator can send a signed message with two SignerInfos, one
   containing a DSS signature, the other containing an RSA signature. If
   any of the SignerInfos included in a SignedData object include an
   eSSSecurityLabel attribute, then all of the SignerInfos in that
   SignedData object MUST include an eSSSecurityLabel attribute and the
   value of each MUST be identical.

3.1.2 Processing Security Labels

   Before processing an eSSSecurityLabel signedAttribute, the receiving
   agent MUST verify the signature of the SignerInfo which covers the
   eSSSecurityLabel attribute. A recipient MUST NOT process an
   eSSSecurityLabel attribute that has not been verified.

   A receiving agent MUST process the eSSSecurityLabel attribute, if
   present, in each SignerInfo in the SignedData object for which it
   verifies the signature. This may result in the receiving agent
   processing multiple eSSSecurityLabels included in a single SignedData
   object. Because all eSSSecurityLabels in a SignedData object must be
   identical, the receiving agent processes (such as performing access
   control) on the first eSSSecurityLabel that it encounters in a
   SignerInfo that it verifies, and then ensures that all other
   eSSSecurityLabels in signerInfos that it verifies are identical to
   the first one encountered. If the eSSSecurityLabels in the
   signerInfos that it verifies are not all identical, then the
   receiving agent MUST warn the user of this condition.

   Receiving agents SHOULD have a local policy regarding whether or not
   to show the inner content of a signedData object that includes an
   eSSSecurityLabel security-policy-identifier that the processing
   software does not recognize. If the receiving agent does not
   recognize the eSSSecurityLabel security-policy-identifier value, then
   it SHOULD stop processing the message and indicate an error.


Next RFC Part