RFC 2986

RFC 2986 🎀 PKCS #10: Certification Request Syntax Specification

Version 1.7 ✨

Part 1 of 3 🦋

Okay bestie, here are the deets 💖 RFC 2986 was written by M. Nystrom and B. Kaliski from RSA Security. It's an Informational doc, dated November 2000, and it obsoletes 2314. Nothing in the title block says it updates anything, so it doesn't 🙈

Status of This Memo 📮

This memo is here to give info to the Internet community 💅 It is not an Internet standard of any kind, and anyone can distribute it as much as they like 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔥

Abstract ✨

This memo republishes PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series 💜 Change control stays inside the PKCS process. Everything in the body comes straight from the PKCS #9 v2.0 or PKCS #10 v1.7 document, except the security considerations section.

The memo describes a syntax for certification requests 🧚

Table of Contents 🗂️

1.  Introduction ................................................. 2
2.  Definitions and notation ..................................... 2
2.1  Definitions ................................................. 2
2.2  Notation .................................................... 4
3.  Overview ..................................................... 4
4.  Certification request syntax ................................. 5
4.1  CertificationRequestInfo .................................... 5
4.2  CertificationRequest ........................................ 7
5.  Security Considerations ...................................... 8
6.  Authors' Addresses ........................................... 8
A.  ASN.1 module ................................................. 9
B.  Intellectual property considerations ........................ 10
C.  Revision history ............................................ 10
D.  References .................................................. 11
E.  Contact information & About PKCS ............................ 12
Full Copyright Statement ........................................ 14

1. Introduction 🦋

Okay so this doc is all about the syntax for certification requests 📝 A certification request is a distinguished name, a public key, and optionally a set of attributes, all collectively signed by the entity asking for certification 🔥 Those requests go to a certification authority, which turns the request into an X.509 [9] public-key certificate. (How the certification authority returns the newly signed certificate is outside the scope of this document. A PKCS #7 [2] message is one possibility.)

Including attributes is giving main character energy for two reasons 💅 First, they can provide other info about an entity, or a "challenge password" that the entity can use later to request certificate revocation 🙈 Second, they can provide attributes for inclusion in X.509 certificates. A non-exhaustive list of attributes is given in PKCS #9 [3].

Certification authorities may also want non-electronic forms of request, and they may send non-electronic replies too 📬 Descriptions of those forms are outside the scope of this document, but certification authorities are expected to make them available.

The preliminary intended application of this document is to support PKCS #7 cryptographic messages 🔐 Other applications are expected to be developed too (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).  The values of objects in this class can be
                   represented by the ASN.1 type AlgorithmIdentifier{}.
                   ALGORITHM is defined as the "useful" information
                   object class TYPE-IDENTIFIER, specified in [11],
                   Annex A.

   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
                   pairs of values that may appear in that instance of
                   the type.  The encoded values of
                   AlgorithmIdentifier{} are equivalent to those of type
                   AlgorithmIdentifier.

   ASN.1           Abstract Syntax Notation One, as defined in the ASN.1
                   standards ([10], [11], [12], and [13]).

   ATTRIBUTE       This class describes objects composed of an attribute
                   (a unique object identifier) and an associated set of
                   attribute values (any ASN.1 type).  The values of
                   objects in this class can be represented by type
                   Attribute{}.

   Attribute{}     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.  When referenced, the single
                   parameter of Attribute{} specifies a constraint on
                   the pairs of values that may appear in an instance of
                   the type.  The encoded values of Attribute{} are
                   equivalent to those of type Attribute.

   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.  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, a validity
                   period, and an optional set of certificate
                   extensions.

   DER             Distinguished Encoding Rules for ASN.1, as defined in
                   X.690.  DER is a subset of BER.

   Name            A type that uniquely identifies or "distinguishes"
                   objects in an X.500 [7] directory.  This type is
                   defined in X.501.  In an X.509 certificate, the type
                   identifies the certificate issuer and the certificate
                   subject, the entity whose public key is certified.

2.2 Notation

No special notation is used in this document. Easy peasy 🧁

3. Overview 🌟

A certification request is made up of three parts: "certification request information," a signature algorithm identifier, and a digital signature on the certification request information 🎀 The certification request information holds the entity's distinguished name, the entity's public key, and a set of attributes that give other info about the entity.

Here's how a certification request gets built, step by step 🪄

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.

Now the certification authority takes over 👑 It fulfills the request by authenticating the requesting entity and verifying the entity's signature. If the request is valid, it builds an X.509 certificate from the distinguished name and public key, the issuer name, and the certification authority's own choice of serial number, validity period, and signature algorithm. If the certification request has any PKCS #9 attributes, the certification authority may also use those values, along with other info it knows, to build X.509 certificate extensions.

The form the certification authority uses to return 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. That 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 thinks are helpful, and certificate-revocation lists (CRLs). Another possibility is that the certification authority just inserts the new certificate into a central database 💾

Note 1: An entity would typically send a certification request after generating a public-key/private-key pair. It may also send one after a change in the entity's distinguished name. 🦋

Note 2: The signature on the certification request stops an entity from requesting a certificate with another party's public key 🛑 That attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack only matters if the entity doesn't know the message being signed and the signed part of the message doesn't identify the signer. The entity still wouldn't be able to decrypt messages meant for the other party, of course 💅

Note 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 📄💻

Note 4: This document is not compatible with the certification request syntax for Privacy-Enhanced Mail, as described in RFC 1424 [5]. The syntax here 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. This document is designed to minimize request size, which is an important feature for certification authorities accepting requests on paper ✨

4. Certification request syntax ✨

okay so this section is split into two bits 💅 first we get CertificationRequestInfo (the info type), then the top-level CertificationRequest that wraps it all up 🎀

4.1 CertificationRequestInfo

certification request information is supposed to have the ASN.1 type CertificationRequestInfo 🧚

CertificationRequestInfo ::= SEQUENCE {
     version       INTEGER { v1(0) } (v1,...),
     subject       Name,
     subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
     attributes    [0] Attributes{{ CRIAttributes }}
}

SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
     algorithm        AlgorithmIdentifier {{IOSet}},
     subjectPublicKey BIT STRING
}
PKInfoAlgorithms ALGORITHM ::= {
     ...  -- add any locally defined algorithms here -- }

Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}

