GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2634

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:
  1. signed receipts
  2. security labels
  3. secure mailing lists
  4. 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",
 "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 [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
    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".
  1. 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.
  1. 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".

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

 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                      % | )

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

 [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.

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

 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

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

 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.

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

 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.

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

 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.

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

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).

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

 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.

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

 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.
  1. the original signedData object requesting the signed receipt
  1. 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.

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

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.

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

 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:

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

     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.

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

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.

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

 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.

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

 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.

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

 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

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

    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

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

    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.

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

 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:
  1. receipts from all recipients are requested
  2. receipts from first tier (recipients that did not receive the

message as members of a mailing list) recipients are requested

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

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

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.

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

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.

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

 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

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

 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.

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

3.2 Syntax of eSSSecurityLabel

 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1
 module. (The MTSAbstractService module begins with "DEFINITIONS
 IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
 compatible with that used in [MSP4].

ESSSecurityLabel ::= SET {

security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }

id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)

  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}

SecurityPolicyIdentifier ::= OBJECT IDENTIFIER

SecurityClassification ::= INTEGER {

unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)

ub-integer-options INTEGER ::= 256

ESSPrivacyMark ::= CHOICE {

  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  utf8String   UTF8String (SIZE (1..MAX))

}

ub-privacy-mark-length INTEGER ::= 128

SecurityCategories ::= SET SIZE (1..ub-security-categories) OF

      SecurityCategory

ub-security-categories INTEGER ::= 64

SecurityCategory ::= SEQUENCE {

type  [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type

}

–Note: The aforementioned SecurityCategory syntax produces identical –hex encodings as the following SecurityCategory syntax that is –documented in the X.411 specification:

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

– –SecurityCategory ::= SEQUENCE { – type [0] SECURITY-CATEGORY, – value [1] ANY DEFINED BY type } – –SECURITY-CATEGORY MACRO ::= –BEGIN –TYPE NOTATION ::= type | empty –VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) –END

3.3 Security Label Components

 This section gives more detail on the the various components of the
 eSSSecurityLabel syntax.

3.3.1 Security Policy Identifier

 A security policy is a set of criteria for the provision of security
 services. The eSSSecurityLabel security-policy-identifier is used to
 identify the security policy in force to which the security label
 relates. It indicates the semantics of the other security label
 components.

3.3.2 Security Classification

 This specification defines the use of the Security Classification
 field exactly as is specified in the X.411 Recommendation, which
 states in part:
    If present, a security-classification may have one of a
    hierarchical list of values. The basic security-classification
    hierarchy is defined in this Recommendation, but the use of these
    values is defined by the security-policy in force. Additional
    values of security-classification, and their position in the
    hierarchy, may also be defined by a security-policy as a local
    matter or by bilateral agreement. The basic security-
    classification hierarchy is, in ascending order: unmarked,
    unclassified, restricted, confidential, secret, top-secret.
 This means that the security policy in force (identified by the
 eSSSecurityLabel security-policy-identifier) defines the
 SecurityClassification integer values and their meanings.
 An organization can develop its own security policy that defines the
 SecurityClassification INTEGER values and their meanings. However,
 the general interpretation of the X.411 specification is that the
 values of 0 through 5 are reserved for the "basic hierarchy" values

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

 of unmarked, unclassified, restricted, confidential, secret, and
 top-secret. Note that X.411 does not provide the rules for how these
 values are used to label data and how access control is performed
 using these values.
 There is no universal definition of the rules for using these "basic
 hierarchy" values. Each organization (or group of organizations) will
 define a security policy which documents how the "basic hierarchy"
 values are used (if at all) and how access control is enforced (if at
 all) within their domain.
 Therefore, the security-classification value MUST be accompanied by a
 security-policy-identifier value to define the rules for its use. For
 example, a company's "secret" classification may convey a different
 meaning than the US Government "secret" classification. In summary, a
 security policy SHOULD NOT use integers 0 through 5 for other than
 their X.411 meanings, and SHOULD instead use other values in a
 hierarchical fashion.
 Note that the set of valid security-classification values MUST be
 hierarchical, but these values do not necessarily need to be in
 ascending numerical order. Further, the values do not need to be
 contiguous.
 For example, in the Defense Message System 1.0 security policy, the
 security-classification value of 11 indicates Sensitive-But-
 Unclassified and 5 indicates top-secret. The hierarchy of sensitivity
 ranks top-secret as more sensitive than Sensitive-But-Unclassified
 even though the numerical value of top-secret is less than
 Sensitive-But-Unclassified.
 (Of course, if security-classification values are both hierarchical
 and in ascending order, a casual reader of the security policy is
 more likely to understand it.)
 An example of a security policy that does not use any of the X.411
 values might be:
 10 -- anyone
 15 -- Morgan Corporation and its contractors
 20 -- Morgan Corporation employees
 25 -- Morgan Corporation board of directors
 An example of a security policy that uses part of the X.411 hierarchy
 might be:
 0 -- unmarked
 1 -- unclassified, can be read by everyone

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

 2 -- restricted to Timberwolf Productions staff
 6 -- can only be read to Timberwolf Productions executives

3.3.3 Privacy Mark

 If present, the eSSSecurityLabel privacy-mark is not used for access
 control. The content of the eSSSecurityLabel privacy-mark may be
 defined by the security policy in force (identified by the
 eSSSecurityLabel security-policy-identifier) which may define a list
 of values to be used. Alternately, the value may be determined by the
 originator of the security-label.

3.3.4 Security Categories

 If present, the eSSSecurityLabel security-categories provide further
 granularity for the sensitivity of the message. The security policy
 in force (identified by the eSSSecurityLabel security-policy-
 identifier) is used to indicate the syntaxes that are allowed to be
 present in the eSSSecurityLabel security-categories. Alternately, the
 security-categories and their values may be defined by bilateral
 agreement.

