WDIFF

draft-ietf-pkix-ipki-pkalgs-00.txt --> draft-ietf-pkix-ipki-pkalgs-01.txt

PKIX Working Group L. Bassham (NIST)
Internet Draft R. Housley (Spyrus) (SPYRUS)
expires January 14, 2000 April, 2001 W. Polk (NIST)
July 14,
November, 2000

Internet X.509 Public Key Infrastructure

Representation of Public Keys

Algorithms and Digital Signatures
in Identifiers for the
Internet X.509 Public Key Infrastructure Certificates

<draft-ietf-pkix-ipki-pkalgs-00.txt>
Certificate and CRL Profile

<draft-ietf-pkix-ipki-pkalgs-01.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This is the first draft of a specification of document specifies algorithm identifiers and ASN.1 encoding
formats for the representation of cryptographic keys,
associated parameters and digital sigantures signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure X.509 (PKI). Digital signatures
are used to sign certificates and certificate revocation lists.
This specification was created by combining Section 7, Cryptographic
Support, from RFC 2459 with the Internet-Draft "Representation of
Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and
Signatures in Internet X.509 Public Key Infrastructure Certificates".
This specification is a companion to lists
(CRLs). Certificates include the "son of 2459";
implementations must also conform to "son public key of 2459". This document
does not define the cryptographic algorithms themselves; instead, it
references other appropriate standards. named subject.

Bassham, Housley & Polk [Page 1]

INTERNET DRAFT July 14, 2000

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.

Please send comments on this document to the ietf-pkix@imc.org mail
list.

Bassham, Housley & Polk [Page 2]

INTERNET DRAFT July 14, November, 2000

Table of Contents

1 Executive Summary ........................................... 4
2 Requirements and Assumptions ................................ 4
2.1 Communication and Topology ................................ 4
2.2 Acceptability Criteria .................................... 4
2.3 User Expectations ......................................... 5
2.4 Administrator Expectations ................................ 5 Introduction ................................................ 3
2 Algorithm Support ........................................... 5
3.1 3
2.1 One-Way Hash Functions .................................... 6
3.1.1 4
2.1.1 MD2 One-Way Hash Functions .............................. 6
3.1.2 4
2.1.2 MD5 One-Way Hash Functions .............................. 6
3.1.3 4
2.1.3 SHA-1 One-Way Hash Functions ............................ 6
3.2 4
2.2 Signature Algorithms ...................................... 7
3.2.1 5
2.2.1 RSA Signature Algorithm ................................. 7
3.2.2 5
2.2.2 DSA Signature Algorithm ................................. 8
3.2.3 6
2.2.3 Elliptic Curve Digital Signature Algorithm .............. 9
3.3 7
2.3 Subject Public Key Algorithms ............................. 10
3.3.1 7
2.3.1 RSA Keys ................................................ 11
3.3.2 8
2.3.2 DSA Signature Keys ...................................... 9
2.3.3 Diffie-Hellman Key Exchange Keys ........................ 12
3.3.3 DSA Signature Keys ...................................... 13
3.3.4 10
2.3.4 KEA Public Keys ......................................... 14
3.3.5 Elliptic Curve 12
2.3.5 ECDSA and ECDH Public Keys .............................. 22
4 13
3 ASN.1 Module ................................................ 19
5 18
4 References .................................................. 23
5 Security Considerations ..................................... 24
6 Intellectual Property Rights ................................ 25
7 Security Considerations ..................................... 26
8 Intellectual Property Rights ................................ 26
9 Author Addresses ............................................ 27
10 25
8 Full Copyright Statement ................................... 27 .................................... 26

Bassham, Housley & Polk [Page 3] 2]

INTERNET DRAFT July 14, November, 2000

1 Executive Summary

This document specifies encoding formats for digital signatures and
public keys in Internet Public 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 encoding for-
mats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (IPKI) certificates
and CRLs. (PKI). This specification is an addendum to RFC 2459,
supplements [RFC XXXX], "Internet Public Key Infrastructure: X.509
Certificate and CRL Profile". Implementations of this specification
must also conform to RFC 2459.
Implementations of this specification are not required to conform to
other parts from that series. XXXX.

This specification defines the contents of the signatureAlgorithm,
signatureValue, signature signature, and subjectPublicKeyInfo fields in IPKI within
Internet X.509 certificates and CRLs when using common cryptographic algorithms. CRLs.

This document identifies secure one-way hash algorithms functions for use in the gen-
eration of digital signatures in IPKI certificates and CRLs. signatures. These algorithms are used in conjunction conjunc-
tion with digital signature algorithms.

