|
Network Working Group Request for Comments: 2314 Category: Informational |
B. Kaliski RSA Laboratories East March 1998 |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (1998). All Rights Reserved.
This document describes a syntax for certification requests.
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 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.
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 Kaliski, B., "Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services," RFC 1424,
February 1993.
X.208 CCITT. Recommendation X.208: Specification of
Abstract Syntax Notation One (ASN.1). 1988.
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.
No symbols or abbreviations are defined in this document.
The next section specifies certification request syntax.
This document exports one type, CertificationRequest.
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 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:
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.
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 meanings:
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:
The signature process consists of two steps:
Note. The syntax for CertificationRequest could equivalently be written with the X.509 SIGNED macro:
CertificationRequest ::= SIGNED CertificateRequestInfo
Security issues are discussed throughout this memo.
Version 1.0
Version 1.0 is the initial version.
This document is based on a contribution of 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".
Burt Kaliski
RSA Laboratories East
20 Crosby Drive
Bedford, MA 01730
Phone: (617) 687-7000
EMail: burt@rsa.com
Copyright © The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.