3.4 Equivalent Security Labels

 Because organizations are allowed to define their own security
 policies, many different security policies will exist. Some
 organizations may wish to create equivalencies between their security
 policies with the security policies of other organizations. For
 example, the Acme Company and the Widget Corporation may reach a
 bilateral agreement that the "Acme private" security-classification
 value is equivalent to the "Widget sensitive" security-classification
 value.
 Receiving agents MUST NOT process an equivalentLabels attribute in a
 message if the agent does not trust the signer of that attribute to
 translate the original eSSSecurityLabel values to the security policy
 included in the equivalentLabels attribute. Receiving agents have the
 option to process equivalentLabels attributes but do not have to. It
 is acceptable for a receiving agent to only process
 eSSSecurityLabels. All receiving agents SHOULD recognize
 equivalentLabels attributes even if they do not process them.

3.4.1 Creating Equivalent Labels

 The EquivalentLabels signed attribute is defined as:

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

EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel

id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)

      us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
 As stated earlier, the ESSSecurityLabel contains the sensitivity
 values selected by the original signer of the signedData. If an
 ESSSecurityLabel is present in a signerInfo, all signerInfos in the
 signedData MUST contain an ESSSecurityLabel and they MUST all be
 identical. In addition to an ESSSecurityLabel, a signerInfo MAY also
 include an equivalentLabels signed attribute. If present, the
 equivalentLabels attribute MUST include one or more security labels
 that are believed by the signer to be semantically equivalent to the
 ESSSecurityLabel attribute included in the same signerInfo.
 All security-policy object identifiers MUST be unique in the set of
 ESSSecurityLabel and EquivalentLabels security labels. Before using
 an EquivalentLabels attribute, a receiving agent MUST ensure that all
 security-policy OIDs are unique in the security label or labels
 included in the EquivalentLabels. Once the receiving agent selects
 the security label (within the EquivalentLabels) to be used for
 processing, then the security-policy OID of the selected
 EquivalentLabels security label MUST be compared with the
 ESSSecurityLabel security-policy OID to ensure that they are unique.
 In the case that an ESSSecurityLabel attribute is not included in a
 signerInfo, then an EquivalentLabels attribute may still be included.
 For example, in the Acme security policy, the absence of an
 ESSSecurityLabel could be defined to equate to a security label
 composed of the Acme security-policy OID and the "unmarked"
 security-classification.
 Note that equivalentLabels MUST NOT be used to convey security labels
 that are semantically different from the ESSSecurityLabel included in
 the signerInfos in the signedData. If an entity needs to apply a
 security label that is semantically different from the
 ESSSecurityLabel, then it MUST include the sematically different
 security label in an outer signedData object that encapsulates the
 signedData object that includes the ESSSecurityLabel.
 If present, the equivalentLabels attribute MUST be a signed
 attribute; it MUST NOT be an unsigned attribute. [CMS] defines
 signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include
 multiple instances of the equivalentLabels attribute. CMS defines the
 ASN.1 syntax for the signed attributes to include attrValues SET OF

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

 AttributeValue. A equivalentLabels attribute MUST only include a
 single instance of AttributeValue. There MUST NOT be zero or multiple
 instances of AttributeValue present in the attrValues SET OF
 AttributeValue.

3.4.2 Processing Equivalent Labels

 A receiving agent SHOULD process the ESSSecurityLabel before
 processing any EquivalentLabels. If the policy in the
 ESSSecurityLabel is understood by the receiving agent, it MUST
 process that label and MUST ignore all EquivalentLabels.
 When processing an EquivalentLabels attribute, the receiving agent
 MUST validate the signature on the EquivalentLabels attribute. A
 receiving agent MUST NOT act on an equivalentLabels attribute for
 which the signature could not be validated, and MUST NOT act on an
 equivalentLabels attribute unless that attribute is signed by an
 entity trusted to translate the original eSSSecurityLabel values to
 the security policy included in the equivalentLabels attribute.
 Determining who is allowed to specify equivalence mappings is a local
 policy. If a message has more than one EquivalentLabels attribute,
 the receiving agent SHOULD process the first one that it reads and
 validates that contains the security policy of interest to the
 receiving agent.

4. Mail List Management

 Sending agents must create recipient-specific data structures for
 each recipient of an encrypted message. This process can impair
 performance for messages sent to a large number of recipients. Thus,
 Mail List Agents (MLAs) that can take a single message and perform
 the recipient-specific encryption for every recipient are often
 desired.
 An MLA appears to the message originator as a normal message
 recipient, but the MLA acts as a message expansion point for a Mail
 List (ML). The sender of a message directs the message to the MLA,
 which then redistributes the message to the members of the ML. This
 process offloads the per-recipient processing from individual user
 agents and allows for more efficient management of large MLs. MLs are
 true message recipients served by MLAs that provide cryptographic and
 expansion services for the mailing list.
 In addition to cryptographic handling of messages, secure mailing
 lists also have to prevent mail loops. A mail loop is where one
 mailing list is a member of a second mailing list, and the second

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

 mailing list is a member of the first. A message will go from one
 list to the other in a rapidly-cascading succession of mail that will
 be distributed to all other members of both lists.
 To prevent mail loops, MLAs use the mlExpansionHistory attribute of
 the outer signature of a triple wrapped message. The
 mlExpansionHistory attribute is essentially a list of every MLA that
 has processed the message. If an MLA sees its own unique entity
 identifier in the list, it knows that a loop has been formed, and
 does not send the message to the list again.

