rfc3183.txt

RFC 的详细文档！


RFC 3183         Domain Security Services using S/MIME      October 2001


3.5 Originator Signature

   The 'originator signature' is used to indicate that the signer is the
   originator of the message and its contents.  It is included in this
   document for completeness only.  An originator signature is indicated
   either by the absence of the signature type attribute, or by the
   presence of the value id-sti-originatorSig in a 'signature type'
   signed attribute.

4. Encryption and Decryption

   Message encryption may be performed by a third party on behalf of a
   set of originators in a domain.  This is referred to as domain
   encryption.  Message decryption may be performed by a third party on
   behalf of a set of recipients in a domain.  This is referred to as
   domain decryption.  The third party that performs these processes is
   referred to in this section as a "Domain Confidentiality Authority"
   (DCA).  Both of these processes are described in this section.

   Messages may be encrypted for decryption by the final recipient
   and/or by a DCA in the recipient's domain.  The message may also be
   encrypted for decryption by a DCA in the originator's domain (e.g.,
   for content analysis, audit, key word scanning, etc.).  The choice of
   which of these is actually performed is a system specific issue that
   depends on system security policy.  It is therefore outside the scope
   of this document.  These processes of encryption and decryption
   processes are shown in the following table.

 --------------------------------------------------------------------
|                        | Recipient Decryption |  Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption  |       Case(a)        |       Case(b)      |
| Domain Encryption      |       Case(c)        |       Case(d)      |
 --------------------------------------------------------------------

   Case (a), encryption of messages by the originator for decryption by
   the final recipient(s), is described in CMS [5].  In cases (c) and
   (d), encryption is performed not by the originator but by the DCA in
   the originator's domain. In cases (b) and (d), decryption is
   performed not by the recipient(s) but by the DCA in the recipient's
   domain.

   A client implementation that conforms to this standard MUST support
   case (b) for transmission, case (c) for reception and case (a) for
   transmission and reception.






Dean & Ottaway                Experimental                     [Page 13]

RFC 3183         Domain Security Services using S/MIME      October 2001


   A DCA implementation that conforms to this standard MUST support
   cases (c) and (d), for transmission, and cases (b) and (d) for
   reception.  In cases (c) and (d) the 'domain signature' SHOULD be
   applied before the encryption.  In cases (b) and (d) the message
   SHOULD be decrypted before the originators 'domain signature' is
   obtained and verified.

   The process of encryption and decryption is documented in CMS [5].
   The only additional requirement introduced by domain encryption and
   decryption is for greater flexibility in the management of keys, as
   described in the following subsections.  As with signatures, a naming
   convention and name mapping convention are used to locate the correct
   public key.

   The mechanisms described below are applicable both to key agreement
   and key transport systems, as documented in CMS [5].  The phrase
   'encryption key' is used as a collective term to cover the key
   management keys used by both techniques.

   The mechanisms below are also applicable to individual roving users
   who wish to encrypt messages that are sent back to base.

4.1 Domain Confidentiality Naming Conventions

   A DCA MUST be named 'domain-confidentiality-authority'.  This name
   MUST appear in the 'common name(CN)' component of the subject field
   in the X.509 certificate.  Additionally, if the certificate contains
   an RFC 822 address, this name MUST appear in the end entity part of
   the address, i.e., on the left-hand side of the '@' symbol.

   Along with this naming convention, an additional naming rule is
   defined:  the 'name mapping rule'.  The name mapping rule states that
   for a DCA, the domain part of its name MUST be the same as, or an
   ascendant of (as defined in section 3.1.1), the domain name of the
   set of entities that it represents.  The domain part is defined as
   follows:

   *  In the case of an X.500 distinguished name of an X.509
      certificate, the domain part is the country, organization,
      organizational unit, state, and locality components of the
      distinguished name.

   * In the case of an RFC 2247 distinguished name, the domain part is
      the domain components of the distinguished name.

   * If the certificate contains an RFC 822 address, the domain part is
      defined to be the RFC 822 address part on the right-hand side of
      the '@' symbol.



