rfc3279.txt

PKIX的RFC英文文档

   -- recognized field type OIDs are defined in the following arc

   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

   -- where fieldType is prime-field, the parameters are of type Prime-p

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

   Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime

   -- where fieldType is characteristic-two-field, the parameters are
   -- of type Characteristic-two

   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

   Characteristic-two ::= SEQUENCE {
      m           INTEGER,                   -- Field size 2^m
      basis       OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY basis }

   -- recognized basis type OIDs are defined in the following arc

   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
        characteristic-two-field basisType(3) }

   -- gnbasis is identified by OID gnBasis and indicates
   -- parameters are NULL

   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

   -- parameters for this basis are NULL

   -- trinomial basis is identified by OID tpBasis and indicates
   -- parameters of type Pentanomial

   tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }




Polk, et al.                Standards Track                    [Page 21]

RFC 3279               Algorithms and Identifiers             April 2002


   -- Trinomial basis representation of F2^m
   -- Integer k for reduction polynomial xm + xk + 1

   Trinomial ::= INTEGER

   -- for pentanomial basis is identified by OID ppBasis and indicates
   -- parameters of type Pentanomial

   ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

   -- Pentanomial basis representation of F2^m
   -- reduction polynomial integers k1, k2, k3
   -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1

   Pentanomial ::= SEQUENCE {
      k1  INTEGER,
      k2  INTEGER,
      k3  INTEGER }

   -- The object identifiers gnBasis, tpBasis and ppBasis name
   -- three kinds of basis for characteristic-two finite fields

   FieldElement ::= OCTET STRING             -- Finite field element

   ECPoint  ::= OCTET STRING                 -- Elliptic curve point

   -- Elliptic Curve parameters may be specified explicitly,
   -- specified implicitly through a "named curve", or
   -- inherited from the CA

   EcpkParameters ::= CHOICE {
      ecParameters  ECParameters,
      namedCurve    OBJECT IDENTIFIER,
      implicitlyCA  NULL }

   ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
      version   ECPVer,
      fieldID   FieldID,
      curve     Curve,
      base      ECPoint,                -- Base point G
      order     INTEGER,                -- Order n of the base point
      cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n

   ECPVer ::= INTEGER {ecpVer1(1)}







Polk, et al.                Standards Track                    [Page 22]

RFC 3279               Algorithms and Identifiers             April 2002


   Curve  ::= SEQUENCE {
      a     FieldElement,            -- Elliptic curve coefficient a
      b     FieldElement,            -- Elliptic curve coefficient b
      seed  BIT STRING  OPTIONAL }

   id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }

   id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

   -- Named Elliptic Curves in ANSI X9.62.

   ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }

   c-TwoCurve OBJECT IDENTIFIER ::= {
        ellipticCurve characteristicTwo(0) }

   c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
   c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
   c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
   c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
   c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
   c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
   c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
   c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
   c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
   c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
   c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
   c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
   c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
   c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
   c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
   c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
   c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
   c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
   c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
   c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }

   primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }

   prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
   prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
   prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
   prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
   prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
   prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
   prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }

   END



Polk, et al.                Standards Track                    [Page 23]

RFC 3279               Algorithms and Identifiers             April 2002


4  References

   [FIPS 180-1]   Federal Information Processing Standards Publication
                  (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
                  [Supersedes FIPS PUB 180 dated 11 May 1993.]

   [FIPS 186-2]   Federal Information Processing Standards Publication
                  (FIPS PUB) 186, Digital Signature Standard, 27 January
                  2000. [Supersedes FIPS PUB 186-1 dated 15 December
                  1998.]

   [P1363]        IEEE P1363, "Standard Specifications for Public-Key
                  Cryptography", 2001.

   [RC95]         Rogier, N. and Chauvaud, P., "The compression function
                  of MD2 is not collision free," Presented at Selected
                  Areas in Cryptography '95, May 1995.

   [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
                  Facilities", STD 13, RFC 1034, November 1987.

   [RFC 1319]     Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
                  1319, April 1992.

   [RFC 1321]     Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                  1321, April 1992.

   [RFC 1422]     Kent, S., "Privacy Enhancement for Internet Electronic
                  Mail: Part II: Certificate-Based Key Management", RFC
                  1422, February 1993.

   [RFC 1423]     Balenson, D., "Privacy Enhancement for Internet
                  Electronic Mail: Part III: Algorithms, Modes, and
                  Identifiers", RFC 1423, February 1993.

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

   [RFC 2313]     Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
                  RFC 2313, March 1998.

   [RFC 2459]     Housley, R., Ford, W., Polk, W. and D. Solo "Internet
                  X.509 Public Key Infrastructure: Certificate and CRL
                  Profile", RFC 2459, January, 1999.

   [RFC 3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
                  (SHA1)", RFC 3174, September 2001.




Polk, et al.                Standards Track                    [Page 24]

RFC 3279               Algorithms and Identifiers             April 2002


   [RFC 3280]     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.

   [SDN.701r]     SDN.701, "Message Security Protocol 4.0", Revision A
                  1997-02-06.

   [X.208]        CCITT Recommendation X.208: Specification of Abstract
                  Syntax Notation One (ASN.1), 1988.

   [X.660]        ITU-T Recommendation X.660 Information Technology -
                  ASN.1 encoding rules: Specification of Basic Encoding
                  Rules (BER), Canonical Encoding Rules (CER) and
                  Distinguished Encoding Rules (DER), 1997.

   [X9.42]        ANSI X9.42-2000, "Public Key Cryptography for The
                  Financial Services Industry: Agreement of Symmetric
                  Keys Using Discrete Logarithm Cryptography", December,
                  1999.

   [X9.62]        X9.62-1998, "Public Key Cryptography For The Financial
                  Services Industry: The Elliptic Curve Digital
                  Signature Algorithm (ECDSA)", January 7, 1999.

   [X9.63]        ANSI X9.63-2001, "Public Key Cryptography For The
                  Financial Services Industry: Key Agreement and Key
                  Transport Using Elliptic Curve Cryptography", Work in
                  Progress.

5  Security Considerations

   This specification does not constrain the size of public keys or
   their parameters for use in the Internet PKI.  However, the key size
   selected impacts the strength achieved when implementing
   cryptographic services.  Selection of appropriate key sizes is
   critical to implementing appropriate security.

   This specification does not identify particular elliptic curves for
   use in the Internet PKI.  However, the particular curve selected
   impact the strength of the digital signatures.  Some curves are
   cryptographically stronger than others!

   In general, use of "well-known" curves, such as the "named curves"
   from ANSI X9.62, is a sound strategy.  For additional information,
   refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
   Appendix A.1, "Avoiding Cryptographically Weak Keys".




Polk, et al.                Standards Track                    [Page 25]

RFC 3279               Algorithms and Identifiers             April 2002


   This specification supplements RFC 3280.  The security considerations
   section of that document applies to this specification as well.

6  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   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
   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.

7  Author Addresses:

   Tim Polk
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: [e-mail]

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: [e-mail]

   Larry Bassham
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: [e-mail]





Polk, et al.                Standards Track                    [Page 26]

RFC 3279               Algorithms and Identifiers             April 2002


8.  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.



















Polk, et al.                Standards Track                    [Page 27]