4.1 Mail List Expansion

 Mail list expansion processing is noted in the value of the
 mlExpansionHistory attribute, located in the signed attributes of the
 MLA's SignerInfo block. The MLA creates or updates the signed
 mlExpansionHistory attribute value each time the MLA expands and
 signs a message for members of a mail list.
 The MLA MUST add an MLData record containing the MLA's identification
 information, date and time of expansion, and optional receipt policy
 to the end of the mail list expansion history sequence. If the
 mlExpansionHistory attribute is absent, then the MLA MUST add the
 attribute and the current expansion becomes the first element of the
 sequence. If the mlExpansionHistory attribute is present, then the
 MLA MUST add the current expansion information to the end of the
 existing MLExpansionHistory sequence. Only one mlExpansionHistory
 attribute can be included in the signedAttributes of a SignerInfo.
 Note that if the mlExpansionHistory attribute is absent, then the
 recipient is a first tier message recipient.
 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 mlExpansionHistory attribute. For example, an MLA can send a
 signed message with two SignerInfos, one containing a DSS signature,
 the other containing an RSA signature.
 If an MLA creates a SignerInfo that includes an mlExpansionHistory
 attribute, then all of the SignerInfos created by the MLA for that
 SignedData object MUST include an mlExpansionHistory attribute, and
 the value of each MUST be identical. Note that other agents might
 later add SignerInfo attributes to the SignedData block, and those
 additional SignerInfos might not include mlExpansionHistory
 attributes.

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

 A recipient MUST verify the signature of the SignerInfo which covers
 the mlExpansionHistory attribute before processing the
 mlExpansionHistory, and MUST NOT process the mlExpansionHistory
 attribute unless the signature over it has been verified. If a
 SignedData object has more than one SignerInfo that has an
 mlExpansionHistory attribute, the recipient MUST compare the
 mlExpansionHistory attributes in all the SignerInfos that it has
 verified, and MUST NOT process the mlExpansionHistory attribute
 unless every verified mlExpansionHistory attribute in the SignedData
 block is identical. If the mlExpansionHistory attributes in the
 verified signerInfos are not all identical, then the receiving agent
 MUST stop processing the message and SHOULD notify the user or MLA
 administrator of this error condition. In the mlExpansionHistory
 processing, SignerInfos that do not have an mlExpansionHistory
 attribute are ignored.

4.1.1 Detecting Mail List Expansion Loops

 Prior to expanding a message, the MLA examines the value of any
 existing mail list expansion history attribute to detect an expansion
 loop. An expansion loop exists when a message expanded by a specific
 MLA for a specific mail list is redelivered to the same MLA for the
 same mail list.
 Expansion loops are detected by examining the mailListIdentifier
 field of each MLData entry found in the mail list expansion history.
 If an MLA finds its own identification information, then the MLA must
 discontinue expansion processing and should provide warning of an
 expansion loop to a human mail list administrator. The mail list
 administrator is responsible for correcting the loop condition.

4.2 Mail List Agent Processing

 The first few paragraphs of this section provide a high-level
 description of MLA processing. The rest of the section provides a
 detailed description of MLA processing.
 MLA message processing depends on the structure of the S/MIME layers
 in the message sent to the MLA for expansion. In addition to sending
 triple wrapped messages to an MLA, an entity can send other types of
 messages to an MLA, such as:
  1. a single wrapped signedData or envelopedData message
  2. a double wrapped message (such as signed and enveloped, enveloped

and signed, or signed and signed, and so on)

  1. a quadruple-wrapped message (such as if a well-formed triple

wrapped message was sent through a gateway that added an outer

    SignedData layer)

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

 In all cases, the MLA MUST parse all layers of the received message
 to determine if there are any signedData layers that include an
 eSSSecurityLabel signedAttribute. This may include decrypting an
 EnvelopedData layer to determine if an encapsulated SignedData layer
 includes an eSSSecurityLabel attribute. The MLA MUST fully process
 each eSSSecurityLabel attribute found in the various signedData
 layers, including performing access control checks, before
 distributing the message to the ML members. The details of the access
 control checks are beyond the scope of this document. The MLA MUST
 verify the signature of the signerInfo including the eSSSecurityLabel
 attribute before using it.
 In all cases, the MLA MUST sign the message to be sent to the ML
 members in a new "outer" signedData layer. The MLA MUST add or update
 an mlExpansionHistory attribute in the "outer" signedData that it
 creates to document MLA processing. If there was an "outer"
 signedData layer included in the original message received by the
 MLA, then the MLA-created "outer" signedData layer MUST include each
 signed attribute present in the original "outer" signedData layer,
 unless the MLA explicitly replaces an attribute (such as signingTime
 or mlExpansionHistory) with a new value.
 When an S/MIME message is received by the MLA, the MLA MUST first
 determine which received signedData layer, if any, is the "outer"
 signedData layer.  To identify the received "outer" signedData layer,
 the MLA MUST verify the signature and fully process the
 signedAttributes in each of the outer signedData layers (working from
 the outside in) to determine if any of them either include an
 mlExpansionHistory attribute or encapsulate an envelopedData object.
 The MLA's search for the "outer" signedData layer is completed when
 it finds one of the following:
  1. the "outer" signedData layer that includes an mlExpansionHistory

attribute or encapsulates an envelopedData object

  1. an envelopedData layer
  2. the original content (that is, a layer that is neither

envelopedData nor signedData).

 If the MLA finds an "outer" signedData layer, then the MLA MUST
 perform the following steps:
 1. Strip off all of the signedData layers that encapsulated the
    "outer" signedData layer
 2. Strip off the "outer" signedData layer itself (after remembering
    the included signedAttributes)

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

 3. Expand the envelopedData (if present)
 4. Sign the message to be sent to the ML members in a new "outer"
    signedData layer that includes the signedAttributes (unless
    explicitly replaced) from the original, received "outer" signedData
    layer.
 If the MLA finds an "outer" signedData layer that includes an
 mlExpansionHistory attribute AND the MLA subsequently finds an
 envelopedData layer buried deeper with the layers of the received
 message, then the MLA MUST strip off all of the signedData layers
 down to the envelopedData layer (including stripping off the original
 "outer" signedData layer) and MUST sign the expanded envelopedData in
 a new "outer" signedData layer that includes the signedAttributes
 (unless explicitly replaced) from the original, received "outer"
 signedData layer.
 If the MLA does not find an "outer" signedData layer AND does not
 find an envelopedData layer, then the MLA MUST sign the original,
 received message in a new "outer" signedData layer. If the MLA does
 not find an "outer" signedData AND does find an envelopedData layer
 then it MUST expand the envelopedData layer, if present, and sign it
 in a new "outer" signedData layer.

