rfc2634.txt

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

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

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

2.2.1 Multiple Receipt Requests

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

   Each recipient SHOULD return only one signed receipt.

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

2.2.2 Information Needed to Validate Signed Receipts

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

    - the original signedData object requesting the signed receipt

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





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