This specification describes the encoding of digital signatures gen-
erated with the following cryptographic algorithms: the Rivest-
Shamir-Adelman (RSA) algorithm, the
* Rivest-Shamir-Adelman (RSA);
* Digital Signature Algorithm
(DSA), (DSA); and the
* Elliptic Curve Digital Signature Algorithm (ECDSA).

This document specifies the contents of the subjectPublicKeyInfo
field and in Internet X.509 certificates. For each algorithm, the
appropriate alternatives for the the keyUsage extension in IPKI certificates. are provided.
This specifi-
cation specification describes encoding formats for public keys used
with the fol-
lowing following cryptographic algorithms: RSA, DSA, the Diffie-Hellman algo-
rithm,
* Rivest-Shamir-Adelman (RSA);
* Digital Signature Algorithm (DSA);
* Diffie-Hellman;
* Key Encryption Algorithm (KEA);
* Elliptic Curve Digital Signature Algorithm (ECDSA); and ECDSA.
* Elliptic Curve Diffie-Hellman (ECDH).

2 Requirements and Assumptions

The goal is to augment the X.509 certificate profile presented in Algorithm Support

This section describes cryptographic algorithms which may be used
with the Internet PKI X.509 Certificate certificate and CRL Profile.

2.1 Communication profile. The section
describes one-way hash functions and Topology

This profile, as presented in Part 1 digital signature algorithms
which may be used to sign certificates and augmented by this specifica-
tion, supports users without high bandwidth, real-time IP connec-
tivity, or high connection availability. In addition, the profile
allows CRLs, and identifies OIDs
for the presence of firewall or other filtered communication.

This profile does not assume the deployment of an X.500 Directory
system. The profile does not prohibit the use of an X.500 Directory,
but other means of distributing certificates public keys contained in a certificate.

Conforming CAs and certificate revoca-
tion lists (CRLs) applications are supported.

2.2 Acceptability Criteria

The goal of the Internet Public Key Infrastructure (PKI) is not required to meet support the needs of deterministic, automated identification, authentication,
access control, and authorization functions. Support for these

Bassham, Housley & Polk [Page 4] 3]

INTERNET DRAFT July 14, November, 2000

services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as
policy data and certification path constraints.

The goal of this document is to profile ECDSA certificates, specify-
ing the contents and semantics of attributes which were not fully
specified by Part 1. If not specifically addressed by this document,
the contents and semantics of the fields and extensions must be as
described in Part 1.

2.3 User Expectations

Users of the Internet PKI are people and processes who use client
software and are the subjects named in certificates. These uses
include readers and writers of electronic mail, the clients for WWW
browsers, WWW servers, and the key manager for IPSEC within a router.
This profile recognizes the limitations of the platforms these users
employ and the sophistication/attentiveness of the users themselves.
This manifests itself in minimal user configuration responsibility
(e.g., root keys, rules), explicit platform usage constraints within
the certificate, certification path constraints which shield the user
from many malicious actions, and applications which sensibly automate
validation functions.

2.4 Administrator Expectations

As with users, the Internet PKI profile is structured to support the
individuals who generally operate Certification Authorities (CAs).
Providing administrators with unbounded choices increases the chances
that a subtle CA administrator mistake will result in broad comprom-
ise or unnecessarily limit interoperability. This profile defines
the object identifiers and data formats that must be supported to
interpret ECDSA public keys.

3 Algorithm Support

This section describes cryptographic algorithms which may be used
with this profile. The section describes one-way hash functions and
digital signature

algorithms which may be used to sign certificates
and CRLs, and identifies OIDs for public keys contained in a certifi-
cate.

Conforming CAs and applications are not required to support the algo-
rithms or algorithm identifiers described in this section. However, How-
ever, conforming CAs and applications that use the algorithms identified identi-
fied here MUST support them as specified.

Bassham, Housley & Polk [Page 5]

INTERNET DRAFT July 14, 2000

3.1

2.1 One-way Hash Functions

This section identifies one-way hash functions for use in the Inter-
net X.509 PKI. One-way hash functions are also called message digest algo-
rithms.
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
this reason, MD2 and MD5 are included in this profile.

3.1.1

2.1.1 MD2 One-way Hash Function

MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Secu-
rity Security has not
recently placed the MD2 algorithm in the public domain. Rather, Previously,
RSA Data Security has had granted license to for use of MD2 for non-commercial non-
commercial Internet Privacy-Enhanced Mail. For this reason, 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 [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.

3.1.2

2.1.2 MD5 One-way Hash Function

MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Secu-
rity Security has
placed the MD5 algorithm in the public domain. MD5 produces a 128-bit 128-
bit "hash" of the input. MD5 is fully described in RFC 1321 [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.

3.1.3

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 [FIPS 180-1].

Bassham, Housley & Polk [Page 4]

INTERNET DRAFT November, 2000

SHA-1 is the one-way hash function of choice for use with the RSA,

Bassham, Housley & Polk [Page 6]

INTERNET DRAFT July 14, 2000
DSA, and ECDSA signature algorithms (see sec. 3.2).

3.2 algorithms.

2.2 Signature Algorithms

Certificates and CRLs described by this standard conforming to [RFC XXXX] 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 signa-
tureAlgorithm field in a within the Certificate or CertificateList. This
algorithm identifier is an OID and has optionally associated parame-
ters. This section identifies algorithm identifiers and parameters
that shall MUST be used in the signatureAlgorithm field in a Certificate or
CertificateList.

RSA and DSA are the most popular signature algorithms used in the
Internet.

Signature algorithms are always used in conjunction with a one-way
hash function.

The signature algorithm and one-way hash function used to sign a cer-
tificate or CRL is indicated by use of an algorithm identifier. An
algorithm identifier is an OID, and may include associated parame-
ters.

This section identifies OIDS for RSA RSA, DSA, and DSA. ECDSA. The contents
of the parameters component for each algorithm vary; details are pro-
vided 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 sig-
nature field.

3.2.1

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

The signature algorithm with MD2 and the RSA encryption algorithm is
defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, 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

Bassham, Housley & Polk [Page 7]

INTERNET DRAFT July 14, 2000
defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, PKCS #1 [RFC 2313], the
ASN.1 OID used to identify this signature algorithm is:

Bassham, Housley & Polk [Page 5]

INTERNET DRAFT November, 2000

md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 4 }

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. The following OID MUST be used to specify the SHA-1 one-
way hash function when performing the data encoding step:

id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 26 }

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 Algorith-
mIdentifier, the parameters component of that type shall SHALL be the ASN.1
type NULL.

The RSA signature generation process and the encoding of the result
is described in detail in RFC 2313.

3.2.2 PKCS #1 [RFC 2313].

2.2.2 DSA Signature Algorithm

The Digital Signature Algorithm (DSA) is defined in the Digital Sig-
nature 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 [FIPS 186]. The ASN.1 OIDs OID used to identify
this signature algorithm are: is:

id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }

Where

When the id-dsa-with-sha1 algorithm identifier appears as the algo-
rithm field in an AlgorithmIdentifier, the encoding shall SHALL omit the
parameters field. That is, the AlgorithmIdentifier shall be a

Bassham, Housley & Polk [Page 6]

INTERNET DRAFT November, 2000

SEQUENCE of one component - component: the OBJECT IDENTIFIER id-dsa-with-sha1.

The DSA parameters in the subjectPublicKeyInfo field of the certifi-
cate 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 SHALL be ASN.1 encoded using the fol-
lowing ASN.1 structure:

Bassham, Housley & Polk [Page 8]

INTERNET DRAFT July 14, 2000

Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }

3.2.3 Elliptic Curve Digital

2.2.3 ECDSA Signature Algorithm

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
the ANSI X9.62 standard
[X9.62]. The ASN.1 object identifiers used to identify the ECDSA algorithm are
defined in the following arc:

ansi-X9-62 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) 10045 }

When used to sign certificates, CRLs, or PKI messages, the

ECDSA
shall be is used in conjunction with the SHA-1 one-way hash algorithm. function.
The ASN.1 object iden-
tifier identifier used to identify the ECDSA algorithm with SHA-1 shall be: is:

id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }

When the ecdsa-with-SHA1 algorithm identifier is used in the SIGNED
parameterized TYPE (e.g., in the signature on a certificate or CRL)
it shall have NULL parameters. The ECDSA parameters in the certifi-
cate of the issuer shall apply to the verification of the signature.
MUST be NULL.

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 shall MUST be ASN.1 encoded using the fol-
lowing follow-
ing ASN.1 structure:

Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }

3.3

2.3 Subject Public Key Algorithms

Certificates described by this profile conforming to [RFC XXXX] 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.

Bassham, Housley & Polk [Page 7]

INTERNET DRAFT November, 2000

This section identifies preferred OIDs and parameters for the RSA,
DSA, Diffie-Hellman, KEA, ECDSA, and Diffie-Hellman ECDH algorithms. Conforming CAs shall
MUST use the identified OIDs when issuing certificates containing
public keys for these algorithms. Conforming applications supporting
any of these algorithms shall, MUST, at a minimum, recognize the OID identified identi-
fied in this section.

3.3.1

2.3.1 RSA Keys

Bassham, Housley & Polk [Page 9]

INTERNET DRAFT July 14, 2000

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 shall MUST
have ASN.1 type NULL for this algorithm identifier.

The RSA public key shall MUST be encoded using the ASN.1 type RSAPub-
licKey: 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
MAY be indicated in the key usage field (see sec. 4.2.1.3). [RFC XXXX]). The use of
a single key for both signature and encryption purposes is not
recommended, recom-
mended, 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 MAY be present:
digitalSignature;
nonRepudiation; keyEnci-
pherment;
keyEncipherment; and
dataEncipherment.

If the keyUsage extension is present in a CA certificate which conveys con-
veys an RSA public key, any combination of the following values may MAY
be present:
digitalSignature; nonRepudi-
ation;

Bassham, Housley & Polk [Page 8]

INTERNET DRAFT November, 2000

nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.

However, this specification RECOMMENDS that if keyCertSign or cRLSign
is present, both keyEncipherment and dataEncipherment should not SHOULD NOT be
present.

3.3.2 Diffie-Hellman Key Exchange Key

2.3.2 DSA Signature Keys

The Diffie-Hellman Digital Signature Algorithm (DSA) is defined in the Digital Sig-
nature Standard (DSS) [FIPS 186]. The DSA OID supported by this profile pro-
file is defined by ANSI
X9.42 [X9.42].

dhpublicnumber OBJECT IDENTIFIER

id-dsa ID ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) x9-57(10040)
x9cm(4) 1 }

The dhpublicnumber OID is intended id-dsa algorithm syntax includes optional domain parameters.
These parameters are commonly referred to as p, q, and g. When omit-
ted, the parameters component MUST be used in omitted entirely. That is, the algorithm field

Bassham, Housley & Polk [Page 10]

INTERNET DRAFT July 14, 2000

of
AlgorithmIdentifier MUST be a value SEQUENCE of type AlgorithmIdentifier. The one component: the OBJECT
IDENTIFIER id-dsa.

If the DSA domain parameters field of that
type, which has are present in the algorithm-specific syntax ANY DEFINED BY algo-
rithm, have subjectPublicKeyInfo
AlgorithmIdentifier, the parameters are included using the following
ASN.1 type GroupParameters for this algorithm.

DomainParameters structure:

Dss-Parms ::= 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
g INTEGER }

The fields of type DomainParameters have the following meanings:

p identifies

If the prime p defining DSA algorithm parameters are absent from the Galois field;

g specifies subjectPublicKey-
Info AlgorithmIdentifier and the generator of CA signed the multiplicative subgroup of order
g;

q specifies subject certificate
using DSA, then the prime factor of p-1;

j optionally specifies certificate issuer's DSA parameters apply to the value that satisfies
subject's DSA key. If the equation
p=jq+1 to support DSA domain parameters are absent from the optional verification of group parameters;

seed optionally specifies
subjectPublicKeyInfo AlgorithmIdentifier and the bit string parameter used as CA signed the
seed for sub-
ject certificate using a signature algorithm other than DSA, then the system parameter generation process;
subject's DSA domain parameters are distributed by other means. If
the subjectPublicKeyInfo AlgorithmIdentifier field omits the parame-
ters component and

pgenCounter optionally specifies the integer value output as part
of CA signed the of subject with a signature algo-
rithm other than DSA, then clients MUST reject the system parameter prime generation process. certificate.

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
within a certificate where the parameters may be used. If either of the parameter generation components (pgencounter or
seed) is provided, DSA

Bassham, Housley & Polk [Page 9]

INTERNET DRAFT November, 2000

domain parameters are absent from the subjectPublicKeyInfo Algorith-
mIdentifier and the CA signed the subject certificate using DSA, then
the certificate issuer's DSA domain parameters apply to the subject's
DSA key. If the DSA domain parameters are absent from the sub-
jectPublicKeyInfo AlgorithmIdentifier and the CA signed the certifi-
cate using a signature algorithm other than DSA, then clients shall be present
not validate the certificate.

When signing, DSA algorithm generates two values. These values are
commonly referred to as well. r and s. To easily transfer these two values
as one signature, they are ASN.1 encoded using the following ASN.1
structure:

Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }

The encoded signature is conveyed as the value of the BIT STRING sig-
nature in a Certificate or CertificateList.

The Diffie-Hellman DSA public key shall MUST be ASN.1 DER encoded as an INTEGER; this
encoding shall be used as the contents (i.e., the value) of the
subjectPublicKey sub-
jectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo SubjectPublicKeyInfo
data element.

DHPublicKey

DSAPublicKey ::= INTEGER -- public key, y = g^x mod p

If the keyUsage Y

The key usage extension is present MAY optionally appear in certificates which
convey a DSA public key. If a certificate which conveys containing a
DH DSA public key,
key includes the keyUsage extension, only the following values may be present: keyAgreement;
encipherOnly; and decipherOnly. At most one of encipherOnly
asserted:

digitalSignature;
nonRepudiation;
keyCertSign; and

Bassham, Housley & Polk [Page 11]

INTERNET DRAFT July 14, 2000

decipherOnly shall
cRLSign.

These values MAY be asserted in keyUsage extension.

3.3.3 DSA Signature Keys

The Digital Signature Algorithm (DSA) is defined in any combination. However, the Digital Sig-
nature Standard (DSS). key-
CertSign and cRLSign values MAY only be asserted if the basicCon-
straints extension is present and cA is TRUE.

2.3.3 Diffie-Hellman Key Exchange Keys

The DSA Diffie-Hellman OID supported by this profile is

id-dsa ID defined in
[X9.42].

dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57(10040)
x9cm(4) ansi-x942(10046) number-type(2) 1 }

Bassham, Housley & Polk [Page 10]

INTERNET DRAFT November, 2000

The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred dhpublicnumber OID is intended to as p, q, and g. When omitted,
the parameters component shall be omitted entirely. That is, used in the
AlgorithmIdentifier shall be algorithm field
of a SEQUENCE value of one component - the OBJECT
IDENTIFIER id-dsa.

If the DSA algorithm type AlgorithmIdentifier. The parameters are present in the subjectPublicKey-
Info AlgorithmIdentifier, field of that
type, which has the parameters are included using algorithm-specific syntax ANY DEFINED BY algo-
rithm, have the fol-
lowing ASN.1 structure:

Dss-Parms 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 {
p INTEGER,
q INTEGER,
g
seed BIT STRING,
pgenCounter INTEGER }

If the DSA algorithm parameters are absent from

The fields of type DomainParameters have the subjectPublicKey-
Info AlgorithmIdentifier and following meanings:

p identifies the CA signed prime p defining the subject certificate
using DSA, then Galois field;

g specifies the certificate issuer's DSA parameters apply to generator of the
subject's DSA key. If multiplicative subgroup of order
g;

q specifies the DSA algorithm parameters are absent from prime factor of p-1;

j optionally specifies the subjectPublicKeyInfo AlgorithmIdentifier and value that satisfies the CA signed equation
p=jq+1 to support the
subject certificate using a signature algorithm other than DSA, then optional verification of group parameters;

seed optionally specifies the subject's DSA parameters are distributed by other means. If bit string parameter used as the
subjectPublicKeyInfo AlgorithmIdentifier field omits
seed for the parameters
component domain parameter generation process; and

pgenCounter optionally specifies the CA signed the subject with a signature algorithm
other than DSA, then clients shall reject the certificate.

When signing, DSA algorithm generates two values. These values are
commonly referred to as r and s. To easily transfer these two values integer value output as one signature, they are ASN.1 encoded using part
of the following ASN.1
structure:

Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }

The encoded signature is conveyed as of the value domain parameter prime generation process.

If either of the BIT STRING sig-
nature in a Certificate domain parameter generation components (pgencounter
or CertificateList.

Bassham, Housley & Polk [Page 12]

INTERNET DRAFT July 14, 2000 seed) is provided, the other MUST be present as well.

The DSA Diffie-Hellman public key shall MUST be ASN.1 DER encoded as an INTEGER;
this encoding shall be used as the contents (i.e., the value) of the sub-
jectPublicKey the
subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo subjectPublicKeyInfo
data element.

DSAPublicKey

DHPublicKey ::= INTEGER -- public key, Y y = g^x mod p

If the keyUsage extension is present in an end entity a certificate which conveys a DSA
DH public key, any combination of the following values may be present: digitalSignature;
keyAgreement;
encipherOnly; and nonRepudiation.

Bassham, Housley & Polk [Page 11]

INTERNET DRAFT November, 2000

decipherOnly.

If present, the keyUsage extension is present in a CA certificate which con-
veys a DSA public key, any combination of the following values may be
present: digitalSignature; nonRepudiation; keyCertSign; MUST assert keyAgreement and cRLSign.

3.3.4 KEA Public Keys

The certificate identifies the KEA algorithm, conveys optional param-
eters, MAY
assert either encipherOnly and specifies the KEA public key in the subjectPublicKeyInfo
field. decipherOnly. The subjectPublicKeyInfo field is a SEQUENCE of an algorithm
identifier keyUsage extension
MUST NOT assert both encipherOnly and the subjectPublicKey field.

The certificate indicates the algorithm through an algorithm identif-
ier. decipherOnly.

2.3.4 KEA Public Keys

This algorithm identifier consists of an object identifier
(OID) and optional associated parameters. Section 3.1.1 section identifies the preferred OID and parameters for the
inclusion of a KEA algorithm. public key in a certificate. Conforming CAs shall MUST
use the identified OID when issuing certificates containing public
keys for the KEA algorithm. Conforming applications supporting the
KEA algorithm shall, MUST, at a minimum, recognize the OID identified in section 3.1.1.

The certificate conveys the KEA public key through the subjectPub-
licKey field. This subjectPublicKey field is a BIT STRING. Section
3.1.2 specifies the method for encoding a KEA public key as a BIT
STRING. Conforming CAs shall encode the KEA public key as described
in Section 3.1.2 when issuing certificates containing public keys for
the KEA algorithm. Conforming applications supporting the KEA algo-
rithm shall decode the subjectPublicKey as described in section 3.1.2
when the algorithm identifier is the one presented in 3.1.1.
this section.

The Key Exchange Algorithm (KEA) is a classified algorithm for
exchanging keys. A KEA key agreement algorithm. Two
parties may generate a "pairwise key" may be generated between two
users if their KEA public keys were generated with and only if they share the
same KEA parameters. The KEA parameters are not included in a certificate; certi-
ficate; instead a "domain identifier" domain identifier is supplied in the parameters
field.

When the subjectPublicKeyInfo field contains a KEA key, the algorithm

Bassham, Housley & Polk [Page 13]

INTERNET DRAFT July 14, 2000
identifier and parameters shall be as defined in [sdn.701r]: [SDN.701r]:

id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 1 22 }

KEA-Parms-Id ::= OCTET STRING

CAs shall 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 will be
computed is com-
puted in three steps: (1)

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

Bassham, Housley & Polk [Page 12]

INTERNET DRAFT November, 2000

Parms is provided above in [RFC 2459] and reproduced below for com-
pleteness.

Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER } 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, tag;
BIT STRING length, length;
0 (indicating that there are zero unused bits in the final octet
of y), 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 fol-
lowing values may be asserted:

keyAgreement;
encipherOnly; and
decipherOnly.

The encipherOnly and decipherOnly values may only be asserted if

If present, the keyUsage extension MUST assert keyAgreement value is also asserted. At most one of and MAY
assert either encipherOnly and
decipherOnly shall be asserted in decipherOnly. The keyUsage extension.

Bassham, Housley & Polk [Page 14]

INTERNET DRAFT July 14, 2000

3.3.5 Elliptic Curve extension
MUST NOT assert both encipherOnly and decipherOnly.

2.3.5 ECDSA and ECDH Keys

This section describes object identifiers identifies the preferred OID and data formats which may
be used with PKIX certificate profile to describe X.509 certificates
containing parameter encoding for
the inclusion of an ECDSA or ECDH public key or signed with ECDSA. Conforming in a certificate. Con-
forming CAs
are required to MUST use the these object identifiers and data formats when
issuing certificates conveying an ECDSA certificates. Conforming or ECDH public key. Conform-
ing applications shall MUST recognize the object identifiers and process
the data formats when processing such certificates.

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
the ANSI X9.62 standard
[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 mathemetical analog of the
Diffie-Hellman key agreement algorithm as specified in [X9.42].
These specifications use the same OIDs and parameter encodings. The
ASN.1 object identifiers used to identify the ECDSA algorithm these public keys are
defined in the following arc:

ansi-X9-62 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) 10045 }

Bassham, Housley & Polk [Page 13]

INTERNET DRAFT November, 2000

When certificates contain an ECDSA or ECDH public key, the id-ecPublicKey id-
ecPublicKey algorithm identifier shall 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 } 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 XXXX]). The use of
a single key for both signature and encryption purposes is not recom-
mended, but is not forbidden.

ECDSA requires 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 }

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 an object identifier. When the parameters are
explicitly included, they shall be encoded in the ASN.1 structure
ECParameters:

Bassham, Housley & Polk [Page 15]

INTERNET DRAFT July 14, 2000

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,

Bassham, Housley & Polk [Page 14]

INTERNET DRAFT November, 2000

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, [X9.62], Section
4.3.1]
4.3.1. The value of ECPoint shall be the octet string representation
of an elliptic curve point following the conversion routine in
[X9.62,
[X9.62], Section 4.4.3.b] 4.4.3.b.

The components of type ECParameters have the following meanings:

version specifies the version number of the elliptic curve parame-
ters. It shall MUST have the value 1 for this version of the specifica-
tion. The notation above creates an INTEGER named ecpVer1 and gives
it a value of one. It is used to constrain version to a single value.

* (ecpVer1).

fieldID identifies the finite field over which the elliptic curve
is defined. Finite fields are represented by values of the parameter-
ized
parameterized type FieldID, constrained to the values of the
objects defined in the information object set FieldTypes. Additional Addi-
tional detail regarding fieldID is provided below.

curve specifies the coefficients a and b of the elliptic curve E.
Each coefficient shall be represented as a value of type FieldEle-
ment, an OCTET STRING. seed is an optional parameter used to
derive the coefficients of a randomly generated elliptic curve.

Bassham, Housley & Polk [Page 16]

INTERNET DRAFT July 14, 2000

base specifies the base point P on the elliptic curve. The base
point shall be 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. Note: This optional parameter is not used specified
as OPTIONAL. However, the cofactor MUST be included in ECDH pub-
lic 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 vali-
dation
validation is not required by this specification. It is included for
compatibility with Elliptic Curve Key Agreement public key parame-
ters, and to support parameter validation.

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
within a certificate where the parameters may be used. If the ECDSA
algorithm ellip-
tic curve parameters are absent from specified as implicitlyCA in the subjectPublicKeyInfo Algor-
ithmIdentifier subjectPub-
licKeyInfo AlgorithmIdentifier and the CA signed the subject certificate certifi-
cate using ECDSA, then the certificate issuer's ECDSA parameters
apply to the subject's ECDSA key. If the ECDSA algorithm elliptic curve parameters

Bassham, Housley & Polk [Page 15]

INTERNET DRAFT November, 2000

are absent from specified as implicitlyCA in the subjectPublicKeyInfo AlgorithmIdentifier Algorith-
mIdentifier and the CA signed the certi-
ficate certificate using a signature algorithm algo-
rithm other than ECDSA, then clients
shall MUST not validate make use of the certificate. ellip-
tic curve public key.

FieldID ::= SEQUENCE { -- Finite field
fieldType OBJECT IDENTIFIER,
parameters ANY DEFINED BY fieldType
}

FieldID is a SEQUENCE of two components, fieldType and parameters.
In an instance of FieldID, "fieldType" will contain
The fieldType contains an object iden-
tifier identifier value that uniquely identifies iden-
tifies the type contained in "parame-
ters". The effect of referencing "fieldType" in both components of
the fieldID sequence is to tightly bind the object identifier and its
type. parameters.

The object identifier id-fieldType represents the root of a tree con-
taining specifies an arc containing the
object identifiers of each field type. It has the follow-
ing following value:

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

The object identifiers prime-field and characteristic-two-field name
the two kinds of fields defined in this Standard. They have the fol-
lowing values:

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

Prime-p ::= INTEGER -- Field size p (p in bits)

Bassham, Housley & Polk [Page 17]

INTERNET DRAFT July 14, 2000 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 represents the root
of a tree 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 }

Bassham, Housley & Polk [Page 16]

INTERNET DRAFT November, 2000

-- for gnBasis, the value of the paramters 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
}

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, etc.; and the least significant bit of the OCTET STRING
becomes the least significant bit of the BIT STRING.

The key usage extension may optionally appear in certificates which
convey an ECDSA public key. If a certificate containing an ECDSA
public key includes the keyUsage extension, only the following values

Bassham, Housley & Polk [Page 18]

INTERNET DRAFT July 14, 2000
may be asserted:

digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.

The keyCertSign

These values MAY be asserted in any combination. However, the key-
CertSign and cRLSign values may MAY only be asserted if the
basicConstraints basicCon-
straints extension is present and cA is TRUE.

The key usage extension may optionally appear in certificates which
convey an ECDH public key. If a certificate containing an ECDH pub-
lic key includes the keyUsage extension, only the following values
may be asserted:

keyAgreement;
encipherOnly; and
decipherOnly.

If present, the keyUsage extension MUST assert keyAgreement and MAY

Bassham, Housley & Polk [Page 17]

INTERNET DRAFT November, 2000

assert either encipherOnly and decipherOnly. The keyUsage extension
MUST NOT assert both encipherOnly and decipherOnly.

3 ASN.1 Module

PKIX1Algorithms88 { tbd }

DEFINITIONS EXPLICIT TAGS ::= BEGIN

-- EXPORTS All;

-- IMPORTS NONE;

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

Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }

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

Bassham, Housley & Polk [Page 19]

INTERNET DRAFT July 14, 2000
---- RSA Keys and Signatures
----
----

-- arc for RSA public key and RSA signature OIDs

pkcs-1 OBJECT IDENTIFIER ::= {

Bassham, Housley & Polk [Page 18]

INTERNET DRAFT November, 2000

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 }

sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }

----
---- Diffie-Hellman Keys
----
----

dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

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

Bassham, Housley & Polk [Page 20]

INTERNET DRAFT July 14, 2000

id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
{ 2 16 840 1 101 2 1 1 22 }

KEA-Parms-Id ::= OCTET STRING

----

Bassham, Housley & Polk [Page 19]

INTERNET DRAFT November, 2000

---- ECDSA 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
}

-- ECDSA signatures

-- Arc for ECDSA signature OIDS

id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }

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

Bassham, Housley & Polk [Page 21]

INTERNET DRAFT July 14, 2000
-- of type Characteristic-two

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

Characteristic-two ::= SEQUENCE {
m INTEGER, -- Field size 2^m
basis OBJECT IDENTIFIER,

Bassham, Housley & Polk [Page 20]

INTERNET DRAFT November, 2000

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 }

-- 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 ::= SEQUENCE {
--
-- Pentanomial basis representation of F2^m
-- reduction polynomial integers k1, k2, k3
-- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
--
k1 INTEGER,
k2 INTEGER,
k3 INTEGER
}

Bassham, Housley & Polk [Page 22]

INTERNET DRAFT July 14, 2000

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

Bassham, Housley & Polk [Page 21]

INTERNET DRAFT November, 2000

-- Elliptic Curve parameters may be specfied 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)}

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
--
-- Standards bodies may define OIDs to represent common
-- elliptic curve parameters. Users are encouraged
-- to consult relevant standards and specifications to
-- determine which OIDs (if any) are appropriate for their
-- applications.

-- The following OIDS are defined in ANSI X9.62.

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

Bassham, Housley & Polk [Page 23]

INTERNET DRAFT July 14, 2000

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

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

c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 }

Bassham, Housley & Polk [Page 22]

INTERNET DRAFT November, 2000

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 }

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

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] Federal Information Processing Standards Publication
(FIPS PUB) 186, Digital Signature Standard, 18 May 1994.

[P1363] IEEE P1363, "Standard for Public-Key Cryptography", draft
standard, 1997.

Bassham, Housley & Polk [Page 24]

INTERNET DRAFT July 14, 2000

[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] P.V. Mockapetris, "Domain names - concepts and
facilities", November 1987.

Bassham, Housley & Polk [Page 23]

INTERNET DRAFT November, 2000

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

[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
MIT and RSA Data Security, April 1992.

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

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

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

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

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

[SDN.701]

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

[X9.42] ANSI X9.42-199x, Public X9.42-2000, "Public Key Cryptography for The Financial
Services Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
Discrete Logarithm Cryptography" (Working Draft), December 1997.
December, 1999.

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

[X9.63] ANSI X9.63-199x, "Public Key Cryptography For The Financial
Services Industry: Key Agreement and Key Transport
Using Elliptic Curve Cryptography" (Working Draft).

6 Intellectual Property Rights

The IETF has been notified Security Considerations

This specification does not constrain the size of intellectual property rights claimed in
regard to some public keys or all of the specification contained
their parameters for use in this docu-
ment. For more information, consult the online list of claimed Internet PKI. However, the key size

Bassham, Housley & Polk [Page 25] 24]

INTERNET DRAFT July 14, November, 2000

rights.

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain 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

selected impacts the result strength achieved when implementing crypto-
graphic services. Selection of an attempt made appropriate key sizes is critical 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 Security Considerations
implementing appropriate security.

This specification does not constrain the key sizes or identify par-
ticular particular elliptic curves for
use in the Internet PKI. However, both
the key size and the particular curve selected
impact the 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 D.4, "Key Length Considerations" and Appendix
F.1, "Avoiding Cryptographically Weak Keys".

This specification is a profile of RFC 2459. XXXX. The security considera-
tions 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 docu-
ment. For more information consult the online list of claimed
rights.

Bassham, Housley & Polk [Page 26]

INTERNET DRAFT July 14, 2000
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:

Larry Bassham
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
lbassham@nist.gov

Russ Housley

Bassham, Housley & Polk [Page 25]

INTERNET DRAFT November, 2000

SPYRUS
381 Elden Street
Suite 1120
Herndon, VA 20170
housley@spyrus.com

Tim Polk
NIST
100 Bureau Drive, Stop 8930
Gaithersburg, MD 20899-8930
USA
tim.polk@nist.gov

8 Full Copyright Statement

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. In addition, the
ASN.1 modules presented in Appendices A and B may be used in whole or
in part without inclusion of the copyright notice. 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 develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process shall be followed, or as
required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be

Bassham, Housley & Polk [Page 27]

INTERNET DRAFT July 14, 2000
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.

Bassham, Housley & Polk [Page 28] 26]

----