Internet Draft Burt Kaliski
Expires March 16, 1998
<draft-hoffman-pkcs-certif-req-02.txt>
PKCS #10: Certification Request Syntax
Version 1.5
Status of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Overview
This document describes a syntax for certification requests.
1. Scope
A certification request consists of a distinguished name, a public
key, and optionally a set of attributes, collectively signed by the
entity requesting certification. Certification requests are sent to a
certification authority, who transforms the request to an X.509
public-key certificate, or a PKCS #6 extended certificate. (In what
form the certification authority returns the newly signed certificate
is outside the scope of this document. A PKCS #7 message is one
possibility.)
The intention of including a set of attributes is twofold: to provide
other information about a given entity, such as the postal address to
which the signed certificate should be returned if electronic mail is
not available, or a "challenge password" by which the entity may
Burt Kaliski [Page 1]
RFC nnn PKCS #10: Certification Request Syntax November 1993
later request certificate revocation; and to provide attributes for a
PKCS #6 extended certificate. A non-exhaustive list of attributes is
given in PKCS #9.
Certification authorities may also require non-electronic forms of
request and may return non-electronic replies. It is expected that
descriptions of such forms, which are outside the scope of this
document, will be available from the certification authority.
The preliminary intended application of this document is to support
PKCS #7 cryptographic messages, but is expected that other
applications will be developed.
2. References
PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption
Standard. Version 1.5, November 1993.
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
Syntax. Version 1.5, November 1993.
PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message
Syntax. Version 1.5, November 1993.
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
Types. Version 1.1, November 1993.
RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services. February 1993.
X.208 CCITT. Recommendation X.208: Specification of
Abstract Syntax Notation One (ASN.1). 1988.
X.209 CCITT. Recommendation X.209: Specification of
Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1). 1988.
X.500 CCITT. Recommendation X.500: The Directory--
Overview of Concepts, Models and
Services. 1988.
X.501 CCITT. Recommendation X.501: The Directory--
Models. 1988.
X.509 CCITT. Recommendation X.509: The Directory--
Authentication Framework. 1988.
Burt Kaliski [Page 2]
RFC nnn PKCS #10: Certification Request Syntax November 1993
3. Definitions
For the purposes of this document, the following definitions apply.
AlgorithmIdentifier: A type that identifies an algorithm (by object
identifier) and any associated parameters. This type is defined in
X.509.
Attribute: A type that contains an attribute type (specified by
object identifier) and one or more attribute values. This type is
defined in X.501.
ASN.1: Abstract Syntax Notation One, as defined in X.208.
BER: Basic Encoding Rules, as defined in X.209.
Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. This type is defined in X.509.
This type also contains the distinguished name of the certificate
issuer (the signer), an issuer- specific serial number, the issuer's
signature algorithm identifier, and a validity period.
DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,
Section 8.7.
Name: A type that uniquely identifies or "distinguishes" objects in a
X.500 directory. This type is defined in X.501. In an X.509
certificate, the type identifies the certificate issuer and the
entity whose public key is certified.
4. Symbols and abbreviations
No symbols or abbreviations are defined in this document.
5. General overview
The next section specifies certification request syntax.
This document exports one type, CertificationRequest.
6. Certification request syntax
This section gives the syntax for certification requests.
A certification request consists of three parts: "certification
request information," a signature algorithm identifier, and a digital
signature on the certification request information. The certification
request information consists of the entity's distinguished name, the
Burt Kaliski [Page 3]
RFC nnn PKCS #10: Certification Request Syntax November 1993
entity's public key, and a set of attributes providing other
information about the entity.
The process by which a certification request is constructed involves
the following steps:
1. A CertificationRequestInfo value containing a
distinguished name, a public key, and optionally a
set of attributes is constructed by an entity.
2. The CertificationRequestInfo value is signed with
the entity's private key. (See Section 6.2.)
3. The CertificationRequestInfo value, a signature
algorithm identifier, and the entity's signature
are collected together into a CertificationRequest
value, defined below.
A certification authority fulfills the request by verifying the
entity's signature, and, if it is valid, constructing a X.509
certificate from the distinguished name and public key, as well as an
issuer name, serial number, validity period, and signature algorithm
of the certification authority's choice. If the certification request
contains a PKCS #9 extended-certificate-attributes attribute, the
certification authority also constructs a PKCS #6 extended
certificate from the X.509 certificate and the extended- certificate-
attributes attribute value.
In what form the certification authority returns the new certificate
is outside the scope of this document. One possibility is a PKCS #7
cryptographic message with content type signedData, following the
degenerate case where there are no signers. The return message may
include a certification path from the new certificate to the
certification authority. It may also include other certificates such
as cross-certificates that the certification authority considers
helpful, and it may include certificate-revocation lists (CRLs).
Another possibility is that the certification authority inserts the
new certificate into a central database.
This section is divided into two parts. The first part describes the
certification-request-information type CertificationRequestInfo, and
the second part describes the top-level type CertificationRequest.
Notes.
1. An entity would typically send a certification
request after generating a public-key/private-key
Burt Kaliski [Page 4]
RFC nnn PKCS #10: Certification Request Syntax November 1993
pair, but may also do so after a change in the
entity's distinguished name.
2. The signature on the certification request
prevents an entity from requesting a certificate
with another party's public key. Such an attack
would give the entity the minor ability to pretend
to be the originator of any message signed by the
other party. This attack is significant only if
the entity does not know the message being signed,
and the signed part of the message does not
identify the signer. The entity would still not be
able to decrypt messages intended for the other
party, of course.
3. How the entity sends the certification request to
a certification authority is outside the scope of
this document. Both paper and electronic forms are
possible.
4. This document is not compatible with the
certification request syntax for Privacy-Enhanced
Mail, as described in RFC 1424. The syntax in this
document differs in three respects: It allows a
set of attributes; it does not include issuer
name, serial number, or validity period; and it
does not require an "innocuous" message to be
signed. The syntax in this document is designed to
minimize request size, an important constraint for
those certification authorities accepting requests
on paper.
6.1 CertificationRequestInfo
Certification request information shall have ASN.1 type
CertificationRequestInfo:
CertificationRequestInfo ::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes }
Version ::= INTEGER
Attributes ::= SET OF Attribute
The fields of type CertificationRequestInfo have the following
Burt Kaliski [Page 5]
RFC nnn PKCS #10: Certification Request Syntax November 1993
meanings:
o version is the version number, for compatibility
with future revisions of this document. It shall
be 0 for this version of the document.
o subject is the distinguished name of the
certificate subject (the entity whose public key
is to be certified).
o subjectPublicKeyInfo contains information about
the public key being certified. The information
identifies the entity's public-key algorithm (and
any associated parameters); examples of public-key
algorithms include X.509's rsa and PKCS #1's
rsaEncryption. The information also includes a bit-
string representation of the entity's public key.
For both public-key algorithms just mentioned, the
bit string contains the BER encoding of a value of
X.509/PKCS #1 type RSAPublicKey.
o attributes is a set of attributes providing
additional information about the subject of the
certificate. Some attribute types that might be
useful here are defined in PKCS #9. An example is
the challenge-password attribute, which specifies
a password by which the entity may request that
the certificate revocation. Another example is the
extended-certificate-attributes attribute, which
specifies attributes for a PKCS #6 extended
certificate.
6.2 CertificationRequest
A certification request shall have ASN.1 type CertificationRequest:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Signature ::= BIT STRING
The fields of type CertificationRequest have the following meanings:
o certificateRequestInfo is the "certification
Burt Kaliski [Page 6]
RFC nnn PKCS #10: Certification Request Syntax November 1993
request information." It is the value being
signed.
o signatureAlgorithm identifies the signature
algorithm (and any associated parameters) under
which the certification-request information is
signed. Examples include PKCS #1's
md2WithRSAEncryption and md5WithRSAEncryption.
o signature is the result of signing the
certification request information with the
certification request subject's private key.
The signature process consists of two steps:
1. The value of the certificationRequestInfo field is
DER encoded, yielding an octet string.
2. The result of step 1 is signed with the
certification request subject's private key under
the specified signature algorithm, yielding a bit
string, the signature.
Note. The syntax for CertificationRequest could equivalently be
written with the X.509 SIGNED macro:
CertificationRequest ::= SIGNED CertificateRequestInfo
Revision history
Version 1.0
Version 1.0 is the initial version.
Copyright
Copyright (c) 1991-1993 RSA Laboratories, a division of RSA Data
Security, Inc. Any substantial use of the text from this document
must acknowledge RSA Data Security, Inc. RSA Data Security, Inc.
requests that all material mentioning or referencing this document
identify this as "RSA Data Security, Inc. PKCS #10".
Author's Address
Burt Kaliski
RSA Laboratories East
20 Crosby Drive
Burt Kaliski [Page 7]
RFC nnn PKCS #10: Certification Request Syntax November 1993
Bedford, MA 01730
(617) 687-7000
burt@rsa.com
Burt Kaliski [Page 8]