CRIAttributes  ATTRIBUTE  ::= {
     ... -- add any locally defined attributes here -- }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
     type   ATTRIBUTE.&id({IOSet}),
     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
}

these are the parts of CertificationRequestInfo and what they mean, bestie 👑

• version is the version number 🎀 It's there for compatibility with future revisions of this document. It shall be 0 for this version of the standard.
• subject is the distinguished name of the certificate subject, aka the entity whose public key is getting certified 🫶
• subjectPublicKeyInfo holds info about the public key being certified 🔑 It names the entity's public-key algorithm (plus any associated parameters). Examples of public-key algorithms include the rsaEncryption object identifier from PKCS #1 [1]. It also has a bit-string version of the entity's public key. For the algorithm we just mentioned, the bit string holds the DER encoding of a value of PKCS #1 type RSAPublicKey. The values of type SubjectPublicKeyInfo{} that are allowed for subjectPKInfo are constrained to the values in the information object set PKInfoAlgorithms, which includes the extension marker (...). Definitions of specific algorithm objects are left to specifications that reference this document. Those specifications will be interoperable with their future versions if any extra algorithm objects get added after the extension marker 🦋
• attributes is a collection of attributes that give extra info about the subject of the certificate ✨ Some attribute types that might be useful here are defined in PKCS #9. One example is the challenge-password attribute, which specifies a password the entity can use to request certificate revocation. Another example is info that should show up in X.509 certificate extensions (for example, the extensionRequest attribute from PKCS #9). The values of type Attributes{} that are allowed for attributes are constrained to the values in the information object set CRIAttributes. Definitions of specific attribute objects are left to specifications that reference this document. Those specifications will be interoperable with their future versions if any extra attribute objects get added after the extension marker 💜

4.2 CertificationRequest

a certification request shall have the ASN.1 type CertificationRequest 🍓

CertificationRequest ::= SEQUENCE {
     certificationRequestInfo CertificationRequestInfo,
     signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
     signature          BIT STRING
}

AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
     algorithm          ALGORITHM.&id({IOSet}),
     parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}

SignatureAlgorithms ALGORITHM ::= {
     ... -- add any locally defined algorithms here -- }

the parts of CertificationRequest 💅

• certificateRequestInfo is the "certification request information." It's the value that gets signed 🔥
• signatureAlgorithm names the signature algorithm (plus any associated parameters) that the certification-request information is signed with 🌈 For example, a specification might include an ALGORITHM object for PKCS #1's md5WithRSAEncryption in the information object set SignatureAlgorithms:

SignatureAlgorithms ALGORITHM ::= {
     ...,
     { NULL IDENTIFIED BY md5WithRSAEncryption }
}

• signature is the result of signing the certification request information with the certification request subject's private key 🔐

the signing process has two steps 🫶

1. The value of the certificationRequestInfo component gets DER encoded, which gives an octet string.
2. The result of step 1 gets signed with the certification request subject's private key under the specified signature algorithm, which gives a bit string: the signature ✨

Note - An equivalent syntax for CertificationRequest could be written like this, bestie 🙈

CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo }
     (CONSTRAINED BY { -- Verify or sign encoded
      -- CertificationRequestInfo -- })

EncodedCertificationRequestInfo ::=
     TYPE-IDENTIFIER.&Type(CertificationRequestInfo)

SIGNED { ToBeSigned } ::= SEQUENCE {
     toBeSigned ToBeSigned,
     algorithm  AlgorithmIdentifier { {SignatureAlgorithms} },
     signature  BIT STRING
}

---

5. Security Considerations 🔥

security issues are discussed throughout this memo, so pay attention 😭🔐

6. Authors' Addresses 🦋

Magnus Nystrom
RSA Security
Box 10704
S-121 29 Stockholm
Sweden

