doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc3279.txt b/doc/rfc/rfc3279.txt
new file mode 100644
index 0000000..04e7b07
--- /dev/null
+++ b/doc/rfc/rfc3279.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                            W. Polk
+Request for Comments: 3279                                          NIST
+Obsoletes: 2528                                               R. Housley
+Category: Standards Track                               RSA Laboratories
+                                                              L. Bassham
+                                                                    NIST
+                                                              April 2002
+
+                   Algorithms and Identifiers for the
+                Internet X.509 Public Key Infrastructure
+       Certificate and Certificate Revocation List (CRL) Profile
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document specifies algorithm identifiers and ASN.1 encoding
+   formats for digital signatures and subject public keys used in the
+   Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
+   are used to sign certificates and certificate revocation list (CRLs).
+   Certificates include the public key of the named subject.
+
+Table of Contents
+
+   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
+   2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
+   2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
+   2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
+   2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
+   2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
+   2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
+   2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
+   2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
+   2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
+   2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
+   2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
+   2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
+   2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10
+
+
+
+Polk, et al.                Standards Track                     [Page 1]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
+   2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
+   3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
+   4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
+   5  Security Considerations . . . . . . . . . . . . . . . . .  25
+   6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
+   7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
+   8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27
+
+1  Introduction
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+   This document specifies algorithm identifiers and ASN.1 [X.660]
+   encoding formats for digital signatures and subject public keys used
+   in the Internet X.509 Public Key Infrastructure (PKI).  This
+   specification supplements [RFC 3280], "Internet X.509 Public Key
+   Infrastructure:  Certificate and Certificate Revocation List (CRL)
+   Profile."  Implementations of this specification MUST also conform to
+   RFC 3280.
+
+   This specification defines the contents of the signatureAlgorithm,
+   signatureValue, signature, and subjectPublicKeyInfo fields within
+   Internet X.509 certificates and CRLs.
+
+   This document identifies one-way hash functions for use in the
+   generation of digital signatures.  These algorithms are used in
+   conjunction with digital signature algorithms.
+
+   This specification describes the encoding of digital signatures
+   generated with the following cryptographic algorithms:
+
+      * Rivest-Shamir-Adelman (RSA);
+      * Digital Signature Algorithm (DSA); and
+      * Elliptic Curve Digital Signature Algorithm (ECDSA).
+
+   This document specifies the contents of the subjectPublicKeyInfo
+   field in Internet X.509 certificates.  For each algorithm, the
+   appropriate alternatives for the the keyUsage extension are provided.
+   This specification describes encoding formats for public keys used
+   with the following cryptographic algorithms:
+
+      * Rivest-Shamir-Adelman (RSA);
+      * Digital Signature Algorithm (DSA);
+      * Diffie-Hellman (DH);
+      * Key Encryption Algorithm (KEA);
+
+
+
+Polk, et al.                Standards Track                     [Page 2]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+      * Elliptic Curve Digital Signature Algorithm (ECDSA); and
+      * Elliptic Curve Diffie-Hellman (ECDH).
+
+2  Algorithm Support
+
+   This section describes cryptographic algorithms which may be used
+   with the Internet X.509 certificate and CRL profile [RFC 3280].  This
+   section describes one-way hash functions and digital signature
+   algorithms which may be used to sign certificates and CRLs, and
+   identifies object identifiers (OIDs) for public keys contained in a
+   certificate.
+
+   Conforming CAs and applications MUST, at a minimum, support digital
+   signatures and public keys for one of the specified algorithms.  When
+   using any of the algorithms identified in this specification,
+   conforming CAs and applications MUST support them as described.
+
+2.1  One-way Hash Functions
+
+   This section identifies one-way hash functions for use in the
+   Internet X.509 PKI.  One-way hash functions are also called message
+   digest algorithms.  SHA-1 is the preferred one-way hash function for
+   the Internet X.509 PKI.  However, PEM uses MD2 for certificates [RFC
+   1422] [RFC 1423] and MD5 is used in other legacy applications.  For
+   these reasons, MD2 and MD5 are included in this profile.  The data
+   that is hashed for certificate and CRL signing is fully described in
+   [RFC 3280].
+
+2.1.1  MD2 One-way Hash Function
+
+   MD2 was developed by Ron Rivest for RSA Security.  RSA Security has
+   recently placed the MD2 algorithm in the public domain.  Previously,
+   RSA Data Security had granted license for use of MD2 for non-
+   commercial Internet Privacy-Enhanced Mail (PEM).  MD2 may continue to
+   be used with PEM certificates, but SHA-1 is preferred.  MD2 produces
+   a 128-bit "hash" of the input.  MD2 is fully described in [RFC 1319].
+
+   At the Selected Areas in Cryptography '95 conference in May 1995,
+   Rogier and Chauvaud presented an attack on MD2 that can nearly find
+   collisions [RC95].  Collisions occur when one can find two different
+   messages that generate the same message digest.  A checksum operation
+   in MD2 is the only remaining obstacle to the success of the attack.
+   For this reason, the use of MD2 for new applications is discouraged.
+   It is still reasonable to use MD2 to verify existing signatures, as
+   the ability to find collisions in MD2 does not enable an attacker to
+   find new messages having a previously computed hash value.
+
+
+
+
+
+Polk, et al.                Standards Track                     [Page 3]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+2.1.2  MD5 One-way Hash Function
+
+   MD5 was developed by Ron Rivest for RSA Security.  RSA Security has
+   placed the MD5 algorithm in the public domain.  MD5 produces a 128-
+   bit "hash" of the input.  MD5 is fully described in [RFC 1321].
+
+   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
+   but there are no other known cryptanalytic results.  The use of MD5
+   for new applications is discouraged.  It is still reasonable to use
+   MD5 to verify existing signatures.
+
+2.1.3  SHA-1 One-way Hash Function
+
+   SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
+   "hash" of the input.  SHA-1 is fully described in [FIPS 180-1].  RFC
+   3174 [RFC 3174] also describes SHA-1, and it provides an
+   implementation of the algorithm.
+
+2.2  Signature Algorithms
+
+   Certificates and CRLs conforming to [RFC 3280] may be signed with any
+   public key signature algorithm.  The certificate or CRL indicates the
+   algorithm through an algorithm identifier which appears in the
+   signatureAlgorithm field within the Certificate or CertificateList.
+   This algorithm identifier is an OID and has optionally associated
+   parameters.  This section identifies algorithm identifiers and
+   parameters that MUST be used in the signatureAlgorithm field in a
+   Certificate or CertificateList.
+
+   Signature algorithms are always used in conjunction with a one-way
+   hash function.
+
+   This section identifies OIDS for RSA, DSA, and ECDSA.  The contents
+   of the parameters component for each algorithm vary; details are
+   provided for each algorithm.
+
+   The data to be signed (e.g., the one-way hash function output value)
+   is formatted for the signature algorithm to be used.  Then, a private
+   key operation (e.g., RSA encryption) is performed to generate the
+   signature value.  This signature value is then ASN.1 encoded as a BIT
+   STRING and included in the Certificate or CertificateList in the
+   signature field.
+
+
+
+
+
+
+
+
+
+Polk, et al.                Standards Track                     [Page 4]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+2.2.1  RSA Signature Algorithm
+
+   The RSA algorithm is named for its inventors: Rivest, Shamir, and
+   Adleman.  This profile includes three signature algorithms based on
+   the RSA asymmetric encryption algorithm.  The signature algorithms
+   combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
+   functions.
+
+   The signature algorithm with SHA-1 and the RSA encryption algorithm
+   is implemented using the padding and encoding conventions described
+   in PKCS #1 [RFC 2313].  The message digest is computed using the
+   SHA-1 hash algorithm.
+
+   The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
+   includes a data encoding step.  In this step, the message digest and
+   the OID for the one-way hash function used to compute the digest are
+   combined.  When performing the data encoding step, the md2, md5, and
+   id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
+   hash functions, respectively:
+
+      md2  OBJECT IDENTIFIER ::= {
+           iso(1) member-body(2) US(840) rsadsi(113549)
+           digestAlgorithm(2) 2 }
+
+      md5  OBJECT IDENTIFIER ::= {
+           iso(1) member-body(2) US(840) rsadsi(113549)
+           digestAlgorithm(2) 5 }
+
+      id-sha1  OBJECT IDENTIFIER ::= {
+           iso(1) identified-organization(3) oiw(14) secsig(3)
+           algorithms(2) 26 }
+
+   The signature algorithm with MD2 and the RSA encryption algorithm is
+   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
+   ASN.1 OID used to identify this signature algorithm is:
+
+      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
+          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+          pkcs-1(1) 2  }
+
+   The signature algorithm with MD5 and the RSA encryption algorithm is
+   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
+   ASN.1 OID used to identify this signature algorithm is:
+
+      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
+          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+          pkcs-1(1) 4  }
+
+
+
+
+Polk, et al.                Standards Track                     [Page 5]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   The ASN.1 object identifier used to identify this signature algorithm
+   is:
+
+      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
+          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+          pkcs-1(1) 5  }
+
+   When any of these three OIDs appears within the ASN.1 type
+   AlgorithmIdentifier, the parameters component of that type SHALL be
+   the ASN.1 type NULL.
+
+   The RSA signature generation process and the encoding of the result
+   is described in detail in PKCS #1 [RFC 2313].
+
+2.2.2  DSA Signature Algorithm
+
+   The Digital Signature Algorithm (DSA) is defined in the Digital
+   Signature Standard (DSS).  DSA was developed by the U.S. Government,
+   and DSA is used in conjunction with the SHA-1 one-way hash function.
+   DSA is fully described in [FIPS 186].  The ASN.1 OID used to identify
+   this signature algorithm is:
+
+      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
+           iso(1) member-body(2) us(840) x9-57 (10040)
+           x9cm(4) 3 }
+
+   When the id-dsa-with-sha1 algorithm identifier appears as the
+   algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
+   the parameters field.  That is, the AlgorithmIdentifier SHALL be a
+   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.
+
+   The DSA parameters in the subjectPublicKeyInfo field of the
+   certificate of the issuer SHALL apply to the verification of the
+   signature.
+
+   When signing, the DSA algorithm generates two values.  These values
+   are commonly referred to as r and s.  To easily transfer these two
+   values as one signature, they SHALL be ASN.1 encoded using the
+   following ASN.1 structure:
+
+      Dss-Sig-Value  ::=  SEQUENCE  {
+              r       INTEGER,
+              s       INTEGER  }
+
+
+
+
+
+
+
+
+Polk, et al.                Standards Track                     [Page 6]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+2.2.3 ECDSA Signature Algorithm
+
+   The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
+   [X9.62].  The ASN.1 object identifiers used to identify ECDSA are
+   defined in the following arc:
+
+      ansi-X9-62  OBJECT IDENTIFIER ::= {
+           iso(1) member-body(2) us(840) 10045 }
+
+      id-ecSigType OBJECT IDENTIFIER  ::=  {
+           ansi-X9-62 signatures(4) }
+
+   ECDSA is used in conjunction with the SHA-1 one-way hash function.
+   The ASN.1 object identifier used to identify ECDSA with SHA-1 is:
+
+      ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
+           id-ecSigType 1 }
+
+   When the ecdsa-with-SHA1 algorithm identifier appears as the
+   algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
+   parameters field.  That is, the AlgorithmIdentifier SHALL be a
+   SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.
+
+   The elliptic curve parameters in the subjectPublicKeyInfo field of
+   the certificate of the issuer SHALL apply to the verification of the
+   signature.
+
+   When signing, the ECDSA algorithm generates two values.  These values
+   are commonly referred to as r and s.  To easily transfer these two
+   values as one signature, they MUST be ASN.1 encoded using the
+   following ASN.1 structure:
+
+      Ecdsa-Sig-Value  ::=  SEQUENCE  {
+           r     INTEGER,
+           s     INTEGER  }
+
+2.3  Subject Public Key Algorithms
+
+   Certificates conforming to [RFC 3280] may convey a public key for any
+   public key algorithm.  The certificate indicates the algorithm
+   through an algorithm identifier.  This algorithm identifier is an OID
+   and optionally associated parameters.
+
+   This section identifies preferred OIDs and parameters for the RSA,
+   DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
+   MUST use the identified OIDs when issuing certificates containing
+
+
+
+
+
+Polk, et al.                Standards Track                     [Page 7]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   public keys for these algorithms.  Conforming applications supporting
+   any of these algorithms MUST, at a minimum, recognize the OID
+   identified in this section.
+
+2.3.1  RSA Keys
+
+   The OID rsaEncryption identifies RSA public keys.
+
+      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+                     rsadsi(113549) pkcs(1) 1 }
+
+      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}
+
+   The rsaEncryption OID is intended to be used in the algorithm field
+   of a value of type AlgorithmIdentifier.  The parameters field MUST
+   have ASN.1 type NULL for this algorithm identifier.
+
+   The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:
+
+      RSAPublicKey ::= SEQUENCE {
+         modulus            INTEGER,    -- n
+         publicExponent     INTEGER  }  -- e
+
+   where modulus is the modulus n, and publicExponent is the public
+   exponent e.  The DER encoded RSAPublicKey is the value of the BIT
+   STRING subjectPublicKey.
+
+   This OID is used in public key certificates for both RSA signature
+   keys and RSA encryption keys.  The intended application for the key
+   MAY be indicated in the key usage field (see [RFC 3280]).  The use of
+   a single key for both signature and encryption purposes is not
+   recommended, but is not forbidden.
+
+   If the keyUsage extension is present in an end entity certificate
+   which conveys an RSA public key, any combination of the following
+   values MAY be present:
+
+      digitalSignature;
+      nonRepudiation;
+      keyEncipherment; and
+      dataEncipherment.
+
+   If the keyUsage extension is present in a CA or CRL issuer
+   certificate which conveys an RSA public key, any combination of the
+   following values MAY be present:
+
+      digitalSignature;
+      nonRepudiation;
+
+
+
+Polk, et al.                Standards Track                     [Page 8]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+      keyEncipherment;
+      dataEncipherment;
+      keyCertSign; and
+      cRLSign.
+
+   However, this specification RECOMMENDS that if keyCertSign or cRLSign
+   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
+   present.
+
+2.3.2  DSA Signature Keys
+
+   The Digital Signature Algorithm (DSA) is defined in the Digital
+   Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
+   profile is:
+
+      id-dsa OBJECT IDENTIFIER ::= {
+           iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
+
+   The id-dsa algorithm syntax includes optional domain parameters.
+   These parameters are commonly referred to as p, q, and g.  When
+   omitted, the parameters component MUST be omitted entirely.  That is,
+   the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
+   OBJECT IDENTIFIER id-dsa.
+
+   If the DSA domain parameters are present in the subjectPublicKeyInfo
+   AlgorithmIdentifier, the parameters are included using the following
+   ASN.1 structure:
+
+      Dss-Parms  ::=  SEQUENCE  {
+          p             INTEGER,
+          q             INTEGER,
+          g             INTEGER  }
+
+   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
+   within a certificate where the parameters may be used.  If the DSA
+   algorithm parameters are omitted from the subjectPublicKeyInfo
+   AlgorithmIdentifier and the CA signed the subject certificate using
+   DSA, then the certificate issuer's DSA parameters apply to the
+   subject's DSA key.  If the DSA domain parameters are omitted from the
+   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
+   subject certificate using a signature algorithm other than DSA, then
+   the subject's DSA domain parameters are distributed by other means.
+   If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
+   parameters component, the CA signed the subject with a signature
+   algorithm other than DSA, and the subject's DSA parameters are not
+   available through other means, then clients MUST reject the
+   certificate.
+
+
+
+
+Polk, et al.                Standards Track                     [Page 9]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
+   encoding shall be used as the contents (i.e., the value) of the
+   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
+   data element.
+
+      DSAPublicKey ::= INTEGER -- public key, Y
+
+   If the keyUsage extension is present in an end entity certificate
+   which conveys a DSA public key, any combination of the following
+   values MAY be present:
+
+      digitalSignature;
+      nonRepudiation;
+
+   If the keyUsage extension is present in a CA or CRL issuer
+   certificate which conveys a DSA public key, any combination of the
+   following values MAY be present:
+
+      digitalSignature;
+      nonRepudiation;
+      keyCertSign; and
+      cRLSign.
+
+2.3.3  Diffie-Hellman Key Exchange Keys
+
+   The Diffie-Hellman OID supported by this profile is defined in
+   [X9.42].
+
+      dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+                us(840) ansi-x942(10046) number-type(2) 1 }
+
+   The dhpublicnumber OID is intended to be used in the algorithm field
+   of a value of type AlgorithmIdentifier.  The parameters field of that
+   type, which has the algorithm-specific syntax ANY DEFINED BY
+   algorithm, have the ASN.1 type DomainParameters for this algorithm.
+
+      DomainParameters ::= SEQUENCE {
+            p       INTEGER, -- odd prime, p=jq +1
+            g       INTEGER, -- generator, g
+            q       INTEGER, -- factor of p-1
+            j       INTEGER OPTIONAL, -- subgroup factor
+            validationParms  ValidationParms OPTIONAL }
+
+      ValidationParms ::= SEQUENCE {
+            seed             BIT STRING,
+            pgenCounter      INTEGER }
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 10]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   The fields of type DomainParameters have the following meanings:
+
+      p identifies the prime p defining the Galois field;
+
+      g specifies the generator of the multiplicative subgroup of order
+      g;
+
+      q specifies the prime factor of p-1;
+
+      j optionally specifies the value that satisfies the equation
+      p=jq+1 to support the optional verification of group parameters;
+
+      seed optionally specifies the bit string parameter used as the
+      seed for the domain parameter generation process; and
+
+      pgenCounter optionally specifies the integer value output as part
+      of the of the domain parameter prime generation process.
+
+   If either of the domain parameter generation components (pgenCounter
+   or seed) is provided, the other MUST be present as well.
+
+   The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
+   this encoding shall be used as the contents (i.e., the value) of the
+   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
+   data element.
+
+      DHPublicKey ::= INTEGER -- public key, y = g^x mod p
+
+   If the keyUsage extension is present in a certificate which conveys a
+   DH public key, the following values may be present:
+
+      keyAgreement;
+      encipherOnly; and
+      decipherOnly.
+
+   If present, the keyUsage extension MUST assert keyAgreement and MAY
+   assert either encipherOnly and decipherOnly.  The keyUsage extension
+   MUST NOT assert both encipherOnly and decipherOnly.
+
+2.3.4 KEA Public Keys
+
+   This section identifies the preferred OID and parameters for the
+   inclusion of a KEA public key in a certificate.  The Key Exchange
+   Algorithm (KEA) is a key agreement algorithm.  Two parties may
+   generate a "pairwise key" if and only if they share the same KEA
+   parameters.  The KEA parameters are not included in a certificate;
+   instead a domain identifier is supplied in the parameters field.
+
+
+
+
+Polk, et al.                Standards Track                    [Page 11]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
+   identifier and parameters SHALL be as defined in [SDN.701r]:
+
+      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
+             { 2 16 840 1 101 2 1 1 22 }
+
+      KEA-Parms-Id     ::= OCTET STRING
+
+   CAs MUST populate the parameters field of the AlgorithmIdentifier
+   within the SubjectPublicKeyInfo field of each certificate containing
+   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
+   also known as the domain identifier.  The domain identifier is
+   computed in three steps:
+
+      (1) the KEA domain parameters (p, q, and g) are DER encoded using
+      the Dss-Parms structure;
+
+      (2) a 160-bit SHA-1 hash is generated from the parameters; and
+
+      (3) the 160-bit hash is reduced to 80-bits by performing an
+      "exclusive or" of the 80 high order bits with the 80 low order
+      bits.
+
+   The resulting value is encoded such that the most significant byte of
+   the 80-bit value is the first octet in the octet string.  The Dss-
+   Parms is provided above in Section 2.3.2.
+
+   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
+   such that the most significant bit (MSB) of y becomes the MSB of the
+   BIT STRING value field and the least significant bit (LSB) of y
+   becomes the LSB of the BIT STRING value field.  This results in the
+   following encoding:
+
+      BIT STRING tag;
+      BIT STRING length;
+      0 (indicating that there are zero unused bits in the final octet
+      of y); and
+      BIT STRING value field including y.
+
+   The key usage extension may optionally appear in a KEA certificate.
+   If a KEA certificate includes the keyUsage extension, only the
+   following values may be asserted:
+
+      keyAgreement;
+      encipherOnly; and
+      decipherOnly.
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 12]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   If present, the keyUsage extension MUST assert keyAgreement and MAY
+   assert either encipherOnly and decipherOnly.  The keyUsage extension
+   MUST NOT assert both encipherOnly and decipherOnly.
+
+2.3.5 ECDSA and ECDH Keys
+
+   This section identifies the preferred OID and parameter encoding for
+   the inclusion of an ECDSA or ECDH public key in a certificate.  The
+   Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
+   [X9.62].  ECDSA is the elliptic curve mathematical analog of the
+   Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
+   Hellman (ECDH) algorithm is a key agreement algorithm defined in
+   [X9.63].
+
+   ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
+   key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
+   specifications use the same OIDs and parameter encodings.  The ASN.1
+   object identifiers used to identify these public keys are defined in
+   the following arc:
+
+   ansi-X9-62 OBJECT IDENTIFIER ::=
+                             { iso(1) member-body(2) us(840) 10045 }
+
+   When certificates contain an ECDSA or ECDH public key, the
+   id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
+   algorithm identifier is defined as follows:
+
+     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }
+
+     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
+
+   This OID is used in public key certificates for both ECDSA signature
+   keys and ECDH encryption keys.  The intended application for the key
+   may be indicated in the key usage field (see [RFC 3280]).  The use of
+   a single key for both signature and encryption purposes is not
+   recommended, but is not forbidden.
+
+   ECDSA and ECDH require use of certain parameters with the public key.
+   The parameters may be inherited from the issuer, implicitly included
+   through reference to a "named curve," or explicitly included in the
+   certificate.
+
+      EcpkParameters ::= CHOICE {
+        ecParameters  ECParameters,
+        namedCurve    OBJECT IDENTIFIER,
+        implicitlyCA  NULL }
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 13]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   When the parameters are inherited, the parameters field SHALL contain
+   implictlyCA, which is the ASN.1 value NULL.  When parameters are
+   specified by reference, the parameters field SHALL contain the
+   named-Curve choice, which is an object identifier.  When the
+   parameters are explicitly included, they SHALL be encoded in the
+   ASN.1 structure ECParameters:
+
+      ECParameters ::= SEQUENCE {
+         version   ECPVer,          -- version is always 1
+         fieldID   FieldID,         -- identifies the finite field over
+                                    -- which the curve is defined
+         curve     Curve,           -- coefficients a and b of the
+                                    -- elliptic curve
+         base      ECPoint,         -- specifies the base point P
+                                    -- on the elliptic curve
+         order     INTEGER,         -- the order n of the base point
+         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
+         }
+
+      ECPVer ::= INTEGER {ecpVer1(1)}
+
+      Curve ::= SEQUENCE {
+         a         FieldElement,
+         b         FieldElement,
+         seed      BIT STRING OPTIONAL }
+
+      FieldElement ::= OCTET STRING
+
+      ECPoint ::= OCTET STRING
+
+   The value of FieldElement SHALL be the octet string representation of
+   a field element following the conversion routine in [X9.62], Section
+   4.3.3.  The value of ECPoint SHALL be the octet string representation
+   of an elliptic curve point following the conversion routine in
+   [X9.62], Section 4.3.6.  Note that this octet string may represent an
+   elliptic curve point in compressed or uncompressed form.
+
+   Implementations that support elliptic curve according to this
+   specification MUST support the uncompressed form and MAY support the
+   compressed form.
+
+   The components of type ECParameters have the following meanings:
+
+      version specifies the version number of the elliptic curve
+      parameters.  It MUST have the value 1 (ecpVer1).
+
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 14]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+      fieldID identifies the finite field over which the elliptic curve
+      is defined.  Finite fields are represented by values of the
+      parameterized type FieldID, constrained to the values of the
+      objects defined in the information object set FieldTypes.
+      Additional detail regarding fieldID is provided below.
+
+      curve specifies the coefficients a and b of the elliptic curve E.
+      Each coefficient is represented as a value of type FieldElement,
+      an OCTET STRING. seed is an optional parameter used to derive the
+      coefficients of a randomly generated elliptic curve.
+
+      base specifies the base point P on the elliptic curve.  The base
+      point is represented as a value of type ECPoint, an OCTET STRING.
+
+      order specifies the order n of the base point.
+
+      cofactor is the integer h = #E(Fq)/n.  This parameter is specified
+      as OPTIONAL.  However, the cofactor MUST be included in ECDH
+      public key parameters.  The cofactor is not required to support
+      ECDSA, except in parameter validation.  The cofactor MAY be
+      included to support parameter validation for ECDSA keys.
+      Parameter validation is not required by this specification.
+
+   The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
+   within a certificate where the parameters may be used.  If the
+   elliptic curve parameters are specified as implicitlyCA in the
+   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
+   subject certificate using ECDSA, then the certificate issuer's ECDSA
+   parameters apply to the subject's ECDSA key.  If the elliptic curve
+   parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
+   AlgorithmIdentifier and the CA signed the certificate using a
+   signature algorithm other than ECDSA, then clients MUST not make use
+   of the elliptic curve public key.
+
+      FieldID ::= SEQUENCE {
+         fieldType   OBJECT IDENTIFIER,
+         parameters  ANY DEFINED BY fieldType }
+
+   FieldID is a SEQUENCE of two components, fieldType and parameters.
+   The fieldType contains an object identifier value that uniquely
+   identifies the type contained in the parameters.
+
+   The object identifier id-fieldType specifies an arc containing the
+   object identifiers of each field type.  It has the following value:
+
+      id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 15]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   The object identifiers prime-field and characteristic-two-field name
+   the two kinds of fields defined in this Standard.  They have the
+   following values:
+
+      prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
+
+      Prime-p ::= INTEGER    -- Field size p (p in bits)
+
+      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 }
+
+   The object identifier id-characteristic-two-basis specifies an arc
+   containing the object identifiers for each type of basis for the
+   characteristic-two finite fields.  It has the following value:
+
+      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
+           characteristic-two-field basisType(1) }
+
+   The object identifiers gnBasis, tpBasis and ppBasis name the three
+   kinds of basis for characteristic-two finite fields defined by
+   [X9.62].  They have the following values:
+
+      gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
+
+      -- for gnBasis, the value of the parameters field is NULL
+
+      tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
+
+      -- type of parameters field for tpBasis is Trinomial
+
+      Trinomial ::= INTEGER
+
+      ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
+
+      -- type of parameters field for ppBasis is Pentanomial
+
+      Pentanomial ::= SEQUENCE {
+         k1  INTEGER,
+         k2  INTEGER,
+         k3  INTEGER }
+
+
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 16]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   The elliptic curve public key (an ECPoint which is an OCTET STRING)
+   is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
+   significant bit of the OCTET STRING becomes the most significant bit
+   of the BIT STRING, and the least significant bit of the OCTET STRING
+   becomes the least significant bit of the BIT STRING.  Note that this
+   octet string may represent an elliptic curve point in compressed or
+   uncompressed form.  Implementations that support elliptic curve
+   according to this specification MUST support the uncompressed form
+   and MAY support the compressed form.
+
+   If the keyUsage extension is present in a CA or CRL issuer
+   certificate which conveys an elliptic curve public key, any
+   combination of the following values MAY be present:
+
+      digitalSignature;
+      nonRepudiation; and
+      keyAgreement.
+
+   If the keyAgreement value is present, either of the following values
+   MAY be present:
+
+      encipherOnly; and
+      decipherOnly.
+
+   The keyUsage extension MUST NOT assert both encipherOnly and
+   decipherOnly.
+
+   If the keyUsage extension is present in a CA certificate which
+   conveys an elliptic curve public key, any combination of the
+   following values MAY be present:
+
+      digitalSignature;
+      nonRepudiation;
+      keyAgreement;
+      keyCertSign; and
+      cRLSign.
+
+   As above, if the keyUsage extension asserts keyAgreement then it MAY
+   assert either encipherOnly and decipherOnly.  However, this
+   specification RECOMMENDS that if keyCertSign or cRLSign is present,
+   keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
+
+
+
+
+
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 17]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+3  ASN.1 Module
+
+   PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
+   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+   id-mod-pkix1-algorithms(17) }
+
+   DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+   -- EXPORTS All;
+
+   -- IMPORTS NONE;
+
+   --
+   --   One-way Hash Functions
+   --
+
+   md2  OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 2 }
+
+   md5  OBJECT IDENTIFIER ::= {
+     iso(1) member-body(2) us(840) rsadsi(113549)
+     digestAlgorithm(2) 5 }
+
+   id-sha1  OBJECT IDENTIFIER ::= {
+     iso(1) identified-organization(3) oiw(14) secsig(3)
+     algorithms(2) 26 }
+
+   --
+   --   DSA Keys and Signatures
+   --
+
+   -- OID for DSA public key
+
+   id-dsa OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
+
+   -- encoding for DSA public key
+
+   DSAPublicKey ::= INTEGER  -- public key, y
+
+   Dss-Parms  ::=  SEQUENCE  {
+      p             INTEGER,
+      q             INTEGER,
+      g             INTEGER  }
+
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 18]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   -- OID for DSA signature generated with SHA-1 hash
+
+   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
+        iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
+
+   -- encoding for DSA signature generated with SHA-1 hash
+
+   Dss-Sig-Value  ::=  SEQUENCE  {
+      r       INTEGER,
+      s       INTEGER  }
+
+   --
+   --   RSA Keys and Signatures
+   --
+
+   -- arc for RSA public key and RSA signature OIDs
+
+   pkcs-1 OBJECT IDENTIFIER ::= {
+         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
+
+   -- OID for RSA public keys
+
+   rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }
+
+   -- OID for RSA signature generated with MD2 hash
+
+   md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }
+
+   -- OID for RSA signature generated with MD5 hash
+
+   md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }
+
+   -- OID for RSA signature generated with SHA-1 hash
+
+   sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }
+
+   -- encoding for RSA public key
+
+   RSAPublicKey ::= SEQUENCE {
+      modulus            INTEGER,    -- n
+      publicExponent     INTEGER  }  -- e
+
+
+
+
+
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 19]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   --
+   --   Diffie-Hellman Keys
+   --
+
+   dhpublicnumber OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) ansi-x942(10046)
+        number-type(2) 1 }
+
+   -- encoding for DSA public key
+
+   DHPublicKey ::= INTEGER  -- public key, y = g^x mod p
+
+   DomainParameters ::= SEQUENCE {
+      p       INTEGER,           -- odd prime, p=jq +1
+      g       INTEGER,           -- generator, g
+      q       INTEGER,           -- factor of p-1
+      j       INTEGER OPTIONAL,  -- subgroup factor, j>= 2
+      validationParms  ValidationParms OPTIONAL }
+
+   ValidationParms ::= SEQUENCE {
+      seed             BIT STRING,
+      pgenCounter      INTEGER }
+
+   --
+   --   KEA Keys
+   --
+
+   id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
+        { 2 16 840 1 101 2 1 1 22 }
+
+   KEA-Parms-Id ::= OCTET STRING
+
+   --
+   --   Elliptic Curve Keys, Signatures, and Curves
+   --
+
+   ansi-X9-62 OBJECT IDENTIFIER ::= {
+        iso(1) member-body(2) us(840) 10045 }
+
+   FieldID ::= SEQUENCE {                    -- Finite field
+      fieldType   OBJECT IDENTIFIER,
+      parameters  ANY DEFINED BY fieldType }
+
+   -- Arc for ECDSA signature OIDS
+
+   id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
+
+
+
+
+
+Polk, et al.                Standards Track                    [Page 20]
+
+RFC 3279               Algorithms and Identifiers             April 2002
+
+
+   -- OID for ECDSA signatures with SHA-1
+
+   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
+
+   -- OID for an elliptic curve signature
+   -- format for the value of an ECDSA signature value
+
+   ECDSA-Sig-Value ::= SEQUENCE {
+      r     INTEGER,
+      s     INTEGER }
+
+   -- 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: tim.polk@nist.gov
+
+   Russell Housley
+   RSA Laboratories
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+   EMail: rhousley@rsasecurity.com
+
+   Larry Bassham
+   NIST
+   100 Bureau Drive, Stop 8930
+   Gaithersburg, MD 20899-8930
+   USA
+   EMail: lbassham@nist.gov
+
+
+
+
+
+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]
+