4.2.1 Examples of Rule Processing

 The following examples help explain the rules above:
 1) A message (S1(Original Content)) (where S = SignedData) is sent to
    the MLA in which the signedData layer does not include an
    MLExpansionHistory attribute. The MLA verifies and fully processes
    the signedAttributes in S1.  The MLA decides that there is not an
    original, received "outer" signedData layer since it finds the
    original content, but never finds an envelopedData and never finds
    an mlExpansionHistory attribute. The MLA calculates a new
    signedData layer, S2, resulting in the following message sent to
    the ML recipients: (S2(S1(Original Content))). The MLA includes an
    mlExpansionHistory attribute in S2.
 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in
    which none of the signedData layers includes an MLExpansionHistory
    attribute. The MLA verifies and fully processes the
    signedAttributes in S3, S2 and S1. The MLA decides that there is
    not an original, received "outer" signedData layer since it finds
    the original content, but never finds an envelopedData and never
    finds an mlExpansionHistory attribute. The MLA calculates a new
    signedData layer, S4, resulting in the following

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

    message sent to the ML recipients:
    (S4(S3(S2(S1(Original Content))))). The MLA includes an
    mlExpansionHistory attribute in S4.
 3) A message (E1(S1(Original Content))) (where E = envelopedData) is
    sent to the MLA in which S1 does not include an MLExpansionHistory
    attribute.  The MLA decides that there is not an original,
    received "outer" signedData layer since it finds the E1 as the
    outer layer.  The MLA expands the recipientInformation in E1. The
    MLA calculates a new signedData layer, S2, resulting in the
    following message sent to the ML recipients:
    (S2(E1(S1(Original Content)))). The MLA includes an
    mlExpansionHistory attribute in S2.
 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in
    which S2 includes an MLExpansionHistory attribute. The MLA verifies
    the signature and fully processes the signedAttributes in S2. The
    MLA finds the mlExpansionHistory attribute in S2, so it decides
    that S2 is the "outer" signedData. The MLA remembers the
    signedAttributes included in S2 for later inclusion in the new
    outer signedData that it applies to the message. The MLA strips off
    S2. The MLA then expands the recipientInformation in E1 (this
    invalidates the signature in S2 which is why it was stripped). The
    nMLA calculates a new signedData layer, S3, resulting in the
    following message sent to the ML recipients: (S3(E1(S1(Original
    Content)))). The MLA includes in S3 the attributes from S2 (unless
    it specifically replaces an attribute value) including an updated
    mlExpansionHistory attribute.
 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
    which none of the signedData layers include an MLExpansionHistory
    attribute. The MLA verifies the signature and fully processes the
    signedAttributes in S3 and S2. When the MLA encounters E1, then it
    decides that S2 is the "outer" signedData since S2 encapsulates E1.
    The MLA remembers the signedAttributes included in S2 for later
    inclusion in the new outer signedData that it applies to the
    message.  The MLA strips off S3 and S2. The MLA then expands the
    recipientInformation in E1 (this invalidates the signatures in S3
    and S2 which is why they were stripped). The MLA calculates a new
    signedData layer, S4, resulting in the following message sent to
    the ML recipients: (S4(E1(S1(Original Content)))). The MLA
    includes in S4 the attributes from S2 (unless it specifically
    replaces an attribute value) and includes a new
    mlExpansionHistory attribute.
 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
    which S3 includes an MLExpansionHistory attribute. In this case,
    the MLA verifies the signature and fully processes the

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

    signedAttributes in S3. The MLA finds the mlExpansionHistory in S3,
    so it decides that S3 is the "outer" signedData. The MLA remembers
    the signedAttributes included in S3 for later inclusion in the new
    outer signedData that it applies to the message. The MLA keeps on
    parsing encapsulated layers because it must determine if there are
    any eSSSecurityLabel attributes contained within. The MLA verifies
    the signature and fully processes the signedAttributes in S2. When
    the MLA encounters E1, then it strips off S3 and S2. The MLA then
    expands the recipientInformation in E1 (this invalidates the
    signatures in S3 and S2 which is why they were stripped). The MLA
    calculates a new signedData layer, S4, resulting in the following
    message sent to the ML recipients: (S4(E1(S1(Original Content)))).
    The MLA includes in S4 the attributes from S3 (unless it
    specifically replaces an attribute value) including an updated
    mlExpansionHistory attribute.

4.2.3 Processing Choices

 The processing used depends on the type of the outermost layer of the
 message. There are three cases for the type of the outermost data:
  1. EnvelopedData
  2. SignedData
  3. data

4.2.3.1 Processing for EnvelopedData

 1. The MLA locates its own RecipientInfo and uses the information it
    contains to obtain the message key.
 2. The MLA removes the existing recipientInfos field and replaces it
    with a new recipientInfos value built from RecipientInfo
 structures
    created for each member of the mailing list. The MLA also removes
    the existing originatorInfo field and replaces it with a new
    originatorInfo value built from information describing the MLA.
 3. The MLA encapsulates the expanded encrypted message in a
    SignedData block, adding an mlExpansionHistory attribute as
    described in the "Mail List Expansion" section to document the
    expansion.
 4. The MLA signs the new message and delivers the updated message to
    mail list members to complete MLA processing.

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

