rfc2634.txt

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

      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:

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

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

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

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

2.8 Receipt Syntax

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

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

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

ESSVersion ::= INTEGER  { v1(1) }

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






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)