1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Network Working Group B. Kaliski
Request for Comments: 2314 RSA Laboratories East
Category: Informational March 1998
<span class="h1">PKCS #10: Certification Request Syntax</span>
<span class="h1">Version 1.5</span>
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.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Scope</span>
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.
<span class="grey">Kaliski Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
The preliminary intended application of this document is to support
PKCS #7 cryptographic messages, but is expected that other
applications will be developed.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. References</span>
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.
<a href="./rfc1424">RFC 1424</a> Kaliski, B., "Privacy Enhancement for
Internet Electronic Mail: Part IV: Key
Certification and Related Services," <a href="./rfc1424">RFC 1424</a>,
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Definitions</span>
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.
<span class="grey">Kaliski Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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,
<a href="#section-8.7">Section 8.7</a>.
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Symbols and abbreviations</span>
No symbols or abbreviations are defined in this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. General overview</span>
The next section specifies certification request syntax.
This document exports one type, CertificationRequest.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Certification request syntax</span>
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.
<span class="grey">Kaliski Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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 <a href="#section-6.2">Section 6.2</a>.)
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.
<span class="grey">Kaliski Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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 <a href="./rfc1424">RFC 1424</a>. 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.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a> CertificationRequestInfo</span>
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.
<span class="grey">Kaliski Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a> CertificationRequest</span>
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.
<span class="grey">Kaliski Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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
<span class="grey">Kaliski Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2314">RFC 2314</a> PKCS #10: Certification Request Syntax March 1998</span>
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]
</pre>
|