4.2.3.2 Processing for SignedData

 MLA processing of multi-layer messages depends on the type of data in
 each of the layers. Step 3 below specifies that different processing
 will take place depending on the type of CMS message that has been
 signed. That is, it needs to know the type of data at the next inner
 layer, which may or may not be the innermost layer.
 1. The MLA verifies the signature value found in the outermost
    SignedData layer associated with the signed data. MLA
    processing of the message terminates if the message signature
    is invalid.
 2. If the outermost SignedData layer includes a signed
    mlExpansionHistory attribute, the MLA checks for an expansion loop
    as described in the "Detecting Mail List Expansion Loops" section,
    then go to step 3. If the outermost SignedData layer does not
    include a signed mlExpansionHistory attribute, the MLA signs the
    whole message (including this outermost SignedData layer that
    doesn't have an mlExpansionHistory attribute), and delivers the
    updated message to mail list members to complete MLA processing.
 3. Determine the type of the data that has been signed. That is, look
    at the type of data on the layer just below the SignedData, which
    may or may not be the "innermost" layer. Based on the type of data,
    perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or
    step 3.3 (all other types).
     3.1. If the signed data is EnvelopedData, the MLA performs
          expansion processing of the encrypted message as
          described previously. Note that this process invalidates the
          signature value in the outermost SignedData layer associated
          with the original encrypted message.  Proceed to section 3.2
          with the result of the expansion.
     3.2. If the signed data is SignedData, or is the result of
          expanding an EnvelopedData block in step 3.1:
         3.2.1. The MLA strips the existing outermost SignedData layer
                after remembering the value of the mlExpansionHistory
                and all other signed attributes in that layer, if
                present.
         3.2.2.  If the signed data is EnvelopedData (from step 3.1),
                 the MLA encapsulates the expanded encrypted message
                 in a new outermost SignedData layer. On the other

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

                 hand, if the signed data is SignedData (from step
                 3.2), the MLA encapsulates the signed data in a new
                 outermost SignedData layer.
         3.2.3.  The outermost signedData layer created by the MLA
                 replaces the original outermost signedData layer. The
                 MLA MUST create an signed attribute list for the new
                 outermost signedData layer which MUST include each
                 signed attribute present in the original outermost
                 signedData layer, unless the MLA explicitly replaces
                 one or more particular attributes with new value. A
                 special case is the mlExpansionHistory attribute. The
                 MLA MUST add an mlExpansionHistory signed attribute
                 to the outer signedData layer as follows:
             3.2.3.1. If the original outermost SignedData layer
                      included an mlExpansionHistory attribute, the
                      attribute's value is copied and updated with the
                      current ML expansion information as described in
                      the "Mail List Expansion" section.
             3.2.3.2. If the original outermost SignedData layer did
                      not include an mlExpansionHistory attribute, a
                      new attribute value is created with the current
                      ML expansion information as described in the
                      "Mail List Expansion" section.
     3.3. If the signed data is not EnvelopedData or SignedData:
         3.3.1.  The MLA encapsulates the received signedData object in
                 an outer SignedData object, and adds an
                 mlExpansionHistory attribute to the outer SignedData
                 object containing the current ML expansion information
                 as described in the "Mail List Expansion" section.
 4. The MLA signs the new message and delivers the updated message to
    mail list members to complete MLA processing.
 A flow chart for the above steps would be:
 1. Has a valid signature?
        YES -> 2.
        NO  -> STOP.
 2. Does outermost SignedData layer contain mlExpansionHistory?
        YES -> Check it, then -> 3.
        NO  -> Sign message (including outermost SignedData that
               doesn't have mlExpansionHistory), deliver it, STOP.
 3. Check type of data just below outermost SignedData.

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

        EnvelopedData -> 3.1.
        SignedData -> 3.2.
        all others -> 3.3.
 3.1. Expand the encrypted message, then -> 3.2.
 3.2. -> 3.2.1.
 3.2.1. Strip outermost SignedData layer, note value of
        mlExpansionHistory and other signed attributes, then -> 3.2.2.
 3.2.2. Encapsulate in new signature, then -> 3.2.3.
 3.2.3. Create new signedData layer. Was there an old
        mlExpansionHistory?
        YES -> copy the old mlExpansionHistory values, then -> 4.
        NO  -> create new mlExpansionHistory value, then -> 4.
 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
        attribute, then -> 4.
 4. Sign message, deliver it, STOP.

4.2.3.3 Processing for data

 1. The MLA encapsulates the message in a SignedData layer, and adds an
    mlExpansionHistory attribute containing the current ML expansion
    information as described in the "Mail List Expansion" section.
 2. The MLA signs the new message and delivers the updated message to
    mail list members to complete MLA processing.
 4.3 Mail List Agent Signed Receipt Policy Processing
 If a mailing list (B) is a member of another mailing list (A), list B
 often needs to propagate forward the mailing list receipt policy of
 A. As a general rule, a mailing list should be conservative in
 propagating forward the mailing list receipt policy because the
 ultimate recipient need only process the last item in the ML
 expansion history. The MLA builds the expansion history to meet this
 requirement.

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

 The following table describes the outcome of the union of mailing
 list A's policy (the rows in the table) and mailing list B's policy
 (the columns in the table).
           |                    B's policy

A's policy | none insteadOf inAdditionTo missing


none | none none none none insteadOf | none insteadOf(B) *1 insteadOf(A) inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) missing | none insteadOf(B) inAdditionTo(B) missing

*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))

4.4 Mail List Expansion History Syntax

 An mlExpansionHistory attribute value has ASN.1 type
 MLExpansionHistory. If there are more than ub-ml-expansion-history
 mailing lists in the sequence, the receiving agent should provide
 notification of the error to a human mail list administrator. The
 mail list administrator is responsible for correcting the overflow
 condition.

MLExpansionHistory ::= SEQUENCE

      SIZE (1..ub-ml-expansion-history) OF MLData

id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)

  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}

ub-ml-expansion-history INTEGER ::= 64

 MLData contains the expansion history describing each MLA that has
 processed a message. As an MLA distributes a message to members of an
 ML, the MLA records its unique identifier, date and time of
 expansion, and receipt policy in an MLData structure.

MLData ::= SEQUENCE {

mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }

EntityIdentifier ::= CHOICE {

issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }

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

 The receipt policy of the ML can withdraw the originator's request
 for the return of a signed receipt. However, if the originator of the
 message has not requested a signed receipt, the MLA cannot request a
 signed receipt. In the event that a ML's signed receipt policy
 supersedes the originator's request for signed receipts, such that
 the originator will not receive any signed receipts, then the MLA MAY
 inform the originator of that fact.
 When present, the mlReceiptPolicy specifies a receipt policy that
 supersedes the originator's request for signed receipts. The policy
 can be one of three possibilities: receipts MUST NOT be returned
 (none); receipts should be returned to an alternate list of
 recipients, instead of to the originator (insteadOf); or receipts
 should be returned to a list of recipients in addition to the
 originator (inAdditionTo).
 MLReceiptPolicy ::= CHOICE {
   none [0] NULL,
   insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
   inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

5. Signing Certificate Attribute

 Concerns have been raised over the fact that the certificate which
 the signer of a CMS SignedData object desired to be bound into the
 verification process of the SignedData object is not
 cryptographically bound into the signature itself. This section
 addresses this issue by creating a new attribute to be placed in the
 signed attributes section of a SignerInfo object.
 This section also presents a description of a set of possible attacks
 dealing with the substitution of one certificate to verify the
 signature for the desired certificate. A set of ways for preventing
 or addressing these attacks is presented to deal with the simplest of
 the attacks.
 Authorization information can be used as part of a signature
 verification process. This information can be carried in either
 attribute certificates and other public key certificates. The signer
 needs to have the ability to restrict the set of certificates used in
 the signature verification process, and information needs to be
 encoded so that is covered by the signature on the SignedData object.
 The methods in this section allow for the set of authorization
 certificates to be listed as part of the signing certificate
 attribute.

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

 Explicit certificate policies can also be used as part of a signature
 verification process. If a signer desires to state an explicit
 certificate policy that should be used when validating the signature,
 that policy needs to be cryptographically bound into the signing
 process. The methods described in this section allows for a set of
 certificate policy statements to be listed as part of the signing
 certificate attribute.

5.1. Attack Descriptions

 At least three different attacks can be launched against a possible
 signature verification process by replacing the certificate or
 certficates used in the signature verification process.

5.1.1 Substitution Attack Description

 The first attack deals with simple substitution of one certificate
 for another certificate. In this attack, the issuer and serial number
 in the SignerInfo is modified to refer to a new certificate. This new
 certificate is used during the signature verification process.
 The first version of this attack is a simple denial of service attack
 where an invalid certificate is substituted for the valid
 certificate. This renders the message unverifiable, as the public key
 in the certificate no longer matches the private key used to sign the
 message.
 The second version is a substitution of one valid certificate for the
 original valid certificate where the public keys in the certificates
 match.  This allows the signature to be validated under potentially
 different certificate constraints than the originator of the message
 intended.

5.1.2 Reissue of Certificate Description

 The second attack deals with a certificate authority (CA) re-issuing
 the signing certificate (or potentially one of its certificates).
 This attack may start becoming more frequent as Certificate
 Authorities reissue their own root certificates, or as certificate
 authorities change policies in the certificate while reissuing their
 root certificates. This problem also occurs when cross certificates
 (with potentially different restrictions) are used in the process of
 verifying a signature.

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

5.1.3 Rogue Duplicate CA Description

 The third attack deals with a rogue entity setting up a certificate
 authority that attempts to duplicate the structure of an existing CA.
 Specifically, the rogue entity issues a new certificate with the same
 public keys as the signer used, but signed by the rogue entity's
 private key.

5.2 Attack Responses

 This document does not attempt to solve all of the above attacks;
 however, a brief description of responses to each of the attacks is
 given in this section.

5.2.1 Substitution Attack Response

 The denial of service attack cannot be prevented. After the
 certificate identifier has been modified in transit, no verification
 of the signature is possible. There is also no way to automatically
 identify the attack because it is indistinguishable from a message
 corruption.
 The substitution of a valid certificate can be responded to in two
 different manners. The first is to make a blanket statement that the
 use of the same public key in two different certificates is bad
 practice and has to be avoided. In practice, there is no practical
 way to prevent users from getting new certificates with the same
 public keys, and it should be assumed that they will do this. Section
 5.4 provides a new attribute that can be included in the SignerInfo
 signed attributes. This binds the correct certificate identifier into
 the signature. This will convert the attack from a potentially
 successful one to simply a denial of service attack.

5.2.2 Reissue of Certificate Response

 A CA should never reissue a certificate with different attributes.
 Certificate Authorities that do so are following poor practices and
 cannot be relied on. Using the hash of the certificate as the
 reference to the certificate prevents this attack for end-entity
 certificates.
 Preventing the attack based on reissuing of CA certificates would
 require a substantial change to the usage of the signingCertificate
 attribute presented in section 5.4. It would require that ESSCertIDs
 would need to be included in the attribute to represent the issuer
 certificates in the signer's certification path. This presents
 problems when the relying party is using a cross-certificate as part
 of its authentication process, and this certificate does not appear

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

 on the list of certificates. The problems outside of a closed PKI
 make the addition of this information prone to error, possibly
 causing the rejection of valid chains.

5.2.3 Rogue Duplicate CA Response

 The best method of preventing this attack is to avoid trusting the
 rogue CA. The use of the hash to identify certificates prevents the
 use of end-entity certificates from the rogue authority. However the
 only true way to prevent this attack is to never trust the rogue CA.

5.3 Related Signature Verification Context

 Some applications require that additional information be used as part
 of the signature validation process. In particular, authorization
 information from attribute certificates and other public key
 certificates or policy identifiers provide additional information
 about the abilities and intent of the signer. The signing certificate
 attribute described in Section 5.4 provides the ability to bind this
 context information as part of the signature.

5.3.1 Authorization Information

 Some applications require that authorization information found in
 attribute certificates and/or other public key certificates be
 validated. This validation requires that the application be able to
 find the correct certificates to perform the verification process;
 however there is no list of the certificates to used in a SignerInfo
 object. The sender has the ability to include a set of attribute
 certificates and public key certificates in a SignedData object. The
 receiver has the ability to retrieve attribute certificates and
 public key certificates from a directory service. There are some
 circumstances where the signer may wish to limit the set of
 certificates that may be used in verifying a signature. It is useful
 to be able to list the set of certificates the signer wants the
 recipient to use in validating the signature.

5.3.2 Policy Information

 A related aspect of the certificate binding is the issue of multiple
 certification paths. In some instances, the semantics of a
 certificate in its use with a message may depend on the Certificate
 Authorities and policies that apply. To address this issue, the
 signer may also wish to bind that context under the signature. While
 this could be done by either signing the complete certification path
 or a policy ID, only a binding for the policy ID is described here.

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

5.4 Signing Certificate Attribute Definition

 The signing certificate attribute is designed to prevent the simple
 substitution and re-issue attacks, and to allow for a restricted set
 of authorization certificates to be used in verifying a signature.
 The definition of SigningCertificate is
 SigningCertificate ::=  SEQUENCE {
     certs        SEQUENCE OF ESSCertID,
     policies     SEQUENCE OF PolicyInformation OPTIONAL
 }
 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
     smime(16) id-aa(2) 12 }
 The first certificate identified in the sequence of certificate
 identifiers MUST be the certificate used to verify the signature. The
 encoding of the ESSCertID for this certificate SHOULD include the
 issuerSerial field. If other constraints ensure that
 issuerAndSerialNumber will be present in the SignerInfo, the
 issuerSerial field MAY be omitted. The certificate identified is used
 during the signature verification process. If the hash of the
 certificate does not match the certificate used to verify the
 signature, the signature MUST be considered invalid.
 If more than one certificate is present in the sequence of
 ESSCertIDs, the certificates after the first one limit the set of
 authorization certificates that are used during signature validation.
 Authorization certificates can be either attribute certificates or
 normal certificates. The issuerSerial field (in the ESSCertID
 structure) SHOULD be present for these certificates, unless the
 client who is validating the signature is expected to have easy
 access to all the certificates requred for validation. If only the
 signing certificate is present in the sequence, there are no
 restrictions on the set of authorization certificates used in
 validating the signature.
 The sequence of policy information terms identifies those certificate
 policies that the signer asserts apply to the certificate, and under
 which the certificate should be relied upon. This value suggests a
 policy value to be used in the relying party's certification path
 validation.
 If present, the SigningCertificate attribute MUST be a signed
 attribute; it MUST NOT be an unsigned attribute. CMS defines
 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include

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

 multiple instances of the SigningCertificate attribute. CMS defines
 the ASN.1 syntax for the signed attributes to include attrValues SET
 OF AttributeValue. A SigningCertificate attribute MUST include only a
 single instance of AttributeValue. There MUST NOT be zero or multiple
 instances of AttributeValue present in the attrValues SET OF
 AttributeValue.

