diff options
Diffstat (limited to 'utils/open-isns/doc/rfc3279.txt')
| -rw-r--r-- | utils/open-isns/doc/rfc3279.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/utils/open-isns/doc/rfc3279.txt b/utils/open-isns/doc/rfc3279.txt new file mode 100644 index 0000000..04e7b07 --- /dev/null +++ b/utils/open-isns/doc/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] + |