EMail: magnus@rsasecurity.com


Burt Kaliski
RSA Security
20 Crosby Drive
Bedford, MA 01730 USA

EMail: bkaliski@rsasecurity.com

APPENDICES 🎀

A. ASN.1 Module

this appendix has all of the ASN.1 type and value definitions from this document, packaged as the ASN.1 module PKCS-10 🧚

PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-10(10) modules(1) pkcs-10(1)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS All --

-- All types and values defined in this module are exported for use
-- in other ASN.1 modules.

IMPORTS

informationFramework, authenticationFramework
     FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
     usefulDefinitions(0) 3}

ATTRIBUTE, Name
     FROM InformationFramework informationFramework

ALGORITHM
     FROM AuthenticationFramework authenticationFramework;

-- Certificate requests
CertificationRequestInfo ::= SEQUENCE {
     version       INTEGER { v1(0) } (v1,...),
     subject       Name,
     subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
     attributes    [0] Attributes{{ CRIAttributes }}
}

SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE {
     algorithm        AlgorithmIdentifier {{IOSet}},
     subjectPublicKey BIT STRING
}

PKInfoAlgorithms ALGORITHM ::= {
     ...  -- add any locally defined algorithms here -- }

Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
CRIAttributes  ATTRIBUTE  ::= {
     ... -- add any locally defined attributes here -- }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
     type   ATTRIBUTE.&id({IOSet}),
     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
}

CertificationRequest ::= SEQUENCE {
     certificationRequestInfo CertificationRequestInfo,
     signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
     signature          BIT STRING
}

AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
     algorithm  ALGORITHM.&id({IOSet}),
     parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}

SignatureAlgorithms ALGORITHM ::= {
     ... -- add any locally defined algorithms here -- }

END

B. Intellectual property considerations 💜

RSA Security makes no patent claims on the general constructions described in this document, although specific underlying techniques may be covered.

License to copy this document is granted provided that it is identified as "RSA Security Inc. Public-Key Cryptography Standards (PKCS)" in all material mentioning or referencing this document.

RSA Security makes no representations regarding intellectual property claims by other parties. Such determination is the responsibility of the user.

C. Revision history 🌸

Version 1.0

Version 1.0 was the previous version of this document (also published as "version 1.5" in [6]).

Version 1.7

This version incorporates several editorial changes, including updates to the references, and changes to ASN.1 type definitions. The following substantive changes have been made:

• This version refers to X.680-X.690, the current international standards for ASN.1 and its encoding rules. All references to X.208 and X.209 have been eliminated.
• The X.690 standard requires that the encoded values of SET OF components be sorted in ascending order under DER. Regardless of this, applications should not rely on the ordering of attribute components.
• All references to PKCS #6 Extended-Certificate Syntax Standard have been removed. With the addition of extensions to X.509 version 3 certificates, RSA Laboratories is withdrawing support for PKCS #6.

Note - The reason for using version 1.7 for this document is to avoid confusion with [6], which is named version 1.5, and an unsupported PKCS #10 version named Version 1.6.

D. References 📚

okay bestie, this is the reading list, and the citations are the receipts 🧾✨ every entry stays exactly as written so nobody can say we fudged the sources 💅

[1] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0, October 1998.

[2] RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.

[3] RSA Laboratories. PKCS #9: Selected Attribute Types. Version 2.0, February 2000.

[4] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure - Certificate Management Protocols", RFC 2510, March 1999.

[5] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, February 1993.

[6] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.

[7] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.

[8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995, Information technology - Open Systems Interconnection - The Directory: Models.

[9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, Information technology - Open Systems Interconnection -The Directory: Authentication framework.

[10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation.

[11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Information Object Specification.

[12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Constraint Specification.

[13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 Specifications.

[14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

---

E. Contact Information & About PKCS 🌈

the PKCS standards come from RSA Laboratories, working with secure systems developers all over the world 🌍 the goal is to speed up how fast public-key cryptography gets deployed 🔐 they first dropped in 1991 after meeting with a small group of early adopters, and the PKCS docs have been widely referenced and implemented ever since 🙌

the PKCS series has ended up inside a bunch of formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/MIME, and SSL 💖

development keeps happening through mailing list discussions and the occasional workshop, and suggestions for improvement are welcome 💌 if you want to reach out, here's the contact info:

PKCS Editor
RSA Laboratories
20 Crosby Drive
Bedford, MA  01730 USA
pkcs-editor@rsasecurity.com
http://www.rsasecurity.com/rsalabs/pkcs

---

Full Copyright Statement ⚖️

Copyright (C) The Internet Society 2000. All Rights Reserved. Yes, the legal stuff is important, so here it is in full 🎀

this document and translations of it may be copied and given to others, as long as the copyright notice and this paragraph stay on every copy 📄 but the document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the only exception is translating it into languages other than English 🌸

those permissions are perpetual, and the Internet Society and its successors or assigns won't revoke them 🦋

this document and the info in it are 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. 😭

---

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 💜 thank you to them for keeping the lights on ✨