5.4.1 Certificate Identification

 The best way to identify certificates is an often-discussed issue.
 [CERT] has imposed a restriction for SignedData objects that the
 issuer DN must be present in all signing certificates. The
 issuer/serial number pair is therefore sufficient to identify the
 correct signing certificate. This information is already present, as
 part of the SignerInfo object, and duplication of this information
 would be unfortunate. A hash of the entire certificate serves the
 same function (allowing the receiver to verify that the same
 certificate is being used as when the message was signed), is
 smaller, and permits a detection of the simple substitution attacks.
 Attribute certificates and additional public key certificates
 containing authorization information do not have an issuer/serial
 number pair represented anywhere in a SignerInfo object. When an
 attribute certificate or an additional public key certificate is not
 included in the SignedData object, it becomes much more difficult to
 get the correct set of certificates based only on a hash of the
 certificate. For this reason, these certificates SHOULD be identified
 by the IssuerSerial object.
 This document defines a certificate identifier as:
 ESSCertID ::=  SEQUENCE {
      certHash                 Hash,
      issuerSerial             IssuerSerial OPTIONAL
 }
 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
 IssuerSerial ::= SEQUENCE {
      issuer                   GeneralNames,
      serialNumber             CertificateSerialNumber
 }
 When creating an ESSCertID, the certHash is computed over the entire
 DER encoded certificate including the signature. The issuerSerial
 would normally be present unless the value can be inferred from other
 information.

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

 When encoding IssuerSerial, serialNumber is the serial number that
 uniquely identifies the certificate. For non-attribute certificates,
 the issuer MUST contain only the issuer name from the certificate
 encoded in the directoryName choice of GeneralNames. For attribute
 certificates, the issuer MUST contain the issuer name field from the
 attribute certificate.

6. Security Considerations

 All security considerations from [CMS] and [SMIME3] apply to
 applications that use procedures described in this document.
 As stated in Section 2.3, a recipient of a receipt request must not
 send back a reply if it cannot validate the signature. Similarly, if
 there conflicting receipt requests in a message, the recipient must
 not send back receipts, since an attacker may have inserted the
 conflicting request.  Sending a signed receipt to an unvalidated
 sender can expose information about the recipient that it may not
 want to expose to unknown senders.
 Senders of receipts should consider encrypting the receipts to
 prevent a passive attacker from gleaning information in the receipts.
 Senders must not rely on recipients' processing software to correctly
 process security labels. That is, the sender cannot assume that
 adding a security label to a message will prevent recipients from
 viewing messages the sender doesn't want them to view. It is expected
 that there will be many S/MIME clients that will not understand
 security labels but will still display a labelled message to a
 recipient.
 A receiving agent that processes security labels must handle the
 content of the messages carefully. If the agent decides not to show
 the message to the intended recipient after processing the security
 label, the agent must take care that the recipient does not
 accidentally see the content at a later time. For example, if an
 error response sent to the originator contains the content that was
 hidden from the recipient, and that error response bounces back to
 the sender due to addressing errors, the original recipient can
 possibly see the content since it is unlikely that the bounce message
 will have the proper security labels.
 A man-in-the-middle attack can cause a recipient to send receipts to
 an attacker if that attacker has a signature that can be validated by
 the recipient. The attack consists of intercepting the original
 message and adding a mLData attribute that says that a receipt should
 be sent to the attacker in addition to whoever else was going to get
 the receipt.

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

 Mailing lists that encrypt their content may be targets for denial-
 of-service attacks if they do not use the mailing list management
 described in Section 4. Using simple RFC822 header spoofing, it is
 quite easy to subscribe one encrypted mailing list to another,
 thereby setting up an infinite loop.
 Mailing List Agents need to be aware that they can be used as oracles
 for the the adaptive chosen ciphertext attack described in [CMS].
 MLAs should notify an administrator if a large number of
 undecryptable messages are received.
 When verifying a signature using certificates that come with a [CMS]
 message, the recipient should only verify using certificates
 previously known to be valid, or certificates that have come from a
 signed SigningCertificate attribute. Otherwise, the attacks described
 in Section 5 can cause the receiver to possibly think a signature is
 valid when it is not.

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

