doc/protocol/rfc3279.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            W. Polk
   8 Request for Comments: 3279                                          NIST
   9 Obsoletes: 2528                                               R. Housley
  10 Category: Standards Track                               RSA Laboratories
  11                                                               L. Bassham
  12                                                                     NIST
  13                                                               April 2002
  14
  15                    Algorithms and Identifiers for the
  16                 Internet X.509 Public Key Infrastructure
  17        Certificate and Certificate Revocation List (CRL) Profile
  18
  19 Status of this Memo
  20
  21    This document specifies an Internet standards track protocol for the
  22    Internet community, and requests discussion and suggestions for
  23    improvements.  Please refer to the current edition of the "Internet
  24    Official Protocol Standards" (STD 1) for the standardization state
  25    and status of this protocol.  Distribution of this memo is unlimited.
  26
  27 Copyright Notice
  28
  29    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  30
  31 Abstract
  32
  33    This document specifies algorithm identifiers and ASN.1 encoding
  34    formats for digital signatures and subject public keys used in the
  35    Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
  36    are used to sign certificates and certificate revocation list (CRLs).
  37    Certificates include the public key of the named subject.
  38
  39 Table of Contents
  40
  41    1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
  42    2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
  43    2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
  44    2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
  45    2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
  46    2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
  47    2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
  48    2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
  49    2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
  50    2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
  51    2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
  52    2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
  53    2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
  54    2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10
  55
  56
  57
  58 Polk, et al.                Standards Track                     [Page 1]
  59 \f
  60 RFC 3279               Algorithms and Identifiers             April 2002
  61
  62
  63    2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
  64    2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
  65    3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
  66    4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
  67    5  Security Considerations . . . . . . . . . . . . . . . . .  25
  68    6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
  69    7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
  70    8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27
  71
  72 1  Introduction
  73
  74    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  75    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  76    document are to be interpreted as described in [RFC 2119].
  77
  78    This document specifies algorithm identifiers and ASN.1 [X.660]
  79    encoding formats for digital signatures and subject public keys used
  80    in the Internet X.509 Public Key Infrastructure (PKI).  This
  81    specification supplements [RFC 3280], "Internet X.509 Public Key
  82    Infrastructure:  Certificate and Certificate Revocation List (CRL)
  83    Profile."  Implementations of this specification MUST also conform to
  84    RFC 3280.
  85
  86    This specification defines the contents of the signatureAlgorithm,
  87    signatureValue, signature, and subjectPublicKeyInfo fields within
  88    Internet X.509 certificates and CRLs.
  89
  90    This document identifies one-way hash functions for use in the
  91    generation of digital signatures.  These algorithms are used in
  92    conjunction with digital signature algorithms.
  93
  94    This specification describes the encoding of digital signatures
  95    generated with the following cryptographic algorithms:
  96
  97       * Rivest-Shamir-Adelman (RSA);
  98       * Digital Signature Algorithm (DSA); and
  99       * Elliptic Curve Digital Signature Algorithm (ECDSA).
 100
 101    This document specifies the contents of the subjectPublicKeyInfo
 102    field in Internet X.509 certificates.  For each algorithm, the
 103    appropriate alternatives for the the keyUsage extension are provided.
 104    This specification describes encoding formats for public keys used
 105    with the following cryptographic algorithms:
 106
 107       * Rivest-Shamir-Adelman (RSA);
 108       * Digital Signature Algorithm (DSA);
 109       * Diffie-Hellman (DH);
 110       * Key Encryption Algorithm (KEA);
 111
 112
 113
 114 Polk, et al.                Standards Track                     [Page 2]
 115 \f
 116 RFC 3279               Algorithms and Identifiers             April 2002
 117
 118
 119       * Elliptic Curve Digital Signature Algorithm (ECDSA); and
 120       * Elliptic Curve Diffie-Hellman (ECDH).
 121
 122 2  Algorithm Support
 123
 124    This section describes cryptographic algorithms which may be used
 125    with the Internet X.509 certificate and CRL profile [RFC 3280].  This
 126    section describes one-way hash functions and digital signature
 127    algorithms which may be used to sign certificates and CRLs, and
 128    identifies object identifiers (OIDs) for public keys contained in a
 129    certificate.
 130
 131    Conforming CAs and applications MUST, at a minimum, support digital
 132    signatures and public keys for one of the specified algorithms.  When
 133    using any of the algorithms identified in this specification,
 134    conforming CAs and applications MUST support them as described.
 135
 136 2.1  One-way Hash Functions
 137
 138    This section identifies one-way hash functions for use in the
 139    Internet X.509 PKI.  One-way hash functions are also called message
 140    digest algorithms.  SHA-1 is the preferred one-way hash function for
 141    the Internet X.509 PKI.  However, PEM uses MD2 for certificates [RFC
 142    1422] [RFC 1423] and MD5 is used in other legacy applications.  For
 143    these reasons, MD2 and MD5 are included in this profile.  The data
 144    that is hashed for certificate and CRL signing is fully described in
 145    [RFC 3280].
 146
 147 2.1.1  MD2 One-way Hash Function
 148
 149    MD2 was developed by Ron Rivest for RSA Security.  RSA Security has
 150    recently placed the MD2 algorithm in the public domain.  Previously,
 151    RSA Data Security had granted license for use of MD2 for non-
 152    commercial Internet Privacy-Enhanced Mail (PEM).  MD2 may continue to
 153    be used with PEM certificates, but SHA-1 is preferred.  MD2 produces
 154    a 128-bit "hash" of the input.  MD2 is fully described in [RFC 1319].
 155
 156    At the Selected Areas in Cryptography '95 conference in May 1995,
 157    Rogier and Chauvaud presented an attack on MD2 that can nearly find
 158    collisions [RC95].  Collisions occur when one can find two different
 159    messages that generate the same message digest.  A checksum operation
 160    in MD2 is the only remaining obstacle to the success of the attack.
 161    For this reason, the use of MD2 for new applications is discouraged.
 162    It is still reasonable to use MD2 to verify existing signatures, as
 163    the ability to find collisions in MD2 does not enable an attacker to
 164    find new messages having a previously computed hash value.
 165
 166
 167
 168
 169
 170 Polk, et al.                Standards Track                     [Page 3]
 171 \f
 172 RFC 3279               Algorithms and Identifiers             April 2002
 173
 174
 175 2.1.2  MD5 One-way Hash Function
 176
 177    MD5 was developed by Ron Rivest for RSA Security.  RSA Security has
 178    placed the MD5 algorithm in the public domain.  MD5 produces a 128-
 179    bit "hash" of the input.  MD5 is fully described in [RFC 1321].
 180
 181    Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
 182    but there are no other known cryptanalytic results.  The use of MD5
 183    for new applications is discouraged.  It is still reasonable to use
 184    MD5 to verify existing signatures.
 185
 186 2.1.3  SHA-1 One-way Hash Function
 187
 188    SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
 189    "hash" of the input.  SHA-1 is fully described in [FIPS 180-1].  RFC
 190    3174 [RFC 3174] also describes SHA-1, and it provides an
 191    implementation of the algorithm.
 192
 193 2.2  Signature Algorithms
 194
 195    Certificates and CRLs conforming to [RFC 3280] may be signed with any
 196    public key signature algorithm.  The certificate or CRL indicates the
 197    algorithm through an algorithm identifier which appears in the
 198    signatureAlgorithm field within the Certificate or CertificateList.
 199    This algorithm identifier is an OID and has optionally associated
 200    parameters.  This section identifies algorithm identifiers and
 201    parameters that MUST be used in the signatureAlgorithm field in a
 202    Certificate or CertificateList.
 203
 204    Signature algorithms are always used in conjunction with a one-way
 205    hash function.
 206
 207    This section identifies OIDS for RSA, DSA, and ECDSA.  The contents
 208    of the parameters component for each algorithm vary; details are
 209    provided for each algorithm.
 210
 211    The data to be signed (e.g., the one-way hash function output value)
 212    is formatted for the signature algorithm to be used.  Then, a private
 213    key operation (e.g., RSA encryption) is performed to generate the
 214    signature value.  This signature value is then ASN.1 encoded as a BIT
 215    STRING and included in the Certificate or CertificateList in the
 216    signature field.
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Polk, et al.                Standards Track                     [Page 4]
 227 \f
 228 RFC 3279               Algorithms and Identifiers             April 2002
 229
 230
 231 2.2.1  RSA Signature Algorithm
 232
 233    The RSA algorithm is named for its inventors: Rivest, Shamir, and
 234    Adleman.  This profile includes three signature algorithms based on
 235    the RSA asymmetric encryption algorithm.  The signature algorithms
 236    combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
 237    functions.
 238
 239    The signature algorithm with SHA-1 and the RSA encryption algorithm
 240    is implemented using the padding and encoding conventions described
 241    in PKCS #1 [RFC 2313].  The message digest is computed using the
 242    SHA-1 hash algorithm.
 243
 244    The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
 245    includes a data encoding step.  In this step, the message digest and
 246    the OID for the one-way hash function used to compute the digest are
 247    combined.  When performing the data encoding step, the md2, md5, and
 248    id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
 249    hash functions, respectively:
 250
 251       md2  OBJECT IDENTIFIER ::= {
 252            iso(1) member-body(2) US(840) rsadsi(113549)
 253            digestAlgorithm(2) 2 }
 254
 255       md5  OBJECT IDENTIFIER ::= {
 256            iso(1) member-body(2) US(840) rsadsi(113549)
 257            digestAlgorithm(2) 5 }
 258
 259       id-sha1  OBJECT IDENTIFIER ::= {
 260            iso(1) identified-organization(3) oiw(14) secsig(3)
 261            algorithms(2) 26 }
 262
 263    The signature algorithm with MD2 and the RSA encryption algorithm is
 264    defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
 265    ASN.1 OID used to identify this signature algorithm is:
 266
 267       md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
 268           iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 269           pkcs-1(1) 2  }
 270
 271    The signature algorithm with MD5 and the RSA encryption algorithm is
 272    defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
 273    ASN.1 OID used to identify this signature algorithm is:
 274
 275       md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
 276           iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 277           pkcs-1(1) 4  }
 278
 279
 280
 281
 282 Polk, et al.                Standards Track                     [Page 5]
 283 \f
 284 RFC 3279               Algorithms and Identifiers             April 2002
 285
 286
 287    The ASN.1 object identifier used to identify this signature algorithm
 288    is:
 289
 290       sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
 291           iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 292           pkcs-1(1) 5  }
 293
 294    When any of these three OIDs appears within the ASN.1 type
 295    AlgorithmIdentifier, the parameters component of that type SHALL be
 296    the ASN.1 type NULL.
 297
 298    The RSA signature generation process and the encoding of the result
 299    is described in detail in PKCS #1 [RFC 2313].
 300
 301 2.2.2  DSA Signature Algorithm
 302
 303    The Digital Signature Algorithm (DSA) is defined in the Digital
 304    Signature Standard (DSS).  DSA was developed by the U.S. Government,
 305    and DSA is used in conjunction with the SHA-1 one-way hash function.
 306    DSA is fully described in [FIPS 186].  The ASN.1 OID used to identify
 307    this signature algorithm is:
 308
 309       id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
 310            iso(1) member-body(2) us(840) x9-57 (10040)
 311            x9cm(4) 3 }
 312
 313    When the id-dsa-with-sha1 algorithm identifier appears as the
 314    algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
 315    the parameters field.  That is, the AlgorithmIdentifier SHALL be a
 316    SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.
 317
 318    The DSA parameters in the subjectPublicKeyInfo field of the
 319    certificate of the issuer SHALL apply to the verification of the
 320    signature.
 321
 322    When signing, the DSA algorithm generates two values.  These values
 323    are commonly referred to as r and s.  To easily transfer these two
 324    values as one signature, they SHALL be ASN.1 encoded using the
 325    following ASN.1 structure:
 326
 327       Dss-Sig-Value  ::=  SEQUENCE  {
 328               r       INTEGER,
 329               s       INTEGER  }
 330
 331
 332
 333
 334
 335
 336
 337
 338 Polk, et al.                Standards Track                     [Page 6]
 339 \f
 340 RFC 3279               Algorithms and Identifiers             April 2002
 341
 342
 343 2.2.3 ECDSA Signature Algorithm
 344
 345    The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
 346    [X9.62].  The ASN.1 object identifiers used to identify ECDSA are
 347    defined in the following arc:
 348
 349       ansi-X9-62  OBJECT IDENTIFIER ::= {
 350            iso(1) member-body(2) us(840) 10045 }
 351
 352       id-ecSigType OBJECT IDENTIFIER  ::=  {
 353            ansi-X9-62 signatures(4) }
 354
 355    ECDSA is used in conjunction with the SHA-1 one-way hash function.
 356    The ASN.1 object identifier used to identify ECDSA with SHA-1 is:
 357
 358       ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
 359            id-ecSigType 1 }
 360
 361    When the ecdsa-with-SHA1 algorithm identifier appears as the
 362    algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
 363    parameters field.  That is, the AlgorithmIdentifier SHALL be a
 364    SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.
 365
 366    The elliptic curve parameters in the subjectPublicKeyInfo field of
 367    the certificate of the issuer SHALL apply to the verification of the
 368    signature.
 369
 370    When signing, the ECDSA algorithm generates two values.  These values
 371    are commonly referred to as r and s.  To easily transfer these two
 372    values as one signature, they MUST be ASN.1 encoded using the
 373    following ASN.1 structure:
 374
 375       Ecdsa-Sig-Value  ::=  SEQUENCE  {
 376            r     INTEGER,
 377            s     INTEGER  }
 378
 379 2.3  Subject Public Key Algorithms
 380
 381    Certificates conforming to [RFC 3280] may convey a public key for any
 382    public key algorithm.  The certificate indicates the algorithm
 383    through an algorithm identifier.  This algorithm identifier is an OID
 384    and optionally associated parameters.
 385
 386    This section identifies preferred OIDs and parameters for the RSA,
 387    DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
 388    MUST use the identified OIDs when issuing certificates containing
 389
 390
 391
 392
 393
 394 Polk, et al.                Standards Track                     [Page 7]
 395 \f
 396 RFC 3279               Algorithms and Identifiers             April 2002
 397
 398
 399    public keys for these algorithms.  Conforming applications supporting
 400    any of these algorithms MUST, at a minimum, recognize the OID
 401    identified in this section.
 402
 403 2.3.1  RSA Keys
 404
 405    The OID rsaEncryption identifies RSA public keys.
 406
 407       pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
 408                      rsadsi(113549) pkcs(1) 1 }
 409
 410       rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}
 411
 412    The rsaEncryption OID is intended to be used in the algorithm field
 413    of a value of type AlgorithmIdentifier.  The parameters field MUST
 414    have ASN.1 type NULL for this algorithm identifier.
 415
 416    The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:
 417
 418       RSAPublicKey ::= SEQUENCE {
 419          modulus            INTEGER,    -- n
 420          publicExponent     INTEGER  }  -- e
 421
 422    where modulus is the modulus n, and publicExponent is the public
 423    exponent e.  The DER encoded RSAPublicKey is the value of the BIT
 424    STRING subjectPublicKey.
 425
 426    This OID is used in public key certificates for both RSA signature
 427    keys and RSA encryption keys.  The intended application for the key
 428    MAY be indicated in the key usage field (see [RFC 3280]).  The use of
 429    a single key for both signature and encryption purposes is not
 430    recommended, but is not forbidden.
 431
 432    If the keyUsage extension is present in an end entity certificate
 433    which conveys an RSA public key, any combination of the following
 434    values MAY be present:
 435
 436       digitalSignature;
 437       nonRepudiation;
 438       keyEncipherment; and
 439       dataEncipherment.
 440
 441    If the keyUsage extension is present in a CA or CRL issuer
 442    certificate which conveys an RSA public key, any combination of the
 443    following values MAY be present:
 444
 445       digitalSignature;
 446       nonRepudiation;
 447
 448
 449
 450 Polk, et al.                Standards Track                     [Page 8]
 451 \f
 452 RFC 3279               Algorithms and Identifiers             April 2002
 453
 454
 455       keyEncipherment;
 456       dataEncipherment;
 457       keyCertSign; and
 458       cRLSign.
 459
 460    However, this specification RECOMMENDS that if keyCertSign or cRLSign
 461    is present, both keyEncipherment and dataEncipherment SHOULD NOT be
 462    present.
 463
 464 2.3.2  DSA Signature Keys
 465
 466    The Digital Signature Algorithm (DSA) is defined in the Digital
 467    Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
 468    profile is:
 469
 470       id-dsa OBJECT IDENTIFIER ::= {
 471            iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
 472
 473    The id-dsa algorithm syntax includes optional domain parameters.
 474    These parameters are commonly referred to as p, q, and g.  When
 475    omitted, the parameters component MUST be omitted entirely.  That is,
 476    the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
 477    OBJECT IDENTIFIER id-dsa.
 478
 479    If the DSA domain parameters are present in the subjectPublicKeyInfo
 480    AlgorithmIdentifier, the parameters are included using the following
 481    ASN.1 structure:
 482
 483       Dss-Parms  ::=  SEQUENCE  {
 484           p             INTEGER,
 485           q             INTEGER,
 486           g             INTEGER  }
 487
 488    The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
 489    within a certificate where the parameters may be used.  If the DSA
 490    algorithm parameters are omitted from the subjectPublicKeyInfo
 491    AlgorithmIdentifier and the CA signed the subject certificate using
 492    DSA, then the certificate issuer's DSA parameters apply to the
 493    subject's DSA key.  If the DSA domain parameters are omitted from the
 494    SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
 495    subject certificate using a signature algorithm other than DSA, then
 496    the subject's DSA domain parameters are distributed by other means.
 497    If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
 498    parameters component, the CA signed the subject with a signature
 499    algorithm other than DSA, and the subject's DSA parameters are not
 500    available through other means, then clients MUST reject the
 501    certificate.
 502
 503
 504
 505
 506 Polk, et al.                Standards Track                     [Page 9]
 507 \f
 508 RFC 3279               Algorithms and Identifiers             April 2002
 509
 510
 511    The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
 512    encoding shall be used as the contents (i.e., the value) of the
 513    subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
 514    data element.
 515
 516       DSAPublicKey ::= INTEGER -- public key, Y
 517
 518    If the keyUsage extension is present in an end entity certificate
 519    which conveys a DSA public key, any combination of the following
 520    values MAY be present:
 521
 522       digitalSignature;
 523       nonRepudiation;
 524
 525    If the keyUsage extension is present in a CA or CRL issuer
 526    certificate which conveys a DSA public key, any combination of the
 527    following values MAY be present:
 528
 529       digitalSignature;
 530       nonRepudiation;
 531       keyCertSign; and
 532       cRLSign.
 533
 534 2.3.3  Diffie-Hellman Key Exchange Keys
 535
 536    The Diffie-Hellman OID supported by this profile is defined in
 537    [X9.42].
 538
 539       dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
 540                 us(840) ansi-x942(10046) number-type(2) 1 }
 541
 542    The dhpublicnumber OID is intended to be used in the algorithm field
 543    of a value of type AlgorithmIdentifier.  The parameters field of that
 544    type, which has the algorithm-specific syntax ANY DEFINED BY
 545    algorithm, have the ASN.1 type DomainParameters for this algorithm.
 546
 547       DomainParameters ::= SEQUENCE {
 548             p       INTEGER, -- odd prime, p=jq +1
 549             g       INTEGER, -- generator, g
 550             q       INTEGER, -- factor of p-1
 551             j       INTEGER OPTIONAL, -- subgroup factor
 552             validationParms  ValidationParms OPTIONAL }
 553
 554       ValidationParms ::= SEQUENCE {
 555             seed             BIT STRING,
 556             pgenCounter      INTEGER }
 557
 558
 559
 560
 561
 562 Polk, et al.                Standards Track                    [Page 10]
 563 \f
 564 RFC 3279               Algorithms and Identifiers             April 2002
 565
 566
 567    The fields of type DomainParameters have the following meanings:
 568
 569       p identifies the prime p defining the Galois field;
 570
 571       g specifies the generator of the multiplicative subgroup of order
 572       g;
 573
 574       q specifies the prime factor of p-1;
 575
 576       j optionally specifies the value that satisfies the equation
 577       p=jq+1 to support the optional verification of group parameters;
 578
 579       seed optionally specifies the bit string parameter used as the
 580       seed for the domain parameter generation process; and
 581
 582       pgenCounter optionally specifies the integer value output as part
 583       of the of the domain parameter prime generation process.
 584
 585    If either of the domain parameter generation components (pgenCounter
 586    or seed) is provided, the other MUST be present as well.
 587
 588    The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
 589    this encoding shall be used as the contents (i.e., the value) of the
 590    subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
 591    data element.
 592
 593       DHPublicKey ::= INTEGER -- public key, y = g^x mod p
 594
 595    If the keyUsage extension is present in a certificate which conveys a
 596    DH public key, the following values may be present:
 597
 598       keyAgreement;
 599       encipherOnly; and
 600       decipherOnly.
 601
 602    If present, the keyUsage extension MUST assert keyAgreement and MAY
 603    assert either encipherOnly and decipherOnly.  The keyUsage extension
 604    MUST NOT assert both encipherOnly and decipherOnly.
 605
 606 2.3.4 KEA Public Keys
 607
 608    This section identifies the preferred OID and parameters for the
 609    inclusion of a KEA public key in a certificate.  The Key Exchange
 610    Algorithm (KEA) is a key agreement algorithm.  Two parties may
 611    generate a "pairwise key" if and only if they share the same KEA
 612    parameters.  The KEA parameters are not included in a certificate;
 613    instead a domain identifier is supplied in the parameters field.
 614
 615
 616
 617
 618 Polk, et al.                Standards Track                    [Page 11]
 619 \f
 620 RFC 3279               Algorithms and Identifiers             April 2002
 621
 622
 623    When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
 624    identifier and parameters SHALL be as defined in [SDN.701r]:
 625
 626       id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
 627              { 2 16 840 1 101 2 1 1 22 }
 628
 629       KEA-Parms-Id     ::= OCTET STRING
 630
 631    CAs MUST populate the parameters field of the AlgorithmIdentifier
 632    within the SubjectPublicKeyInfo field of each certificate containing
 633    a KEA public key with an 80-bit parameter identifier (OCTET STRING),
 634    also known as the domain identifier.  The domain identifier is
 635    computed in three steps:
 636
 637       (1) the KEA domain parameters (p, q, and g) are DER encoded using
 638       the Dss-Parms structure;
 639
 640       (2) a 160-bit SHA-1 hash is generated from the parameters; and
 641
 642       (3) the 160-bit hash is reduced to 80-bits by performing an
 643       "exclusive or" of the 80 high order bits with the 80 low order
 644       bits.
 645
 646    The resulting value is encoded such that the most significant byte of
 647    the 80-bit value is the first octet in the octet string.  The Dss-
 648    Parms is provided above in Section 2.3.2.
 649
 650    A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
 651    such that the most significant bit (MSB) of y becomes the MSB of the
 652    BIT STRING value field and the least significant bit (LSB) of y
 653    becomes the LSB of the BIT STRING value field.  This results in the
 654    following encoding:
 655
 656       BIT STRING tag;
 657       BIT STRING length;
 658       0 (indicating that there are zero unused bits in the final octet
 659       of y); and
 660       BIT STRING value field including y.
 661
 662    The key usage extension may optionally appear in a KEA certificate.
 663    If a KEA certificate includes the keyUsage extension, only the
 664    following values may be asserted:
 665
 666       keyAgreement;
 667       encipherOnly; and
 668       decipherOnly.
 669
 670
 671
 672
 673
 674 Polk, et al.                Standards Track                    [Page 12]
 675 \f
 676 RFC 3279               Algorithms and Identifiers             April 2002
 677
 678
 679    If present, the keyUsage extension MUST assert keyAgreement and MAY
 680    assert either encipherOnly and decipherOnly.  The keyUsage extension
 681    MUST NOT assert both encipherOnly and decipherOnly.
 682
 683 2.3.5 ECDSA and ECDH Keys
 684
 685    This section identifies the preferred OID and parameter encoding for
 686    the inclusion of an ECDSA or ECDH public key in a certificate.  The
 687    Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
 688    [X9.62].  ECDSA is the elliptic curve mathematical analog of the
 689    Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
 690    Hellman (ECDH) algorithm is a key agreement algorithm defined in
 691    [X9.63].
 692
 693    ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
 694    key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
 695    specifications use the same OIDs and parameter encodings.  The ASN.1
 696    object identifiers used to identify these public keys are defined in
 697    the following arc:
 698
 699    ansi-X9-62 OBJECT IDENTIFIER ::=
 700                              { iso(1) member-body(2) us(840) 10045 }
 701
 702    When certificates contain an ECDSA or ECDH public key, the
 703    id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
 704    algorithm identifier is defined as follows:
 705
 706      id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }
 707
 708      id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
 709
 710    This OID is used in public key certificates for both ECDSA signature
 711    keys and ECDH encryption keys.  The intended application for the key
 712    may be indicated in the key usage field (see [RFC 3280]).  The use of
 713    a single key for both signature and encryption purposes is not
 714    recommended, but is not forbidden.
 715
 716    ECDSA and ECDH require use of certain parameters with the public key.
 717    The parameters may be inherited from the issuer, implicitly included
 718    through reference to a "named curve," or explicitly included in the
 719    certificate.
 720
 721       EcpkParameters ::= CHOICE {
 722         ecParameters  ECParameters,
 723         namedCurve    OBJECT IDENTIFIER,
 724         implicitlyCA  NULL }
 725
 726
 727
 728
 729
 730 Polk, et al.                Standards Track                    [Page 13]
 731 \f
 732 RFC 3279               Algorithms and Identifiers             April 2002
 733
 734
 735    When the parameters are inherited, the parameters field SHALL contain
 736    implictlyCA, which is the ASN.1 value NULL.  When parameters are
 737    specified by reference, the parameters field SHALL contain the
 738    named-Curve choice, which is an object identifier.  When the
 739    parameters are explicitly included, they SHALL be encoded in the
 740    ASN.1 structure ECParameters:
 741
 742       ECParameters ::= SEQUENCE {
 743          version   ECPVer,          -- version is always 1
 744          fieldID   FieldID,         -- identifies the finite field over
 745                                     -- which the curve is defined
 746          curve     Curve,           -- coefficients a and b of the
 747                                     -- elliptic curve
 748          base      ECPoint,         -- specifies the base point P
 749                                     -- on the elliptic curve
 750          order     INTEGER,         -- the order n of the base point
 751          cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
 752          }
 753
 754       ECPVer ::= INTEGER {ecpVer1(1)}
 755
 756       Curve ::= SEQUENCE {
 757          a         FieldElement,
 758          b         FieldElement,
 759          seed      BIT STRING OPTIONAL }
 760
 761       FieldElement ::= OCTET STRING
 762
 763       ECPoint ::= OCTET STRING
 764
 765    The value of FieldElement SHALL be the octet string representation of
 766    a field element following the conversion routine in [X9.62], Section
 767    4.3.3.  The value of ECPoint SHALL be the octet string representation
 768    of an elliptic curve point following the conversion routine in
 769    [X9.62], Section 4.3.6.  Note that this octet string may represent an
 770    elliptic curve point in compressed or uncompressed form.
 771
 772    Implementations that support elliptic curve according to this
 773    specification MUST support the uncompressed form and MAY support the
 774    compressed form.
 775
 776    The components of type ECParameters have the following meanings:
 777
 778       version specifies the version number of the elliptic curve
 779       parameters.  It MUST have the value 1 (ecpVer1).
 780
 781
 782
 783
 784
 785
 786 Polk, et al.                Standards Track                    [Page 14]
 787 \f
 788 RFC 3279               Algorithms and Identifiers             April 2002
 789
 790
 791       fieldID identifies the finite field over which the elliptic curve
 792       is defined.  Finite fields are represented by values of the
 793       parameterized type FieldID, constrained to the values of the
 794       objects defined in the information object set FieldTypes.
 795       Additional detail regarding fieldID is provided below.
 796
 797       curve specifies the coefficients a and b of the elliptic curve E.
 798       Each coefficient is represented as a value of type FieldElement,
 799       an OCTET STRING. seed is an optional parameter used to derive the
 800       coefficients of a randomly generated elliptic curve.
 801
 802       base specifies the base point P on the elliptic curve.  The base
 803       point is represented as a value of type ECPoint, an OCTET STRING.
 804
 805       order specifies the order n of the base point.
 806
 807       cofactor is the integer h = #E(Fq)/n.  This parameter is specified
 808       as OPTIONAL.  However, the cofactor MUST be included in ECDH
 809       public key parameters.  The cofactor is not required to support
 810       ECDSA, except in parameter validation.  The cofactor MAY be
 811       included to support parameter validation for ECDSA keys.
 812       Parameter validation is not required by this specification.
 813
 814    The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
 815    within a certificate where the parameters may be used.  If the
 816    elliptic curve parameters are specified as implicitlyCA in the
 817    SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
 818    subject certificate using ECDSA, then the certificate issuer's ECDSA
 819    parameters apply to the subject's ECDSA key.  If the elliptic curve
 820    parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
 821    AlgorithmIdentifier and the CA signed the certificate using a
 822    signature algorithm other than ECDSA, then clients MUST not make use
 823    of the elliptic curve public key.
 824
 825       FieldID ::= SEQUENCE {
 826          fieldType   OBJECT IDENTIFIER,
 827          parameters  ANY DEFINED BY fieldType }
 828
 829    FieldID is a SEQUENCE of two components, fieldType and parameters.
 830    The fieldType contains an object identifier value that uniquely
 831    identifies the type contained in the parameters.
 832
 833    The object identifier id-fieldType specifies an arc containing the
 834    object identifiers of each field type.  It has the following value:
 835
 836       id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
 837
 838
 839
 840
 841
 842 Polk, et al.                Standards Track                    [Page 15]
 843 \f
 844 RFC 3279               Algorithms and Identifiers             April 2002
 845
 846
 847    The object identifiers prime-field and characteristic-two-field name
 848    the two kinds of fields defined in this Standard.  They have the
 849    following values:
 850
 851       prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
 852
 853       Prime-p ::= INTEGER    -- Field size p (p in bits)
 854
 855       characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
 856
 857       Characteristic-two ::= SEQUENCE {
 858          m           INTEGER,                      -- Field size 2^m
 859          basis       OBJECT IDENTIFIER,
 860          parameters  ANY DEFINED BY basis }
 861
 862    The object identifier id-characteristic-two-basis specifies an arc
 863    containing the object identifiers for each type of basis for the
 864    characteristic-two finite fields.  It has the following value:
 865
 866       id-characteristic-two-basis OBJECT IDENTIFIER ::= {
 867            characteristic-two-field basisType(1) }
 868
 869    The object identifiers gnBasis, tpBasis and ppBasis name the three
 870    kinds of basis for characteristic-two finite fields defined by
 871    [X9.62].  They have the following values:
 872
 873       gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
 874
 875       -- for gnBasis, the value of the parameters field is NULL
 876
 877       tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
 878
 879       -- type of parameters field for tpBasis is Trinomial
 880
 881       Trinomial ::= INTEGER
 882
 883       ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
 884
 885       -- type of parameters field for ppBasis is Pentanomial
 886
 887       Pentanomial ::= SEQUENCE {
 888          k1  INTEGER,
 889          k2  INTEGER,
 890          k3  INTEGER }
 891
 892
 893
 894
 895
 896
 897
 898 Polk, et al.                Standards Track                    [Page 16]
 899 \f
 900 RFC 3279               Algorithms and Identifiers             April 2002
 901
 902
 903    The elliptic curve public key (an ECPoint which is an OCTET STRING)
 904    is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
 905    significant bit of the OCTET STRING becomes the most significant bit
 906    of the BIT STRING, and the least significant bit of the OCTET STRING
 907    becomes the least significant bit of the BIT STRING.  Note that this
 908    octet string may represent an elliptic curve point in compressed or
 909    uncompressed form.  Implementations that support elliptic curve
 910    according to this specification MUST support the uncompressed form
 911    and MAY support the compressed form.
 912
 913    If the keyUsage extension is present in a CA or CRL issuer
 914    certificate which conveys an elliptic curve public key, any
 915    combination of the following values MAY be present:
 916
 917       digitalSignature;
 918       nonRepudiation; and
 919       keyAgreement.
 920
 921    If the keyAgreement value is present, either of the following values
 922    MAY be present:
 923
 924       encipherOnly; and
 925       decipherOnly.
 926
 927    The keyUsage extension MUST NOT assert both encipherOnly and
 928    decipherOnly.
 929
 930    If the keyUsage extension is present in a CA certificate which
 931    conveys an elliptic curve public key, any combination of the
 932    following values MAY be present:
 933
 934       digitalSignature;
 935       nonRepudiation;
 936       keyAgreement;
 937       keyCertSign; and
 938       cRLSign.
 939
 940    As above, if the keyUsage extension asserts keyAgreement then it MAY
 941    assert either encipherOnly and decipherOnly.  However, this
 942    specification RECOMMENDS that if keyCertSign or cRLSign is present,
 943    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Polk, et al.                Standards Track                    [Page 17]
 955 \f
 956 RFC 3279               Algorithms and Identifiers             April 2002
 957
 958
 959 3  ASN.1 Module
 960
 961    PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
 962    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 963    id-mod-pkix1-algorithms(17) }
 964
 965    DEFINITIONS EXPLICIT TAGS ::= BEGIN
 966
 967    -- EXPORTS All;
 968
 969    -- IMPORTS NONE;
 970
 971    --
 972    --   One-way Hash Functions
 973    --
 974
 975    md2  OBJECT IDENTIFIER ::= {
 976      iso(1) member-body(2) us(840) rsadsi(113549)
 977      digestAlgorithm(2) 2 }
 978
 979    md5  OBJECT IDENTIFIER ::= {
 980      iso(1) member-body(2) us(840) rsadsi(113549)
 981      digestAlgorithm(2) 5 }
 982
 983    id-sha1  OBJECT IDENTIFIER ::= {
 984      iso(1) identified-organization(3) oiw(14) secsig(3)
 985      algorithms(2) 26 }
 986
 987    --
 988    --   DSA Keys and Signatures
 989    --
 990
 991    -- OID for DSA public key
 992
 993    id-dsa OBJECT IDENTIFIER ::= {
 994         iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
 995
 996    -- encoding for DSA public key
 997
 998    DSAPublicKey ::= INTEGER  -- public key, y
 999
1000    Dss-Parms  ::=  SEQUENCE  {
1001       p             INTEGER,
1002       q             INTEGER,
1003       g             INTEGER  }
1004
1005
1006
1007
1008
1009
1010 Polk, et al.                Standards Track                    [Page 18]
1011 \f
1012 RFC 3279               Algorithms and Identifiers             April 2002
1013
1014
1015    -- OID for DSA signature generated with SHA-1 hash
1016
1017    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
1018         iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
1019
1020    -- encoding for DSA signature generated with SHA-1 hash
1021
1022    Dss-Sig-Value  ::=  SEQUENCE  {
1023       r       INTEGER,
1024       s       INTEGER  }
1025
1026    --
1027    --   RSA Keys and Signatures
1028    --
1029
1030    -- arc for RSA public key and RSA signature OIDs
1031
1032    pkcs-1 OBJECT IDENTIFIER ::= {
1033          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
1034
1035    -- OID for RSA public keys
1036
1037    rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }
1038
1039    -- OID for RSA signature generated with MD2 hash
1040
1041    md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }
1042
1043    -- OID for RSA signature generated with MD5 hash
1044
1045    md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }
1046
1047    -- OID for RSA signature generated with SHA-1 hash
1048
1049    sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }
1050
1051    -- encoding for RSA public key
1052
1053    RSAPublicKey ::= SEQUENCE {
1054       modulus            INTEGER,    -- n
1055       publicExponent     INTEGER  }  -- e
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Polk, et al.                Standards Track                    [Page 19]
1067 \f
1068 RFC 3279               Algorithms and Identifiers             April 2002
1069
1070
1071    --
1072    --   Diffie-Hellman Keys
1073    --
1074
1075    dhpublicnumber OBJECT IDENTIFIER ::= {
1076         iso(1) member-body(2) us(840) ansi-x942(10046)
1077         number-type(2) 1 }
1078
1079    -- encoding for DSA public key
1080
1081    DHPublicKey ::= INTEGER  -- public key, y = g^x mod p
1082
1083    DomainParameters ::= SEQUENCE {
1084       p       INTEGER,           -- odd prime, p=jq +1
1085       g       INTEGER,           -- generator, g
1086       q       INTEGER,           -- factor of p-1
1087       j       INTEGER OPTIONAL,  -- subgroup factor, j>= 2
1088       validationParms  ValidationParms OPTIONAL }
1089
1090    ValidationParms ::= SEQUENCE {
1091       seed             BIT STRING,
1092       pgenCounter      INTEGER }
1093
1094    --
1095    --   KEA Keys
1096    --
1097
1098    id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
1099         { 2 16 840 1 101 2 1 1 22 }
1100
1101    KEA-Parms-Id ::= OCTET STRING
1102
1103    --
1104    --   Elliptic Curve Keys, Signatures, and Curves
1105    --
1106
1107    ansi-X9-62 OBJECT IDENTIFIER ::= {
1108         iso(1) member-body(2) us(840) 10045 }
1109
1110    FieldID ::= SEQUENCE {                    -- Finite field
1111       fieldType   OBJECT IDENTIFIER,
1112       parameters  ANY DEFINED BY fieldType }
1113
1114    -- Arc for ECDSA signature OIDS
1115
1116    id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
1117
1118
1119
1120
1121
1122 Polk, et al.                Standards Track                    [Page 20]
1123 \f
1124 RFC 3279               Algorithms and Identifiers             April 2002
1125
1126
1127    -- OID for ECDSA signatures with SHA-1
1128
1129    ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
1130
1131    -- OID for an elliptic curve signature
1132    -- format for the value of an ECDSA signature value
1133
1134    ECDSA-Sig-Value ::= SEQUENCE {
1135       r     INTEGER,
1136       s     INTEGER }
1137
1138    -- recognized field type OIDs are defined in the following arc
1139
1140    id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
1141
1142    -- where fieldType is prime-field, the parameters are of type Prime-p
1143
1144    prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
1145
1146    Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime
1147
1148    -- where fieldType is characteristic-two-field, the parameters are
1149    -- of type Characteristic-two
1150
1151    characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
1152
1153    Characteristic-two ::= SEQUENCE {
1154       m           INTEGER,                   -- Field size 2^m
1155       basis       OBJECT IDENTIFIER,
1156       parameters  ANY DEFINED BY basis }
1157
1158    -- recognized basis type OIDs are defined in the following arc
1159
1160    id-characteristic-two-basis OBJECT IDENTIFIER ::= {
1161         characteristic-two-field basisType(3) }
1162
1163    -- gnbasis is identified by OID gnBasis and indicates
1164    -- parameters are NULL
1165
1166    gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
1167
1168    -- parameters for this basis are NULL
1169
1170    -- trinomial basis is identified by OID tpBasis and indicates
1171    -- parameters of type Pentanomial
1172
1173    tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
1174
1175
1176
1177
1178 Polk, et al.                Standards Track                    [Page 21]
1179 \f
1180 RFC 3279               Algorithms and Identifiers             April 2002
1181
1182
1183    -- Trinomial basis representation of F2^m
1184    -- Integer k for reduction polynomial xm + xk + 1
1185
1186    Trinomial ::= INTEGER
1187
1188    -- for pentanomial basis is identified by OID ppBasis and indicates
1189    -- parameters of type Pentanomial
1190
1191    ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
1192
1193    -- Pentanomial basis representation of F2^m
1194    -- reduction polynomial integers k1, k2, k3
1195    -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
1196
1197    Pentanomial ::= SEQUENCE {
1198       k1  INTEGER,
1199       k2  INTEGER,
1200       k3  INTEGER }
1201
1202    -- The object identifiers gnBasis, tpBasis and ppBasis name
1203    -- three kinds of basis for characteristic-two finite fields
1204
1205    FieldElement ::= OCTET STRING             -- Finite field element
1206
1207    ECPoint  ::= OCTET STRING                 -- Elliptic curve point
1208
1209    -- Elliptic Curve parameters may be specified explicitly,
1210    -- specified implicitly through a "named curve", or
1211    -- inherited from the CA
1212
1213    EcpkParameters ::= CHOICE {
1214       ecParameters  ECParameters,
1215       namedCurve    OBJECT IDENTIFIER,
1216       implicitlyCA  NULL }
1217
1218    ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
1219       version   ECPVer,
1220       fieldID   FieldID,
1221       curve     Curve,
1222       base      ECPoint,                -- Base point G
1223       order     INTEGER,                -- Order n of the base point
1224       cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n
1225
1226    ECPVer ::= INTEGER {ecpVer1(1)}
1227
1228
1229
1230
1231
1232
1233
1234 Polk, et al.                Standards Track                    [Page 22]
1235 \f
1236 RFC 3279               Algorithms and Identifiers             April 2002
1237
1238
1239    Curve  ::= SEQUENCE {
1240       a     FieldElement,            -- Elliptic curve coefficient a
1241       b     FieldElement,            -- Elliptic curve coefficient b
1242       seed  BIT STRING  OPTIONAL }
1243
1244    id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }
1245
1246    id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
1247
1248    -- Named Elliptic Curves in ANSI X9.62.
1249
1250    ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }
1251
1252    c-TwoCurve OBJECT IDENTIFIER ::= {
1253         ellipticCurve characteristicTwo(0) }
1254
1255    c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
1256    c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
1257    c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
1258    c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
1259    c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
1260    c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
1261    c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
1262    c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
1263    c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
1264    c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
1265    c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
1266    c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
1267    c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
1268    c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
1269    c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
1270    c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
1271    c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
1272    c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
1273    c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
1274    c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }
1275
1276    primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }
1277
1278    prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
1279    prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
1280    prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
1281    prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
1282    prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
1283    prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
1284    prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }
1285
1286    END
1287
1288
1289
1290 Polk, et al.                Standards Track                    [Page 23]
1291 \f
1292 RFC 3279               Algorithms and Identifiers             April 2002
1293
1294
1295 4  References
1296
1297    [FIPS 180-1]   Federal Information Processing Standards Publication
1298                   (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
1299                   [Supersedes FIPS PUB 180 dated 11 May 1993.]
1300
1301    [FIPS 186-2]   Federal Information Processing Standards Publication
1302                   (FIPS PUB) 186, Digital Signature Standard, 27 January
1303                   2000. [Supersedes FIPS PUB 186-1 dated 15 December
1304                   1998.]
1305
1306    [P1363]        IEEE P1363, "Standard Specifications for Public-Key
1307                   Cryptography", 2001.
1308
1309    [RC95]         Rogier, N. and Chauvaud, P., "The compression function
1310                   of MD2 is not collision free," Presented at Selected
1311                   Areas in Cryptography '95, May 1995.
1312
1313    [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
1314                   Facilities", STD 13, RFC 1034, November 1987.
1315
1316    [RFC 1319]     Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
1317                   1319, April 1992.
1318
1319    [RFC 1321]     Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1320                   1321, April 1992.
1321
1322    [RFC 1422]     Kent, S., "Privacy Enhancement for Internet Electronic
1323                   Mail: Part II: Certificate-Based Key Management", RFC
1324                   1422, February 1993.
1325
1326    [RFC 1423]     Balenson, D., "Privacy Enhancement for Internet
1327                   Electronic Mail: Part III: Algorithms, Modes, and
1328                   Identifiers", RFC 1423, February 1993.
1329
1330    [RFC 2119]     Bradner, S., "Key Words for Use in RFCs to Indicate
1331                   Requirement Levels", BCP 14, RFC 2119, March 1997.
1332
1333    [RFC 2313]     Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
1334                   RFC 2313, March 1998.
1335
1336    [RFC 2459]     Housley, R., Ford, W., Polk, W. and D. Solo "Internet
1337                   X.509 Public Key Infrastructure: Certificate and CRL
1338                   Profile", RFC 2459, January, 1999.
1339
1340    [RFC 3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
1341                   (SHA1)", RFC 3174, September 2001.
1342
1343
1344
1345
1346 Polk, et al.                Standards Track                    [Page 24]
1347 \f
1348 RFC 3279               Algorithms and Identifiers             April 2002
1349
1350
1351    [RFC 3280]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1352                   X.509 Public Key Infrastructure Certificate and
1353                   Certificate Revocation List (CRL) Profile", RFC 3280,
1354                   April 2002.
1355
1356    [SDN.701r]     SDN.701, "Message Security Protocol 4.0", Revision A
1357                   1997-02-06.
1358
1359    [X.208]        CCITT Recommendation X.208: Specification of Abstract
1360                   Syntax Notation One (ASN.1), 1988.
1361
1362    [X.660]        ITU-T Recommendation X.660 Information Technology -
1363                   ASN.1 encoding rules: Specification of Basic Encoding
1364                   Rules (BER), Canonical Encoding Rules (CER) and
1365                   Distinguished Encoding Rules (DER), 1997.
1366
1367    [X9.42]        ANSI X9.42-2000, "Public Key Cryptography for The
1368                   Financial Services Industry: Agreement of Symmetric
1369                   Keys Using Discrete Logarithm Cryptography", December,
1370                   1999.
1371
1372    [X9.62]        X9.62-1998, "Public Key Cryptography For The Financial
1373                   Services Industry: The Elliptic Curve Digital
1374                   Signature Algorithm (ECDSA)", January 7, 1999.
1375
1376    [X9.63]        ANSI X9.63-2001, "Public Key Cryptography For The
1377                   Financial Services Industry: Key Agreement and Key
1378                   Transport Using Elliptic Curve Cryptography", Work in
1379                   Progress.
1380
1381 5  Security Considerations
1382
1383    This specification does not constrain the size of public keys or
1384    their parameters for use in the Internet PKI.  However, the key size
1385    selected impacts the strength achieved when implementing
1386    cryptographic services.  Selection of appropriate key sizes is
1387    critical to implementing appropriate security.
1388
1389    This specification does not identify particular elliptic curves for
1390    use in the Internet PKI.  However, the particular curve selected
1391    impact the strength of the digital signatures.  Some curves are
1392    cryptographically stronger than others!
1393
1394    In general, use of "well-known" curves, such as the "named curves"
1395    from ANSI X9.62, is a sound strategy.  For additional information,
1396    refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
1397    Appendix A.1, "Avoiding Cryptographically Weak Keys".
1398
1399
1400
1401
1402 Polk, et al.                Standards Track                    [Page 25]
1403 \f
1404 RFC 3279               Algorithms and Identifiers             April 2002
1405
1406
1407    This specification supplements RFC 3280.  The security considerations
1408    section of that document applies to this specification as well.
1409
1410 6  Intellectual Property Rights
1411
1412    The IETF has been notified of intellectual property rights claimed in
1413    regard to some or all of the specification contained in this
1414    document.  For more information consult the online list of claimed
1415    rights.
1416
1417    The IETF takes no position regarding the validity or scope of any
1418    intellectual property or other rights that might be claimed to
1419    pertain to the implementation or use of the technology described in
1420    this document or the extent to which any license under such rights
1421    might or might not be available; neither does it represent that it
1422    has made any effort to identify any such rights.  Information on the
1423    IETF's procedures with respect to rights in standards-track and
1424    standards- related documentation can be found in BCP-11.  Copies of
1425    claims of rights made available for publication and any assurances of
1426    licenses to be made available, or the result of an attempt made to
1427    obtain a general license or permission for the use of such
1428    proprietary rights by implementors or users of this specification can
1429    be obtained from the IETF Secretariat.
1430
1431 7  Author Addresses:
1432
1433    Tim Polk
1434    NIST
1435    100 Bureau Drive, Stop 8930
1436    Gaithersburg, MD 20899-8930
1437    USA
1438    EMail: tim.polk@nist.gov
1439
1440    Russell Housley
1441    RSA Laboratories
1442    918 Spring Knoll Drive
1443    Herndon, VA 20170
1444    USA
1445    EMail: rhousley@rsasecurity.com
1446
1447    Larry Bassham
1448    NIST
1449    100 Bureau Drive, Stop 8930
1450    Gaithersburg, MD 20899-8930
1451    USA
1452    EMail: lbassham@nist.gov
1453
1454
1455
1456
1457
1458 Polk, et al.                Standards Track                    [Page 26]
1459 \f
1460 RFC 3279               Algorithms and Identifiers             April 2002
1461
1462
1463 8.  Full Copyright Statement
1464
1465    Copyright (C) The Internet Society (2002).  All Rights Reserved.
1466
1467    This document and translations of it may be copied and furnished to
1468    others, and derivative works that comment on or otherwise explain it
1469    or assist in its implementation may be prepared, copied, published
1470    and distributed, in whole or in part, without restriction of any
1471    kind, provided that the above copyright notice and this paragraph are
1472    included on all such copies and derivative works.  However, this
1473    document itself may not be modified in any way, such as by removing
1474    the copyright notice or references to the Internet Society or other
1475    Internet organizations, except as needed for the purpose of
1476    developing Internet standards in which case the procedures for
1477    copyrights defined in the Internet Standards process must be
1478    followed, or as required to translate it into languages other than
1479    English.
1480
1481    The limited permissions granted above are perpetual and will not be
1482    revoked by the Internet Society or its successors or assigns.
1483
1484    This document and the information contained herein is provided on an
1485    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1486    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1487    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1488    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1489    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1490
1491 Acknowledgement
1492
1493    Funding for the RFC Editor function is currently provided by the
1494    Internet Society.
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Polk, et al.                Standards Track                    [Page 27]
1515 \f