rfc3183.txt

RFC 的详细文档！

RFC 3183         Domain Security Services using S/MIME      October 2001


   1) A message (S1 (Original Content)) (where S = signedData) in which
      the signedData does not include an mlExpansionHistory attribute is
      to have a 'domain signature' applied.  The signedData, S1, is
      verified.  No "outer" signedData is found, after searching for one
      as defined above, since the original content is found, nor is an
      envelopedData or a mlExpansionHistory attribute found.  A new
      signedData layer, S2, is created that contains a 'domain
      signature', resulting in the following message sent out of the
      domain (S2 (S1 (Original Content))).

   2) A message (S3 (S2 (S1 (Original Content))) in which none of the
      signedData layers includes an mlExpansionHistory attribute is to
      have a 'domain signature' applied.  The signedData objects S1, S2
      and S3 are verified.  There is not an original, "outer" signedData
      layer since the original content is found, nor is an envelopedData
      or a mlExpansionHistory attribute found.  A new signedData layer,
      S4, is created that contains a 'domain signature', resulting in
      the following message sent out of the domain (S4 (S3 (S2 (S1
      (Original Content))).

   3) A message (E1 (S1 (Original Content))) (where E = envelopedData)
      in which S1 does not include a mlExpansionHistory attribute is to
      have a 'domain signature' applied.  There is not an original,
      received "outer" signedData layer since the envelopedData, E1, is
      found at the outer layer.  The encryptedContent is decrypted.  The
      signedData, S1, is verified.  The decrypted content is wrapped in
      a new signedData layer, S2, which contains a 'domain signature'.
      If local policy requires the message to be encrypted, using S/MIME
      encryption, before it leaves the domain then this new message is
      wrapped in an envelopedData layer, E2, resulting in the following
      message sent out of the domain (E2 (S2 (S1 (Original Content)))),
      else the message is not wrapped in an envelopedData layer
      resulting in the following message (S2 (S1 (Original Content)))
      being sent.

   4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a
      mlExpansionHistory attribute is to have a 'domain signature'
      applied.  The signedData object S2 is verified.  The
      mlExpansionHistory attribute is found in S2, so S2 is the "outer"
      signedData.  The signed attributes in S2 are remembered for later
      inclusion in the new outer signedData that is applied to the
      message.  S2 is stripped off and the message is decrypted.  The
      signedData object S1 is verified.  The decrypted message is
      wrapped in a signedData layer, S3, which contains a 'domain
      signature'.  If local policy requires the message to be encrypted,
      using S/MIME encryption, before it leaves the domain then this new
      message is wrapped in an envelopedData layer, E2.  A new
      signedData layer, S4, is then wrapped around the envelopedData,



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


      E2, resulting in the following message sent out of the domain (S4
      (E2 (S3 (S1 (Original Content))))).  If local policy does not
      require the message to be encrypted, using S/MIME encryption,
      before it leaves the domain then the message is not wrapped in an
      envelopedData layer but is wrapped in a new signedData layer, S4,
      resulting in the following message sent out of the domain (S4 (S3
      (S1 (Original Content).  The signedData S4, in both cases,
      contains the signed attributes from S2.

   5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of
      the signedData layers include a mlExpansionHistory attribute is to
      have a 'domain signature' applied.  The signedData objects S3 and
      S2 are verified.  When the envelopedData E1 is found the
      signedData objects S3 and S2 are stripped off.  The
      encryptedContent is decrypted.  The signedData object S1 is
      verified.  The decrypted content is wrapped in a new signedData
      layer, S4, which contains a 'domain signature'.  If local policy
      requires the message to be encrypted, using S/MIME encryption,
      before it leaves the domain then this new message is wrapped in an
      envelopedData layer, E2, resulting in the following message sent
      out of the domain (E2 (S4 (S1 (Original Content)))), else the
      message is not wrapped in an envelopedData layer resulting in the
      following message (S4 (S1 (Original Content))) being sent.

   6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3
      includes a mlExpansionHistory attribute is to have a 'domain
      signature' applied.  The signedData objects S3 and S2 are
      verified.  The mlExpansionHistory attribute is found in S3, so S3
      is the "outer" signedData.  The signed attributes in S3 are
      remembered for later inclusion in the new  outer signedData that
      is applied to the message.  The signedData object S3 is stripped
      off.  When the envelopedData layer, E1, is found the signedData
      object S2 is stripped off.  The encryptedContent is decrypted.
      The signedData object S1 is verified.  The decrypted content is
      wrapped in a new signedData layer, S4, which contains a 'domain
      signature'.  If local policy requires the message to be encrypted,
      using S/MIME encryption, before it leaves the domain then this new
      message is wrapped in an envelopedData layer, E2.  A new
      signedData layer, S5, is then wrapped around the envelopedData,
      E2, resulting in the following message sent out of the domain (S5
      (E2 (S4 (S1 (Original Content))))).  If local policy does not
      require the message to be encrypted, using S/MIME encryption,
      before it leaves the domain then the message is not wrapped in an
      envelopedData layer but is wrapped in a new signedData layer, S5,
      resulting in the following message sent out of the domain (S5 (S4
      (S1 (Original Content).  The signedData S5, in both cases,
      contains the signed attributes from S3.




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


   7) A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3
      does not include a mlExpansionHistory attribute is to have a
      'domain signature' applied.  The signedData object S3 is verified.
      When the envelopedData E2 is found the signedData object S3 is
      stripped off.  The encryptedContent is decrypted.  The signedData
      object S2 is verified, the envelopedData E1 is decrypted and the
      signedData object S1 is verified.  The signedData object S2 is
      wrapped in a new signedData layer S4, which contains a 'domain
      signature'.  Since there is an envelopedData E1 lower down in the
      message, the new message is wrapped in an envelopedData layer, E3,
      resulting in the following message sent out of the domain (E3 (S4
      (S2 (E1 (S1 (Original Content)))))).

6. Security Considerations

   This specification relies on the existence of several well known
   names, such as domain-confidentiality-authority.  Organizations must
   take care with these names, even if they do not support DOMSEC, so
   that certificates issued in these names are only issued to legitimate
   entities.  If this is not true then an individual could get a
   certificate associated with [e-mail]
   and as a result might be able to read messages the a DOMSEC client
   intended for others.

   Implementations MUST protect all private keys.  Compromise of the
   signer's private key permits masquerade.

   Similarly, compromise of the content-encryption key may result in
   disclosure of the encrypted content.

   Compromise of key material is regarded as an even more serious issue
   for domain security services than for an S/MIME client.  This is
   because compromise of the private key may in turn compromise the
   security of a whole domain.  Therefore, great care should be used
   when considering its protection.

   Domain encryption alone is not secure and should be used in
   conjunction with a domain signature to avoid a masquerade attack,
   where an attacker that has obtained a DCA certificate can fake a
   message to that domain pretending to be another domain.

   When an encrypted DOMSEC message is sent to an end user in such a way
   that the message is decrypted by the end users DCA the message will
   be in plain text and therefore confidentiality could be compromised.







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


   If the recipient's DCA is compromised then the recipient can not
   guarantee the integrity of the message.  Furthermore, even if the
   recipient's DCA correctly verifies a message's signatures, then a
   message could be undetectably modified, when there are no signatures
   on a message that the recipient can verify.

7. DOMSEC ASN.1 Module

   DOMSECSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }

    DEFINITIONS IMPLICIT TAGS ::=
    BEGIN

    -- EXPORTS All
    -- The types and values defined in this module are exported for
    -- use in the other ASN.1 modules.  Other applications may use
    -- them for their own purposes.

    SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

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

    id-sti  OBJECT IDENTIFIER ::= { id-smime 9 }   -- signature type
    identifier

    -- Signature Type Identifiers

    id-sti-originatorSig       OBJECT IDENTIFIER ::= { id-sti 1 }
    id-sti-domainSig           OBJECT IDENTIFIER ::= { id-sti 2 }
    id-sti-addAttribSig        OBJECT IDENTIFIER ::= { id-sti 3 }
    id-sti-reviewSig           OBJECT IDENTIFIER ::= { id-sti 4 }

    END -- of DOMSECSyntax















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


8. References

   [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633,
       June 1999.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
       June 1999.

   [4] International Telecommunications Union, Recommendation X.208,
       "Open systems interconnection: specification of Abstract Syntax
       Notation (ASN.1)", CCITT Blue Book, 1989.

   [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

9. Authors' Addresses

   Tim Dean
   QinetiQ
   St. Andrews Road
   Malvern
   Worcs
   WR14 3PS

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

   William Ottaway
   QinetiQ
   St. Andrews Road
   Malvern
   Worcs
   WR14 3PS

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]











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


10.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Dean & Ottaway                Experimental                     [Page 24]