Dean & Ottaway                Experimental                     [Page 14]

RFC 3183         Domain Security Services using S/MIME      October 2001


   For example, a DCA acting on behalf of John Doe of the Acme
   corporation, whose distinguished name is 'cn=John Doe,ou=marketing,
   o=acme,c=us' and whose e-mail address is [e-mail],
   could have a certificate containing a distinguished name of
   'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail
   address of '[e-mail]'.  If John Doe
   has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,
   dc=defense,dc=acme,dc=us' then the domain signing authority could
   have a distinguished name of
   'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'.  The key
   associated with this certificate would be used for encrypting
   messages for John Doe.

   Any message received where the domain part of the domain encrypting
   agents name does not match, or is not an ascendant of, the domain
   name of the entities it represents MUST be flagged.

   This naming rule prevents messages being encrypted for the wrong
   domain decryption agent.

   Implementations conforming to this standard MUST support this name
   mapping convention as a minimum.  Implementations may choose to
   supplement this convention with other locally defined conventions.
   However, these MUST be agreed between sender and recipient domains
   prior to sending any messages.

4.2 Key Management for DCA Encryption

   At the sender's domain, DCA encryption is achieved using the
   recipient DCA's certificate or the end recipient's certificate.  For
   this, the encrypting process must be able to correctly locate the
   certificate for the corresponding DCA in the recipient's domain or
   the one corresponding to the end recipient.  Having located the
   correct certificate, the encryption process is then performed and
   additional information required for decryption is conveyed to the
   recipient in the recipientInfo field as specified in CMS [5].  A DCA
   encryption agent MUST be named according to the naming convention
   specified in section 4.1.  This is so that the corresponding
   certificate can be found.

   No specific method for locating the certificate to the corresponding
   DCA in the recipient's domain or the one corresponding to the end
   recipient is mandated in this document.  An implementation may choose
   to access a local certificate store to locate the correct
   certificate.  Alternatively, a X.500 or LDAP directory may be used in
   one of the following ways:





Dean & Ottaway                Experimental                     [Page 15]

RFC 3183         Domain Security Services using S/MIME      October 2001


   1. The directory may store the DCA certificate in the recipient's
      directory entry.  When the user certificate attribute is
      requested, this certificate is returned.

   2. The encrypting agent maps the recipient's name to the DCA name in
      the manner specified in 4.1.  The user certificate attribute
      associated with this directory entry is then obtained.

   This document does not mandate either of these processes.  Whichever
   one is used, the name mapping conventions must be adhered to, in
   order to maintain confidentiality.

   Having located the correct certificate, the encryption process is
   then performed.  A recipientInfo for the DCA or end recipient is then
   generated, as described in CMS [5].

   DCA encryption may be performed for decryption by the end recipient
   and/or by a DCA.  End recipient decryption is described in CMS [5].
   DCA decryption is described in section 4.3.

4.3 Key Management for DCA Decryption

   DCA decryption uses a private-key belonging to the DCA and the
   necessary information conveyed in the DCA's recipientInfo field.

   It should be noted that domain decryption can be performed on
   messages encrypted by the originator and/or by a DCA in the
   originator's domain.  In the first case, the encryption process is
   described in CMS [5]; in the second case, the encryption process is
   described in 4.2.

5. Applying a Domain Signature when Mail List Agents are Present.

   It is possible that a message leaving a DOMSEC domain may encounter a
   Mail List Agent (MLA) before it reaches the final recipient.  There
   is a possibility that this would result in the 'domain signature'
   being stripped off the message.  We do not want a MLA to remove the
   'domain signature'.  Therefore, the 'domain signature' must be
   applied to the message in such a way that will prevent a MLA from
   removing it.

   A MLA will search a message for the "outer" signedData layer, as
   defined in ESS [3] section 4.2, and strip off all signedData layers
   that encapsulate this "outer" signedData layer.  Where this "outer"
   signedData layer is found will depend on whether the message contains
   a mlExpansionHistory attribute or an envelopedData layer.





