rfc3185.txt

RFC 的详细文档！


RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


   The optional to implement KEKDerivationAlgorithm attribute MUST only
   be present when MSG1.content-encryption algorithm differs from
   MSG2.key-encryption algorithm, in which case it MUST be present.
   Implementations that recognize this attribute, but do not support the
   functionality SHOULD ignore the attribute.

   Ignoring attributes as discussed above, will lead to decryption
   failures.  CMS implementations SHOULD be able to signal the
   particular reason for this failure to the calling application.

6. Security Considerations

   Encryption does not provide authentication, for example, if the
   encryptedContent is essentially random then recipients MUST NOT
   assume that "knowing" a CEKReference value proves anything - anyone
   could have created the EnvelopedData.  This is relevant both for
   security (the recovered plaintext should not be entirely random) and
   for avoiding denial of service (the recipient MUST NOT assume that
   using the right CEKReference means that message originator is
   genuine).

   Similarly, using the correct CEKReference does not mean that a
   message has not been replayed or inserted, and recipients MUST NOT
   assume that replay has been avoided.

   The maxDecrypts field presents a potential denial-of-service attack
   if a very large value is included by an originator in an attempt to
   get a recipient to consume memory by storing the referenced CEKs for
   a long period or if the originator never sends the indicated number
   of ciphertexts.  Recipients SHOULD therefore drop referenced CEKs
   where the maxDecrypts value is too large (according to local
   configuration) or the referenced CEK has been held for too long a
   period.

   Suppose MSG1 is sent to a set S1 of users.  In the case where MSG2 is
   sent to only a subset of users in S1, all users from S1 will still be
   able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).
   Implementers should be aware that in such cases, all members of the
   original set of recipients (S1) can access the plaintext of MSG2 and
   subsequent messages.

   The reason for the byte reversal is as follows: without the byte
   reversal, an attacker knowing some of MSG1.plaintext (a prefix in a
   field for instance) can use the corresponding ciphertext block as the
   next encrypted CEK, i.e., as MSG2.KEKRecipientInfo.encryptedKey.  Now
   the attacker knows the next CEK.  This attacks something this note is
   not claiming to protect (origin authentication), but is easily
   avoided using the byte reversal.  Byte-reversal was chosen over bit-



Farrell & Turner            Standards Track                     [Page 6]

RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


   reversal since bit-reversal would cause parity bits from MSG1.CEK to
   be used as keying bits for MSG2.KEK for DES-based algorithms.  Note
   that byte reversal would similarly affect parity if parity checks
   spanned more than one octet, however no well-known algorithms operate
   in this way.

   Implementations should be very careful with this scheme if MSG[n].KEK
   is used to derive MSG[n].CEK, e.g., if MSG[n].CEK were the byte-
   reversal of MSG[n].KEK, then this scheme could result in a fixed key
   being unexpectedly used.

7. References

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

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

   [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
             Specification Version 2.0", RFC 2898, September 2000.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

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

Authors' Addresses

   Stephen Farrell,
   Baltimore Technologies,
   39 Parkgate Street,
   Dublin 8
   IRELAND

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


   Sean Turner
   IECA, Inc.
   9010 Edgepark Road
   Vienna, VA 22182
   USA

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



Farrell & Turner            Standards Track                     [Page 7]

RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


Appendix A: ASN.1 Module

   SMIMERcek
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        smime(16) modules(0) rcek(13) }

     -- This module contains the definitions of the attributes
     -- used for re-using the content encryption key from a
     -- message in further messages.

     DEFINITIONS IMPLICIT TAGS ::=

     BEGIN
     -- EXPORTS ALL --

     IMPORTS

       AlgorithmIdentifier FROM
            AuthenticationFramework { joint-iso-itu-t ds(5)
                  module(1) authenticationFramework(7) 3 } ;

       -- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params.  Since
       -- this specification only uses 1988 ASN.1, the definition is
       -- repeated here for completeness.

       -- The DEFAULT prf field value, MUST be used for this
       -- specification
       digestAlgorithm OBJECT IDENTIFIER ::=
            { iso(1) member-body(2) us(840) rsadsi(113549) 2}
       id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}

       -- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which
       -- results in the same encoding as produced by the definition
       -- below.  See [RFC2898] for that definition.

       PBKDF2-params ::= SEQUENCE {
         salt CHOICE {
             specified OCTET STRING, -- MUST BE USED
             otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
         },
         iterationCount INTEGER (1..MAX),
         keyLength INTEGER (1..MAX) OPTIONAL
       }

        -- id-aa is the arc with all new authenticated and
        -- unauthenticated attributes produced the by S/MIME
        -- Working Group.  It is also defined in [CMS-MSG]




Farrell & Turner            Standards Track                     [Page 8]

RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


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

        -- This attribute contains what will be the key identifier
        -- for subsequent messages
        id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
        CEKReference ::= OCTET STRING

        -- This attribute contains a "hint" to the recipient
        -- indicating how many times the originator will use
        -- the re-used CEK
        id-aa-CEKMaxDecrypts      OBJECT IDENTIFIER ::= { id-aa 31 }
        CEKMaxDecrypts ::= INTEGER

        -- This attribute specifies the key derivation function
        -- to be used when the default byte reversal operation cannot
        -- be used.

        id-aa-KEKDerivationAlg     OBJECT IDENTIFIER ::= { id-aa 32 }
        KEKDerivationAlgorithm ::= SEQUENCE {
            kekAlg          AlgorithmIdentifier,
            pbkdf2Param     PBKDF2-params }


     END

























Farrell & Turner            Standards Track                     [Page 9]

RFC 3185          Reuse of CMS Content Encryption Keys      October 2001


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.



















Farrell & Turner            Standards Track                    [Page 10]