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 S. Boeyen
Request for Comments: 2587 Entrust
Category: Standards Track T. Howes
Netscape
P. Richard
Xcert
June 1999
<span class="h1">Internet X.509 Public Key Infrastructure</span>
<span class="h1">LDAPv2 Schema</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Abstract</span>
The schema defined in this document is a minimal schema to support
PKIX in an LDAPv2 environment, as defined in <a href="./rfc2559">RFC 2559</a>. Only PKIX-
specific components are specified here. LDAP servers, acting as PKIX
repositories should support the auxiliary object classes defined in
this specification and integrate this schema specification with the
generic and other application-specific schemas as appropriate,
depending on the services to be supplied by that server.
The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
and 'MAY' in this document are to be interpreted as described in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a>.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introduction</span>
This specification is part of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
mechanism defined for access to a PKI repository. Other mechanisms,
such as http, are also defined. If an LDAP server, accessed by LDAPv2
is used to provide a repository, the minimum requirement is that the
repository support the addition of X.509 certificates to directory
<span class="grey">Boeyen, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
entries. Certificate Revocation List (CRL)is one mechanism for
publishing revocation information in a repository. Other mechanisms,
such as http, are also defined.
This specification defines the attributes and object classes to be
used by LDAP servers acting as PKIX repositories and to be understood
by LDAP clients communicating with such repositories to query, add,
modify and delete PKI information. Some object classes and attributes
defined in X.509 are duplicated here for completeness. For end
entities and Certification Authorities (CA), the earlier X.509
defined object classes mandated inclusion of attributes which are
optional for PKIX. Also, because of the mandatory attribute
specification, this would have required dynamic modification of the
object class attribute should the attributes not always be present in
entries. For these reasons, alternative object classes are defined in
this document for use by LDAP servers acting as PKIX repositories.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. PKIX Repository Objects</span>
The primary PKIX objects to be represented in a repository are:
- End Entities
- Certification Authorities (CA)
These objects are defined in <a href="./rfc2459">RFC 2459</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. End Entities</span>
For purposes of PKIX schema definition, the role of end entities as
subjects of certificates is the major aspect relevant to this
specification. End entities may be human users, or other types of
entities to which certificates may be issued. In some cases, the
entry for the end entity may already exist and the PKI-specific
information is added to the existing entry. In other cases the entry
may not exist prior to the issuance of a certificate, in which case
the entity adding the certificate may also need to create the entry.
Schema elements used to represent the non PKIX aspects of an entry,
such as the structural object class used to represent organizational
persons, may vary, depending on the particular environment and set of
applications served and are outside the scope of this specification.
The following auxiliary object class MAY be used to represent
certificate subjects:
<span class="grey">Boeyen, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
An end entity may obtain one or more certificates from one or more
Certification Authorities. The userCertificate attribute MUST be
used to represent these certificates in the directory entry
representing that user.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Certification Authorities</span>
As with end entities, Certification Authorities are typically
represented in directories as auxiliary components of entries
representing a more generic object, such as organizations,
organizational units etc. The non PKIX-specific schema elements for
these entries, such as the structural object class of the object, are
outside the scope of this specification.
The following auxiliary object class MAY be used to represent
Certification Authorities:
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
crossCertificatePairATTRIBUTE::={
WITH SYNTAX CertificatePair
EQUALITY MATCHING RULE certificatePairExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
<span class="grey">Boeyen, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
The cACertificate attribute of a CA's directory entry shall be used
to store self-issued certificates (if any) and certificates issued to
this CA by CAs in the same realm as this CA.
The forward elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all, except self-issued
certificates issued to this CA. Optionally, the reverse elements of
the crossCertificatePair attribute, of a CA's directory entry may
contain a subset of certificates issued by this CA to other CAs.
When both the forward and the reverse elements are present in a
single attribute value, issuer name in one certificate shall match
the subject name in the other and vice versa, and the subject public
key in one certificate shall be capable of verifying the digital
signature on the other certificate and vice versa.
When a reverse element is present, the forward element value and the
reverse element value need not be stored in the same attribute value;
in other words, they can be stored in either a single attribute value
or two attribute values.
In the case of V3 certificates, none of the above CA certificates
shall include a basicConstraints extension with the cA value set to
FALSE.
The definition of realm is purely a matter of local policy.
certificateRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
certificateRevocationList(39)}
The certificateRevocationList attribute, if present in a particular
CA's entry, contains CRL(s) as defined in <a href="./rfc2459">RFC 2459</a>.
authorityRevocationListATTRIBUTE::={
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
authorityRevocationList(38)}
The authorityRevocationList attribute, if present in a particular
CA's entry, includes revocation information regarding certificates
issued to other CAs.
<span class="grey">Boeyen, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. CRL distribution points</span>
CRL distribution points are an optional mechanism, specified in <a href="./rfc2459">RFC</a>
<a href="./rfc2459">2459</a>, which MAY be used to distribute revocation information.
A patent statement regarding CRL distribution points can be found at
the end of this document.
If a CA elects to use CRL distribution points, the following object
class is used to represent these.
cRLDistributionPoint OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND structural
MUST CONTAIN { commonName }
MAY CONTAIN { certificateRevocationList |
authorityRevocationList |
deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
The certificateRevocationList and authorityRevocationList attributes
are as defined above.
The commonName attribute and deltaRevocationList attributes, defined
in X.509, are duplicated below.
commonName ATTRIBUTE::={
SUBTYPE OF name
WITH SYNTAX DirectoryString
ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
deltaRevocationList(53) }
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Delta CRLs</span>
Delta CRLs are an optional mechanism, specified in <a href="./rfc2459">RFC 2459</a>, which
MAY be used to enhance the distribution of revocation information.
If a CA elects to use delta CRLs, the following object class is used
to represent these.
<span class="grey">Boeyen, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
deltaCRL OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
Since the elements of information which are key to the PKI service
(certificates and CRLs) are both digitally signed pieces of
information, no additional integrity service is REQUIRED.
Security considerations with respect to retrieval, addition,
deletion, and modification of the information supported by this
schema definition are addressed in <a href="./rfc2559">RFC 2559</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
[<a id="ref-1">1</a>] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", <a href="./rfc1777">RFC 1777</a>, March 1995.
[<a id="ref-2">2</a>] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a> Intellectual Property Rights</span>
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in <a href="https://www.rfc-editor.org/bcp/bcp11">BCP-11</a>. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
<span class="grey">Boeyen, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Authors' Addresses</span>
Sharon Boeyen
Entrust Technologies Limited
750 Heron Road
Ottawa, Ontario
Canada K1V 1A7
EMail: sharon.boeyen@entrust.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
EMail: howes@netscape.com
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
EMail: patr@xcert.com
<span class="grey">Boeyen, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2587">RFC 2587</a> PKIX LDAPv2 Schema June 1999</span>
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boeyen, et al. Standards Track [Page 8]
</pre>
|
