rfc2634.txt

<VC++网络游戏建摸与实现>源代码

   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