PKCS10 文档.doc-资料库

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第1页.png

第1页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第2页.png

第2页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第3页.png

第3页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第4页.png

第4页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第5页.png

第5页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第6页.png

第6页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第7页.png

第7页 / 共29页

lixiaoshuangzyl-10492920-16359647351827216257.doc.pdf-第8页.png

第8页 / 共29页

Network Working Group Request for Comments: 2986 Obsoletes: 2314 Category: Informational M. Nystrom B. Kaliski RSA Security November 2000 PKCS #10: Certification Request Syntax Specification Version 1.7 Status of this Memo 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 Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo describes a syntax for certification requests. Table of Contents Introduction ................................................. 2 1. 2. Definitions and notation ..................................... 2 2.1 Definitions ................................................. 2 2.2 Notation .................................................... 4 Overview ..................................................... 4 3. 4. Certification request syntax ................................. 5 4.1 CertificationRequestInfo .................................... 5 4.2 CertificationRequest ........................................ 7 Security Considerations ...................................... 8 5. 6. Authors' Addresses ........................................... 8 ASN.1 module ................................................. 9 A. B. Intellectual property considerations ........................ 10

Revision history ............................................ 10 C. References .................................................. 11 D. E. Contact information & About PKCS ............................ 12 Full Copyright Statement ........................................ 14 Nystrom & Kaliski Informational [Page 1]

RFC 2986 Certification Request Syntax Specification November 2000 1. Introduction A Certification requests are sent to a This document describes syntax for certification requests. certification request consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. certification authority, which transforms the request into an X.509 [9] public-key certificate. (In what form the certification authority returns the newly signed certificate is outside the scope of this document. A PKCS #7 [2] message is one possibility.) The intention of including a set of attributes is twofold: to provide other information about a given entity , or a "challenge password" by which the entity may later request certificate revocation; and to provide attributes for inclusion in X.509 certificates. exhaustive list of attributes is given in PKCS #9 [3]. A non- 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 certification authorities. The preliminary intended application of this document is to support PKCS #7 cryptographic messages, but it is expected that other applications will be developed (see e.g. [4]). 2. Definitions and notation 2.1 Definitions For the purposes of this document, the following definitions apply. ALGORITHM An information object class defined in X.509 to describe objects composed of an algorithm (a unique object identifier) and its parameters (any ASN.1 type). represented by the ASN.1 type AlgorithmIdentifier{}. ALGORITHM is defined as the "useful" information object class TYPE-IDENTIFIER, specified in [11], Annex A. The values of objects in this class can be AlgorithmIdentifier{} A useful parameterized version of X.509 type AlgorithmIdentifier is defined in this document. This type tightly binds pairs of algorithm object

identifiers to their associated parameter types. When referenced, the single parameter of AlgorithmIdentifier{} specifies a constraint on the Nystrom & Kaliski Informational [Page 2]

RFC 2986 Certification Request Syntax Specification November 2000 ASN.1 ATTRIBUTE Attribute{} pairs of values that may appear in that instance of the type. AlgorithmIdentifier{} are equivalent to those of type AlgorithmIdentifier. The encoded values of Abstract Syntax Notation One, as defined in the ASN.1 standards ([10], [11], [12], and [13]). This class describes objects composed of an attribute (a unique object identifier) and an associated set of attribute values (any ASN.1 type). objects in this class can be represented by type Attribute{}. The values of A useful parameterized version of X.501 [8] type Attribute is defined in this document. This type tightly binds pairs of attribute type object identifiers to one or more attribute values types. In the ASN.1 open type notation, an attribute type is defined as ATTRIBUTE.&id and an attribute value as ATTRIBUTE.&Type. parameter of Attribute{} specifies a constraint on the pairs of values that may appear in an instance of the type. equivalent to those of type Attribute. The encoded values of Attribute{} are When referenced, the single BER Basic Encoding Rules for ASN.1, as defined in X.690 ([14]). Certificate A type that binds a subject entity's distinguished name to a public key with a digital signature. type is defined in X.509. the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, a validity period, and an optional set of certificate extensions. This type also contains This DER Name Distinguished Encoding Rules for ASN.1, as defined in X.690. DER is a subset of BER. A type that uniquely identifies or "distinguishes" objects in an X.500 [7] directory. defined in X.501. In an X.509 certificate, the type identifies the certificate issuer and the certificate This type is

subject, the entity whose public key is certified. Nystrom & Kaliski Informational [Page 3]

RFC 2986 Certification Request Syntax Specification November 2000 2.2 Notation No special notation is used in this document. 3. Overview 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: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity's private key. (See Section 4.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 authenticating the requesting entity and verifying the entity's signature, and, if the request is valid, constructing an X.509 certificate from the distinguished name and public key, the issuer name, and the certification authority's choice of serial number, validity period, and signature algorithm. If the certification request contains any PKCS #9 attributes, the certification authority may also use the values in these attributes as well as other information known to the certification authority to construct X.509 certificate extensions. 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. include a certification path from the new certificate to the certification authority. as cross-certificates that the certification authority considers It may also include other certificates such The return message may

helpful, and it may include certificate-revocation lists (CRLs). Another possibility is that the certification authority inserts the new certificate into a central database. Nystrom & Kaliski Informational [Page 4]

资料库

PKCS10 文档.doc

相关推荐

安全技术

热门标签

最新资料