rfc3183.txt

RFC 的详细文档！

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


3.1.1 Naming Conventions

   The following naming conventions are specified for agents generating
   signatures specified in this document:

   *  For a domain signature, an agent generating this signature MUST be
      named 'domain-signing-authority'

   *  For a review signature, an agent generating this signature MUST be
      named 'review-authority'.

   *  For an additional attributes signature, an agent generating this
      signature MUST be named 'attribute-authority'.

   This name shall appear as the 'common name (CN)' component of the
   subject field in the X.509 certificate.  There MUST be only one CN
   component present.  Additionally, if the certificate contains an RFC
   822 address, this name shall appear in the end entity component of
   the address - on the left-hand side of the '@' symbol.

   In the case of a domain signature, an additional naming rule is
   defined: the 'name mapping rule'.  The name mapping rule states that
   for a domain signing authority, the domain part of its name MUST be
   the same as, or an ascendant of, the domain name of the message
   originator(s) that it is representing.  The domain part is defined as
   follows:

   *  In the case of an X.500 distinguished subject 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 component on the right-hand side
      of the '@' symbol.

   For example, a domain signing authority 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-signing-authority,o=acme,c=us' and an RFC 822 address of
   '[e-mail]'.  If John Doe has an RFC 2247





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


   defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' then an
   address of 'cn=domain-signing-authority,dc=acme,dc=us' could be used
   to represent the domain signing authority.

   When the X.500 distinguished subject name has consecutive
   organizational units and/or localities it is important to understand
   the ordering of these values in order to determine if the domain part
   of the domain signature is an ascendant.  In this case, when parsing
   the distinguished subject name from the most significant component
   (i.e., country, locality or organization) the parsed organizational
   unit or locality is deemed to be the ascendant of consecutive
   (unparsed) organizational units or localities.

   When parsing an RFC 2247 subject name from the most significant
   component (i.e., the 'dc' entry that represents the country, locality
   or organization) the parsed 'dc' entry is deemed to be the ascendant
   of consecutive (unparsed) 'dc' entries.

   For example, a domain signing authority acting on behalf of John Doe
   of the Acme corporation, whose distinguished name is 'cn=John Doe,
   ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is
   [e-mail], could have a certificate
   containing a distinguished name of 'cn=domain-signing-
   authority,ou=defence,o=acme,c=us' and an RFC 822 address of 'domain-
   [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'.

   Any message received where the domain part of the domain signing
   agent's name does not match, or is not an ascendant of, the
   originator's domain name MUST be flagged.

   This naming rule prevents agents from one organization masquerading
   as domain signing authorities on behalf of another.  For the other
   types of signature defined in this document, no such named mapping
   rule is defined.

   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 secure exchange of messages.

   On verifying the signature, a receiving agent MUST ensure that the
   naming convention has been adhered to.  Any message that violates the
   convention MUST be flagged.



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


3.1.2 Signature Type Attribute

   An S/MIME signed attribute is used to indicate the type of signature.
   This should be used in conjunction with the naming conventions
   specified in the previous section.  When an S/MIME signed message
   containing the signature type attribute is received it triggers the
   software to verify that the correct naming convention has been used.

   The ASN.1 [4] notation of this attribute is: -

      SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

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

      -- signature type identifier

   If present, the SignatureType attribute MUST be a signed attribute,
   as defined in [5].  If the SignatureType attribute is absent and
   there are no further encapsulated signatures the recipient SHOULD
   assume that the signature is that of the message originator.

   All of the signatures defined here are generated and processed as
   described in [5].  They are distinguished by the presence of the
   following values in the SignatureType signed attribute:

      id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
      -- domain signature.

      id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
      -- additional attributes signature.

      id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
      -- review signature.

   For completeness, an attribute type is also specified for an
   originator signature.  However, this signature type is optional.  It
   is defined as follows:

      id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
      -- originator's signature.

   All signature types, except the originator type, MUST encapsulate
   other signatures.  Note a DOMSEC defined signature could be
   encapsulating an empty signature as defined in section 3.






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


   A SignerInfo MUST NOT include multiple instances of SignatureType.  A
   signed attribute representing a SignatureType MAY include multiple
   instances of different SignatureType values as an AttributeValue of
   attrValues [5], as long as the SignatureType 'additional attributes'
   is not present.

   If there is more than one SignerInfo in a signerInfos (i.e., when
   different algorithms are used) then the SignatureType attribute in
   all the SignerInfos MUST contain the same content.

   The following sections describe the conditions under which each of
   these types of signature may be generated, and how they are
   processed.

3.2 Domain Signature Generation and Verification

   A 'domain signature' is a proxy signature generated on a user's
   behalf in the user's domain.  The signature MUST adhere to the naming
   conventions in 3.1.1, including the name mapping convention.  A
   'domain signature' on a message authenticates the fact that the
   message has been released from that domain.  Before signing, a
   process generating a 'domain signature' MUST first satisfy itself of
   the authenticity of the message originator.  This is achieved by one
   of two methods.  Either the 'originator's signature' is checked, if
   S/MIME signatures are used inside a domain.  Or if not, some
   mechanism external to S/MIME is used, such as the physical address of
   the originating client or an authenticated IP link.

   If the originator's authenticity is successfully verified by one of
   the above methods and all other signatures present are valid,
   including those that have been encrypted, a 'domain signature' can be
   added to a message.

   If a 'domain signature' is added and the message is received by a
   Mail List Agent (MLA) there is a possibility that the 'domain
   signature' will be removed.  To stop the 'domain signature' from
   being removed the steps in section 5 MUST be followed.

   An entity generating a domain signature MUST do so using a
   certificate containing a subject name that follows the naming
   convention specified in 3.1.1.

   If the originator's authenticity is not successfully verified or all
   the signatures present are not valid, a 'domain signature' MUST NOT
   be generated.






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


   On reception, the 'domain signature' SHOULD be used to verify the
   authenticity of a message.  A check MUST be made to ensure that both
   the naming convention and the name mapping convention have been used
   as specified in this standard.

   A recipient can assume that successful verification of the domain
   signature also authenticates the message originator.

   If there is an originator signature present, the name in that
   certificate SHOULD be used to identify the originator.  This
   information can then be displayed to the recipient.

   If there is no originator signature present, the only assumption that
   can be made is the domain the message originated from.

   A domain signer can be assumed to have verified any signatures that
   it encapsulates.  Therefore, it is not necessary to verify these
   signatures before treating the message as authentic.  However, this
   standard does not preclude a recipient from attempting to verify any
   other signatures that are present.

   The 'domain signature' is indicated by the presence of the value id-
   sti-domainSig in a 'signature type' signed attribute.

   There MAY be one or more 'domain signature' signatures in an S/MIME
   encoding.

3.3 Additional Attributes Signature Generation and Verification

   The 'additional attributes' signature type indicates that the
   SignerInfo contains additional attributes that are associated with
   the message.

   All attributes in the applicable SignerInfo MUST be treated as
   additional attributes.  Successful verification of an 'additional
   attributes' signature means only that the attributes are
   authentically bound to the message.  A recipient MUST NOT assume that
   its successful verification also authenticates the message
   originator.

   An entity generating an 'additional attributes' signature MUST do so
   using a certificate containing a subject name that follows the naming
   convention specified in 3.1.1.  On reception, a check MUST be made to
   ensure that the naming convention has been used.







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


   A signer MAY include any of the attributes listed in [3] or in this
   document when generating an 'additional attributes' signature.  The
   following attributes have a special meaning, when present in an
   'additional attributes' signature:

   1) Equivalent Label: label values in this attribute are to be treated
      as equivalent to the security label contained in an encapsulated
      SignerInfo, if present.

   2) Security Label: the label value indicates the aggregate
      sensitivity of the inner message content plus any encapsulated
      signedData and envelopedData containers.  The label on the
      original data is indicated by the value in the originator's
      signature, if present.

   An 'additional attributes' signature is indicated by the presence of
   the value id-sti-addAttribSig in a 'signature type' signed attribute.
   Other Object Identifiers MUST NOT be included in the sequence of OIDs
   if this value is present.

   There MAY be multiple 'additional attributes' signatures in an S/MIME
   encoding.

3.4 Review Signature Generation and Verification

   The review signature indicates that the signer has reviewed the
   message.  Successful verification of a review signature means only
   that the signer has approved the message for onward transmission to
   the recipient(s).  When the recipient is in another domain, a device
   on a domain boundary such as a Mail Guard or firewall may be
   configured to check review signatures.  A recipient MUST NOT assume
   that its successful verification also authenticates the message
   originator.

   An entity generating a signed review signature MUST do so using a
   certificate containing a subject name that follows the naming
   convention specified in 3.1.1.  On reception, a check MUST be made to
   ensure that the naming convention has been used.

   A review signature is indicated by the presence of the value id-sti-
   reviewSig in a 'signature type' signed attribute.

   There MAY be multiple review signatures in an S/MIME encoding.








Dean & Ottaway                Experimental                     [Page 12]