rfc3278.txt

RFC 的详细文档！

         s INTEGER }

   ECDSA-Sig-Value is specified in [X9.62].  Within CMS, ECDSA-Sig-Value
   is DER-encoded and placed within a signature field of SignedData.

   When using ECDH and ECMQV with EnvelopedData and AuthenticatedData,
   ephemeral and static public keys are encoded using the type ECPoint.

      ECPoint ::= OCTET STRING

   When using ECMQV with EnvelopedData and AuthenticatedData, the
   sending agent's ephemeral public key and additional keying material
   are encoded using the type:




Blake-Wilson, et al.         Informational                     [Page 11]

RFC 3278              Use of ECC Algorithms in CMS            April 2002


      MQVuserKeyingMaterial ::= SEQUENCE {
         ephemeralPublicKey OriginatorPublicKey,
         addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL  }

   The ECPoint syntax in used to represent the ephemeral public key and
   placed in the ephemeralPublicKey field.  The additional user keying
   material is placed in the addedukm field.  Then the
   MQVuserKeyingMaterial value is DER-encoded and placed within a ukm
   field of EnvelopedData or AuthenticatedData.

   When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, the
   key-encryption keys are derived by using the type:

      ECC-CMS-SharedInfo ::= SEQUENCE {
         keyInfo AlgorithmIdentifier,
         entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
         suppPubInfo [2] EXPLICIT OCTET STRING   }

   The fields of ECC-CMS-SharedInfo are as follows:

      keyInfo contains the object identifier of the key-encryption
      algorithm (used to wrap the CEK) and NULL parameters.

      entityUInfo optionally contains additional keying material
      supplied by the sending agent.  When used with ECDH and CMS, the
      entityUInfo field contains the octet string ukm.  When used with
      ECMQV and CMS, the entityUInfo contains the octet string addedukm
      (encoded in MQVuserKeyingMaterial).

      suppPubInfo contains the length of the generated KEK, in bits,
      represented as a 32 bit number, as in [CMS-DH].  (E.g. for 3DES it
      would be 00 00 00 c0.)

   Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to
   the key derivation function, as specified in [SEC1, Section 3.6.1].
   Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in
   [CMS-DH].  Here, a counter value is not included in the keyInfo field
   because the key derivation function specified in [SEC1, Section
   3.6.1] ensures that sufficient keying data is provided.

9  Summary

   This document specifies how to use ECC algorithms with the S/MIME
   CMS.  Use of ECC algorithm within CMS can result in reduced
   processing requirements for S/MIME agents, and reduced bandwidth for
   CMS messages.





Blake-Wilson, et al.         Informational                     [Page 12]

RFC 3278              Use of ECC Algorithms in CMS            April 2002


References

   [X9.62]      ANSI X9.62-1998, "Public Key Cryptography For The
                Financial Services Industry: The Elliptic Curve Digital
                Signature Algorithm (ECDSA)", American National
                Standards Institute, 1999.

   [PKI-ALG]    Bassham, L., Housley R. and W. Polk, "Algorithms and
                Identifiers for the Internet X.509 Public Key
                Infrastructure Certificate and CRL Profile", RFC 3279,
                April 2002.

   [BON]        D. Boneh, "The Security of Multicast MAC", Presentation
                at Selected Areas of Cryptography 2000, Center for
                Applied Cryptographic Research, University of Waterloo,
                2000.  Paper version available from
                http://crypto.stanford.edu/~dabo/papers/mmac.ps

   [MUST]       Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [FIPS-180]   FIPS 180-1, "Secure Hash Standard", National Institute
                of Standards and Technology, April 17, 1995.

   [FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National
                Institute of Standards and Technology, 15 February 2000.

   [PKI]        Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

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

   [IEEE1363]   IEEE P1363, "Standard Specifications for Public Key
                Cryptography", Institute of Electrical and Electronics
                Engineers, 2000.

   [K]          B. Kaliski, "MQV Vulnerabilty", Posting to ANSI X9F1 and
                IEEE P1363 newsgroups, 1998.

   [LMQSV]      L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
                "An efficient protocol for authenticated key agreement",
                Technical report CORR 98-05, University of Waterloo,
                1998.





Blake-Wilson, et al.         Informational                     [Page 13]

RFC 3278              Use of ECC Algorithms in CMS            April 2002


   [CMS-KEA]    Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC
                2876, July 2000.

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

   [CMS-DH]     Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
                2631, June 1999.

   [SEC1]       SECG, "Elliptic Curve Cryptography", Standards for
                Efficient Cryptography Group, 2000. Available from
                www.secg.org/collateral/sec1.pdf.

   [SEC2]       SECG, "Recommended Elliptic Curve Domain Parameters",
                Standards for Efficient Cryptography Group, 2000.
                Available from www.secg.org/collateral/sec2.pdf.

Security Considerations

   This specification is based on [CMS], [X9.62] and [SEC1] and the
   appropriate security considerations of those documents apply.

   In addition, implementors of AuthenticatedData should be aware of the
   concerns expressed in [BON] when using AuthenticatedData to send
   messages to more than one recipient.  Also, users of MQV should be
   aware of the vulnerability in [K].

   When 256, 384, and 512 bit hash functions succeed SHA-1 in future
   revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they can
   similarly succeed SHA-1 in a future revision of this document.

Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to the specification contained in this document.  For more
   information, consult the online list of claimed rights
   (http://www.ietf.org/ipr.html).

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to



Blake-Wilson, et al.         Informational                     [Page 14]

RFC 3278              Use of ECC Algorithms in CMS            April 2002


   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

Acknowledgments

   The methods described in this document are based on work done by the
   ANSI X9F1 working group.  The authors wish to extend their thanks to
   ANSI X9F1 for their assistance.  The authors also wish to thank Peter
   de Rooij for his patient assistance.  The technical comments of
   Francois Rousseau were valuable contributions.

Authors' Addresses

   Simon Blake-Wilson
   Certicom Corp
   5520 Explorer Drive #400
   Mississauga, ON L4W 5L1

   EMail: [e-mail]


   Daniel R. L. Brown
   pCerticom Corp
   5520 Explorer Drive #400
   Mississauga, ON L4W 5L1

   EMail: [e-mail]


   Paul Lambert

   EMail: [e-mail]


















Blake-Wilson, et al.         Informational                     [Page 15]

RFC 3278              Use of ECC Algorithms in CMS            April 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Blake-Wilson, et al.         Informational                     [Page 16]