diff options
Diffstat (limited to 'doc/protocol/rfc3279.txt')
| -rw-r--r-- | doc/protocol/rfc3279.txt | 1515 |
1 files changed, 0 insertions, 1515 deletions
diff --git a/doc/protocol/rfc3279.txt b/doc/protocol/rfc3279.txt deleted file mode 100644 index 04e7b075d4..0000000000 --- a/doc/protocol/rfc3279.txt +++ /dev/null @@ -1,1515 +0,0 @@ - - - - - - -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] - |