Dean & Ottaway                Experimental                     [Page 16]

RFC 3183         Domain Security Services using S/MIME      October 2001


   There is a possibility that a message leaving a DOMSEC domain has
   already been processed by a MLA, in which case a 'mlExpansionHistory'
   attribute will be present within the message.

   There is a possibility that the message will contain an envelopedData
   layer.  This will be the case when the message has been encrypted
   within the domain for the domain's "Domain Confidentiality
   Authority", see section 4.0, and, possibly, the final recipient.

   How the 'domain signature' is applied will depend on what is already
   present within the message.  Before the 'domain signature' can be
   applied the message MUST be searched for the "outer" signedData
   layer, this search is complete when one of the following is found: -

      -  The "outer" signedData layer that includes an
         mlExpansionHistory attribute or encapsulates an envelopedData
         object.
      -  An envelopedData layer.
      -  The original content (that is, a layer that is neither
         envelopedData nor signedData).

   If a signedData layer containing a mlExpansionHistory attribute has
   been found then: -

      1) Strip off the signedData layer (after remembering the included
         signedAttributes).

      2) Search the rest of the message until an envelopedData layer or
         the original content is found.

      3) a) If an envelopedData layer has been found then: -

            -  Strip off all the signedData layers down to the
               envelopedData layer.
            -  Locate the RecipientInfo for the local DCA and use the
               information it contains to obtain the message key.
            -  Decrypt the encryptedContent using the message key.
            -  Encapsulate the decrypted message with a 'domain
               signature'
            -  If local policy requires the message to be encrypted
               using S/MIME encryption before leaving the domain then
               encapsulate the 'domain signature' with an envelopedData
               layer containing RecipientInfo structures for each of the
               recipients and an originatorInfo value built from
               information describing this DCA.






Dean & Ottaway                Experimental                     [Page 17]

RFC 3183         Domain Security Services using S/MIME      October 2001


               If local policy does not require the message to be
               encrypted using S/MIME encryption but there is an
               envelopedData at a lower level within the message then
               the 'domain signature' MUST be encapsulated by an
               envelopedData as described above.

               An example when it may not be local policy to require
               S/MIME encryption is when there is a link crypto present.

      b) If an envelopedData layer has not been found then: -

            -  Encapsulate the new message with a 'domain signature'.

      4) Encapsulate the new message in a signedData layer, adding the
         signedAttributes from the signedData layer that contained the
         mlExpansionHistory attribute.

   If no signedData layer containing a mlExpansionHistory attribute has
   been found but an envelopedData has been found then: -

      1) Strip off all the signedData layers down to the envelopedData
         layer.
      2) Locate the RecipientInfo for the local DCA and use the
         information it contains to obtain the message key.
      3) Decrypt the encryptedContent using the message key.
      4) Encapsulate the decrypted message with a 'domain signature'
      5) If local policy requires the message to be encrypted before
         leaving the domain then encapsulate the 'domain signature' with
         an envelopedData layer containing RecipientInfo structures for
         each of the recipients and an originatorInfo value built from
         information describing this DCA.

         If local policy does not require the message to be encrypted
         using S/MIME encryption but there is an envelopedData at a
         lower level within the message then the 'domain signature' MUST
         be encapsulated by an envelopedData as described above.

   If no signedData layer containing a mlExpansionHistory attribute has
   been found and no envelopedData has been found then: -

      1) Encapsulate the message in a 'domain signature'.

5.1 Examples of Rule Processing

   The following examples help explain the above rules.  All of the
   signedData objects are valid and none of them are a domain signature.
   If a signedData object was a domain signature then it would not be
   necessary to validate any further signedData objects.



Dean & Ottaway                Experimental                     [Page 18]