From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2314.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc2314.txt (limited to 'doc/rfc/rfc2314.txt') diff --git a/doc/rfc/rfc2314.txt b/doc/rfc/rfc2314.txt new file mode 100644 index 0000000..89183fd --- /dev/null +++ b/doc/rfc/rfc2314.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group B. Kaliski +Request for Comments: 2314 RSA Laboratories East +Category: Informational March 1998 + + + PKCS #10: Certification Request Syntax + Version 1.5 + +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 (1998). All Rights Reserved. + +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 + 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. + + + + + + +Kaliski Informational [Page 1] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 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. + + 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. + +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. + + + + +Kaliski Informational [Page 2] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 + entity's public key, and a set of attributes providing other + information about the entity. + + + + + + + + + +Kaliski Informational [Page 3] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 pair, but + may also do so after a change in the entity's distinguished + name. + + + + + +Kaliski Informational [Page 4] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 + 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. + + + + + + +Kaliski Informational [Page 5] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 + 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. + + + +Kaliski Informational [Page 6] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + + 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 + +Security Considerations + + Security issues are discussed throughout this memo. + +Revision history + + Version 1.0 + + Version 1.0 is the initial version. + +Acknowledgements + + 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". + +Author's Address + + Burt Kaliski + RSA Laboratories East + 20 Crosby Drive + Bedford, MA 01730 + + Phone: (617) 687-7000 + EMail: burt@rsa.com + + + + + +Kaliski Informational [Page 7] + +RFC 2314 PKCS #10: Certification Request Syntax March 1998 + + +Full Copyright Statement + + Copyright (C) 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. + + + + + + + + + + + + + + + + + + + + + + + + +Kaliski Informational [Page 8] + -- cgit v1.2.3