rfc2634.txt

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

Network Working Group                                P. Hoffman, Editor
Request for Comments: 2634                     Internet Mail Consortium
Category: Standards Track                                     June 1999


                 Enhanced Security Services for S/MIME

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Introduction

   This document describes four optional security service extensions for
   S/MIME. The services are:

    - signed receipts
    - security labels
    - secure mailing lists
    - signing certificates

   The first three of these services provide functionality that is
   similar to the Message Security Protocol [MSP4], but are useful in
   many other environments, particularly business and finance. Signing
   certificates are useful in any environment where certificates might
   be transmitted with signed messages.

   The services described here are extensions to S/MIME version 3 ([MSG]
   and [CERT]), and some of them can also be added to S/MIME version 2
   [SMIME2]. The extensions described here will not cause an S/MIME
   version 3 recipient to be unable to read messages from an S/MIME
   version 2 sender. However, some of the extensions will cause messages
   created by an S/MIME version 3 sender to be unreadable by an S/MIME
   version 2 recipient.

   This document describes both the procedures and the attributes needed
   for the four services. Note that some of the attributes described in
   this document are quite useful in other contexts and should be
   considered when extending S/MIME or other CMS applications.




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

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

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

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






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