A. ASN.1 Module

ExtendedSecurityServices

   { iso(1) member-body(2) us(840) rsadsi(113549)
     pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

IMPORTS

– Cryptographic Message Syntax (CMS)

  ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
  FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

– PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, – 1988 Syntax

  PolicyInformation FROM PKIX1Implicit88 {iso(1)
  identified-organization(3) dod(6) internet(1) security(5)
  mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}

– X.509

  GeneralNames, CertificateSerialNumber FROM CertificateExtensions
  {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};

– Extended Security Services

– The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 – constructs in this module. A valid ASN.1 SEQUENCE can have zero or – more entries. 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.

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

  1. - The contents are formatted as described in [UTF8]

– Section 2.7

ReceiptRequest ::= SEQUENCE {

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

ub-receiptsTo INTEGER ::= 16

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

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}

ReceiptsFrom ::= CHOICE {

allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }

AllOrFirstTier ::= INTEGER { – Formerly AllOrNone

allReceipts (0),
firstTierRecipients (1) }

– Section 2.8

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) }

– Section 2.9

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}

– Section 2.10

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}

– Section 2.11

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

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 }

– Section 3.2

ESSSecurityLabel ::= SET {

security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }

id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)

  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}

SecurityPolicyIdentifier ::= OBJECT IDENTIFIER

SecurityClassification ::= INTEGER {

unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)

ub-integer-options INTEGER ::= 256

ESSPrivacyMark ::= CHOICE {

  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  utf8String   UTF8String (SIZE (1..MAX))

}

ub-privacy-mark-length INTEGER ::= 128

SecurityCategories ::= SET SIZE (1..ub-security-categories) OF

      SecurityCategory

ub-security-categories INTEGER ::= 64

SecurityCategory ::= SEQUENCE {

type  [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type

}

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

–Note: The aforementioned SecurityCategory syntax produces identical –hex encodings as the following SecurityCategory syntax that is –documented in the X.411 specification: – –SecurityCategory ::= SEQUENCE { – type [0] SECURITY-CATEGORY, – value [1] ANY DEFINED BY type } – –SECURITY-CATEGORY MACRO ::= –BEGIN –TYPE NOTATION ::= type | empty –VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) –END

– Section 3.4

EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel

id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)

  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}

– Section 4.4

MLExpansionHistory ::= SEQUENCE

      SIZE (1..ub-ml-expansion-history) OF MLData

id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)

  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}

ub-ml-expansion-history INTEGER ::= 64

MLData ::= SEQUENCE {

mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }

EntityIdentifier ::= CHOICE {

issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }

MLReceiptPolicy ::= CHOICE {

none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

– Section 5.4

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

SigningCertificate ::= SEQUENCE {

  certs        SEQUENCE OF ESSCertID,
  policies     SEQUENCE OF PolicyInformation OPTIONAL

}

id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)

  member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
  smime(16) id-aa(2) 12 }

ESSCertID ::= SEQUENCE {

   certHash                 Hash,
   issuerSerial             IssuerSerial OPTIONAL

}

Hash ::= OCTET STRING – SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {

   issuer                   GeneralNames,
   serialNumber             CertificateSerialNumber

}

END – of ExtendedSecurityServices

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

B. References

 [ASN1-1988]  "Recommendation X.208: Specification of Abstract Syntax
              Notation One (ASN.1)".
 [ASN1-1994]  "Recommendation X.680: Specification of Abstract Syntax
              Notation One (ASN.1)".
 [CERT]       Ramsdell, B., Editor, "S/MIME Version 3 Certificate
              Handling", RFC 2632, June 1999.
 [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
              June 1999.
 [MSG]        Ramsdell, B., Editor, "S/MIME Version 3 Message
              Specification", RFC 2633, June 1999.
 [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [MSP4]       "Secure Data Network System (SDNS) Message Security
              Protocol (MSP) 4.0", Specification SDN.701, Revision A,
              1997-02-06.
 [MTSABS]     "1988 International Telecommunication Union (ITU) Data
              Communication Networks Message Handling Systems: Message
              Transfer System:  Abstract Service Definition and
              Procedures, Volume VIII, Fascicle VIII.7, Recommendation
              X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
              mts(3) modules(0) mts-abstract-service(1)}
 [PKCS7-1.5]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax",
              RFC 2315, March 1998.
 [SMIME2]     Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
              L.  Repka"S/MIME Version 2 Message Specification", RFC
              2311, March 1998, and Dusse, S., Hoffman, P. and B.
              Ramsdell,"S/MIME Version 2 Certificate Handling", RFC
              2312, March 1998.
 [UTF8]       Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

C. Acknowledgments

 The first draft of this work was prepared by David Solo. John Pawling
 did a huge amount of very detailed revision work during the many
 phases of the document.

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

 Many other people have contributed hard work to this memo, including:
 Andrew Farrell
 Bancroft Scott
 Bengt Ackzell
 Bill Flanigan
 Blake Ramsdell
 Carlisle Adams
 Darren Harter
 David Kemp
 Denis Pinkas
 Francois Rousseau
 Jim Schaad
 Russ Housley
 Scott Hollenbeck
 Steve Dusse

Editor's Address

 Paul Hoffman
 Internet Mail Consortium
 127 Segre Place
 Santa Cruz, CA  95060
 EMail: phoffman@imc.org

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

Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Hoffman Standards Track [Page 58]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2634.txt · Last modified: 1999/07/06 21:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki