Network Working Group W. Polk
Request for Comments: 3279 NIST
Obsoletes: 2528 R. Housley
Category: Standards Track RSA Laboratories
L. Bassham
NIST
April 2002
Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI). Digital signatures
are used to sign certificates and certificate revocation list (CRLs).
Certificates include the public key of the named subject.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2 Algorithm Support . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Way Hash Functions . . . . . . . . . . . . . . . . 3
2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . . 3
2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . . 4
2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . . 4
2.2 Signature Algorithms . . . . . . . . . . . . . . . . . 4
2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . . 5
2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . . 6
2.2.3 Elliptic Curve Digital Signature Algorithm . . . . . 7
2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 7
2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . . 9
2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . . 10
Polk, et al. Standards Track [Page 1]
RFC 3279 Algorithms and Identifiers April 2002
2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . . 11
2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . . 13
3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 18
4 References . . . . . . . . . . . . . . . . . . . . . . . 24
5 Security Considerations . . . . . . . . . . . . . . . . . 25
6 Intellectual Property Rights . . . . . . . . . . . . . . 26
7 Author Addresses . . . . . . . . . . . . . . . . . . . . 26
8 Full Copyright Statement . . . . . . . . . . . . . . . . 27
1 Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
This document specifies algorithm identifiers and ASN.1 [X.660]
encoding formats for digital signatures and subject public keys used
in the Internet X.509 Public Key Infrastructure (PKI). This
specification supplements [RFC 3280], "Internet X.509 Public Key
Infrastructure: Certificate and Certificate Revocation List (CRL)
Profile." Implementations of this specification MUST also conform to
RFC 3280.
This specification defines the contents of the signatureAlgorithm,
signatureValue, signature, and subjectPublicKeyInfo fields within
Internet X.509 certificates and CRLs.
This document identifies one-way hash functions for use in the
generation of digital signatures. These algorithms are used in
conjunction with digital signature algorithms.
This specification describes the encoding of digital signatures
generated with the following cryptographic algorithms:
* Rivest-Shamir-Adelman (RSA);
* Digital Signature Algorithm (DSA); and
* Elliptic Curve Digital Signature Algorithm (ECDSA).
This document specifies the contents of the subjectPublicKeyInfo
field in Internet X.509 certificates. For each algorithm, the
appropriate alternatives for the the keyUsage extension are provided.
This specification describes encoding formats for public keys used
with the following cryptographic algorithms:
* Rivest-Shamir-Adelman (RSA);
* Digital Signature Algorithm (DSA);
* Diffie-Hellman (DH);
* Key Encryption Algorithm (KEA);
Polk, et al. Standards Track [Page 2]
RFC 3279 Algorithms and Identifiers April 2002
* Elliptic Curve Digital Signature Algorithm (ECDSA); and
* Elliptic Curve Diffie-Hellman (ECDH).
2 Algorithm Support
This section describes cryptographic algorithms which may be used
with the Internet X.509 certificate and CRL profile [RFC 3280]. This
section describes one-way hash functions and digital signature
algorithms which may be used to sign certificates and CRLs, and
identifies object identifiers (OIDs) for public keys contained in a
certificate.
Conforming CAs and applications MUST, at a minimum, support digital
signatures and public keys for one of the specified algorithms. When
using any of the algorithms identified in this specification,
conforming CAs and applications MUST support them as described.
2.1 One-way Hash Functions
This section identifies one-way hash functions for use in the
Internet X.509 PKI. One-way hash functions are also called message
digest algorithms. SHA-1 is the preferred one-way hash function for
the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC
1422] [RFC 1423] and MD5 is used in other legacy applications. For
these reasons, MD2 and MD5 are included in this profile. The data
that is hashed for certificate and CRL signing is fully described in
[RFC 3280].
2.1.1 MD2 One-way Hash Function
MD2 was developed by Ron Rivest for RSA Security. RSA Security has
recently placed the MD2 algorithm in the public domain. Previously,
RSA Data Security had granted license for use of MD2 for non-
commercial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to
be used with PEM certificates, but SHA-1 is preferred. MD2 produces
a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319].
At the Selected Areas in Cryptography '95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find
collisions [RC95]. Collisions occur when one can find two different
messages that generate the same message digest. A checksum operation
in MD2 is the only remaining obstacle to the success of the attack.
For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as
the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value.
Polk, et al. Standards Track [Page 3]
RFC 3279 Algorithms and Identifiers April 2002
2.1.2 MD5 One-way Hash Function
MD5 was developed by Ron Rivest for RSA Security. RSA Security has
placed the MD5 algorithm in the public domain. MD5 produces a 128-
bit "hash" of the input. MD5 is fully described in [RFC 1321].
Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
but there are no other known cryptanalytic results. The use of MD5
for new applications is discouraged. It is still reasonable to use
MD5 to verify existing signatures.
2.1.3 SHA-1 One-way Hash Function
SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit
"hash" of the input. SHA-1 is fully described in [FIPS 180-1]. RFC
3174 [RFC 3174] also describes SHA-1, and it provides an
implementation of the algorithm.
2.2 Signature Algorithms
Certificates and CRLs conforming to [RFC 3280] may be signed with any
public key signature algorithm. The certificate or CRL indicates the
algorithm through an algorithm identifier which appears in the
signatureAlgorithm field within the Certificate or CertificateList.
This algorithm identifier is an OID and has optionally associated
parameters. This section identifies algorithm identifiers and
parameters that MUST be used in the signatureAlgorithm field in a
Certificate or CertificateList.
Signature algorithms are always used in conjunction with a one-way
hash function.
This section identifies OIDS for RSA, DSA, and ECDSA. The contents
of the parameters component for each algorithm vary; details are
provided for each algorithm.
The data to be signed (e.g., the one-way hash function output value)
is formatted for the signature algorithm to be used. Then, a private
key operation (e.g., RSA encryption) is performed to generate the
signature value. This signature value is then ASN.1 encoded as a BIT
STRING and included in the Certificate or CertificateList in the
signature field.
Polk, et al. Standards Track [Page 4]
RFC 3279 Algorithms and Identifiers April 2002