]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2587.txt
Sync with HEAD
[openldap] / doc / rfc / rfc2587.txt
1
2
3
4
5
6
7 Network Working Group                                     S. Boeyen
8 Request for Comments: 2587                                  Entrust
9 Category: Standards Track                                  T. Howes
10                                                            Netscape
11                                                          P. Richard
12                                                               Xcert
13                                                           June 1999
14
15
16
17                 Internet X.509 Public Key Infrastructure
18                              LDAPv2 Schema
19
20 Status of this Memo
21
22    This document specifies an Internet standards track protocol for the
23    Internet community, and requests discussion and suggestions for
24    improvements.  Please refer to the current edition of the "Internet
25    Official Protocol Standards" (STD 1) for the standardization state
26    and status of this protocol.  Distribution of this memo is unlimited.
27
28 Copyright Notice
29
30    Copyright (C) The Internet Society (1999).  All Rights Reserved.
31
32 1.  Abstract
33
34    The schema defined in this document is a minimal schema to support
35    PKIX in an LDAPv2 environment, as defined in RFC 2559.  Only PKIX-
36    specific components are specified here.  LDAP servers, acting as PKIX
37    repositories should support the auxiliary object classes defined in
38    this specification and integrate this schema specification with the
39    generic and other application-specific schemas as appropriate,
40    depending on the services to be supplied by that server.
41
42    The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
43    and 'MAY' in this document are to be interpreted as described in RFC
44    2119.
45
46 2.  Introduction
47
48    This specification is part of a multi-part standard for development
49    of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
50    mechanism defined for access to a PKI repository. Other mechanisms,
51    such as http, are also defined. If an LDAP server, accessed by LDAPv2
52    is used to provide a repository, the minimum requirement is that the
53    repository support the addition of X.509 certificates to directory
54
55
56
57
58 Boeyen, et al.              Standards Track                     [Page 1]
59 \f
60 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
61
62
63    entries.  Certificate Revocation List (CRL)is one mechanism for
64    publishing revocation information in a repository.  Other mechanisms,
65    such as http, are also defined.
66
67    This specification defines the attributes and object classes to be
68    used by LDAP servers acting as PKIX repositories and to be understood
69    by LDAP clients communicating with such repositories to query, add,
70    modify and delete PKI information. Some object classes and attributes
71    defined in X.509 are duplicated here for completeness. For end
72    entities and Certification Authorities (CA), the earlier X.509
73    defined object classes mandated inclusion of attributes which are
74    optional for PKIX. Also, because of the mandatory attribute
75    specification, this would have required dynamic modification of the
76    object class attribute should the attributes not always be present in
77    entries. For these reasons, alternative object classes are defined in
78    this document for use by LDAP servers acting as PKIX repositories.
79
80 3.  PKIX Repository Objects
81
82    The primary PKIX objects to be represented in a repository are:
83
84       -  End Entities
85       -  Certification Authorities (CA)
86
87    These objects are defined in RFC 2459.
88
89 3.1.  End Entities
90
91    For purposes of PKIX schema definition, the role of end entities as
92    subjects of certificates is the major aspect relevant to this
93    specification. End entities may be human users, or other types of
94    entities to which certificates may be issued. In some cases, the
95    entry for the end entity may already exist and the PKI-specific
96    information is added to the existing entry. In other cases the entry
97    may not exist prior to the issuance of a certificate, in which case
98    the entity adding the certificate may also need to create the entry.
99    Schema elements used to represent the non PKIX aspects of an entry,
100    such as the structural object class used to represent organizational
101    persons, may vary, depending on the particular environment and set of
102    applications served and are outside the scope of this specification.
103
104    The following auxiliary object class MAY be used to represent
105    certificate subjects:
106
107
108
109
110
111
112
113
114 Boeyen, et al.              Standards Track                     [Page 2]
115 \f
116 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
117
118
119 pkiUser   OBJECT-CLASS   ::= {
120    SUBCLASS OF   { top}
121    KIND          auxiliary
122    MAY CONTAIN   {userCertificate}
123    ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
124
125 userCertificate    ATTRIBUTE  ::=  {
126      WITH SYNTAX   Certificate
127      EQUALITY MATCHING RULE   certificateExactMatch
128      ID  joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
129
130    An end entity may obtain one or more certificates from one or more
131    Certification Authorities.  The userCertificate attribute MUST be
132    used to represent these certificates in the directory entry
133    representing that user.
134
135 3.2.  Certification Authorities
136
137    As with end entities, Certification Authorities are typically
138    represented in directories as auxiliary components of entries
139    representing a more generic object, such as organizations,
140    organizational units etc. The non PKIX-specific schema elements for
141    these entries, such as the structural object class of the object, are
142    outside the scope of this specification.
143
144    The following auxiliary object class MAY be used to represent
145    Certification Authorities:
146
147 pkiCA   OBJECT-CLASS   ::= {
148    SUBCLASS OF   { top}
149    KIND          auxiliary
150    MAY CONTAIN   {cACertificate |
151                   certificateRevocationList |
152                   authorityRevocationList |
153                   crossCertificatePair }
154    ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
155
156 cACertificate    ATTRIBUTE  ::=  {
157      WITH SYNTAX   Certificate
158      EQUALITY MATCHING RULE   certificateExactMatch
159      ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
160
161 crossCertificatePairATTRIBUTE::={
162    WITH SYNTAX   CertificatePair
163    EQUALITY MATCHING RULE certificatePairExactMatch
164  ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
165
166
167
168
169
170 Boeyen, et al.              Standards Track                     [Page 3]
171 \f
172 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
173
174
175    The cACertificate attribute of a CA's directory entry shall be used
176    to store self-issued certificates (if any) and certificates issued to
177    this CA by CAs in the same realm as this CA.
178
179    The forward elements of the crossCertificatePair attribute of a CA's
180    directory entry shall be used to store all, except self-issued
181    certificates issued to this CA.  Optionally, the reverse elements of
182    the crossCertificatePair attribute, of a CA's directory entry may
183    contain a subset of certificates issued by this CA to other CAs.
184    When both the forward and the reverse elements are present in a
185    single attribute value, issuer name in one certificate shall match
186    the subject name in the other and vice versa, and the subject public
187    key in one certificate shall be capable of verifying the digital
188    signature on the other certificate and vice versa.
189
190    When a reverse element is present, the forward element value and the
191    reverse element value need not be stored in the same attribute value;
192    in other words, they can be stored in either a single attribute value
193    or two attribute values.
194
195    In the case of V3 certificates, none of the above CA certificates
196    shall include a basicConstraints extension with the cA value set to
197    FALSE.
198
199    The definition of realm is purely a matter of local policy.
200
201       certificateRevocationListATTRIBUTE::={
202            WITH SYNTAX  CertificateList
203            EQUALITY MATCHING RULE certificateListExactMatch
204         ID joint-iso-ccitt(2) ds(5) attributeType(4)
205            certificateRevocationList(39)}
206
207    The certificateRevocationList attribute, if present in a particular
208    CA's entry, contains CRL(s) as defined in RFC 2459.
209
210       authorityRevocationListATTRIBUTE::={
211          WITH SYNTAX   CertificateList
212          EQUALITY MATCHING RULE certificateListExactMatch
213        ID joint-iso-ccitt(2) ds(5) attributeType(4)
214           authorityRevocationList(38)}
215
216    The authorityRevocationList attribute, if present in a particular
217    CA's entry, includes revocation information regarding certificates
218    issued to other CAs.
219
220
221
222
223
224
225
226 Boeyen, et al.              Standards Track                     [Page 4]
227 \f
228 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
229
230
231 3.2.1.  CRL distribution points
232
233    CRL distribution points are an optional mechanism, specified in RFC
234    2459, which MAY be used to distribute revocation information.
235
236    A patent statement regarding CRL distribution points can be found at
237    the end of this document.
238
239    If a CA elects to use CRL distribution points, the following object
240    class is used to represent these.
241
242  cRLDistributionPoint   OBJECT-CLASS::= {
243     SUBCLASS OF     { top }
244     KIND            structural
245     MUST CONTAIN    { commonName }
246     MAY CONTAIN     { certificateRevocationList |
247                       authorityRevocationList |
248                       deltaRevocationList }
249     ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
250
251    The certificateRevocationList and authorityRevocationList attributes
252    are as defined above.
253
254    The commonName attribute and deltaRevocationList attributes, defined
255    in X.509, are duplicated below.
256
257       commonName   ATTRIBUTE::={
258          SUBTYPE OF     name
259          WITH SYNTAX   DirectoryString
260          ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
261
262       deltaRevocationList        ATTRIBUTE ::= {
263          WITH SYNTAX             CertificateList
264          EQUALITY MATCHING RULE  certificateListExactMatch
265          ID joint-iso-ccitt(2) ds(5) attributeType(4)
266             deltaRevocationList(53) }
267
268 3.2.2.  Delta CRLs
269
270    Delta CRLs are an optional mechanism, specified in RFC 2459, which
271    MAY be used to enhance the distribution of revocation information.
272
273    If a CA elects to use delta CRLs, the following object class is used
274    to represent these.
275
276
277
278
279
280
281
282 Boeyen, et al.              Standards Track                     [Page 5]
283 \f
284 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
285
286
287       deltaCRL   OBJECT-CLASS::= {
288          SUBCLASS OF     { top }
289          KIND            auxiliary
290          MAY CONTAIN     { deltaRevocationList }
291          ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
292
293 4.  Security Considerations
294
295    Since the elements of information which are key to the PKI service
296    (certificates and CRLs) are both digitally signed pieces of
297    information, no additional integrity service is REQUIRED.
298
299    Security considerations with respect to retrieval, addition,
300    deletion, and modification of the information supported by this
301    schema definition are addressed in RFC 2559.
302
303 5.  References
304
305    [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
306         Protocol", RFC 1777, March 1995.
307
308    [2]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
309         Levels", BCP 14, RFC 2119, March 1997.
310
311 6  Intellectual Property Rights
312
313    The IETF has been notified of intellectual property rights claimed in
314    regard to some or all of the specification contained in this
315    document.  For more information consult the online list of claimed
316    rights.
317
318    The IETF takes no position regarding the validity or scope of any
319    intellectual property or other rights that might be claimed to
320    pertain to the implementation or use of the technology described in
321    this document or the extent to which any license under such rights
322    might or might not be available; neither does it represent that it
323    has made any effort to identify any such rights. Information on the
324    IETF's procedures with respect to rights in standards-track and
325    standards-related documentation can be found in BCP-11. Copies of
326    claims of rights made available for publication and any assurances of
327    licenses to be made available, or the result of an attempt made to
328    obtain a general license or permission for the use of such
329    proprietary rights by implementors or users of this specification can
330    be obtained from the IETF Secretariat.
331
332
333
334
335
336
337
338 Boeyen, et al.              Standards Track                     [Page 6]
339 \f
340 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
341
342
343 7.  Authors' Addresses
344
345    Sharon Boeyen
346    Entrust Technologies Limited
347    750 Heron Road
348    Ottawa, Ontario
349    Canada K1V 1A7
350
351    EMail: sharon.boeyen@entrust.com
352
353
354    Tim Howes
355    Netscape Communications Corp.
356    501 E. Middlefield Rd.
357    Mountain View, CA 94043
358    USA
359
360    EMail: howes@netscape.com
361
362
363    Patrick Richard
364    Xcert Software Inc.
365    Suite 1001, 701 W. Georgia Street
366    P.O. Box 10145
367    Pacific Centre
368    Vancouver, B.C.
369    Canada V7Y 1C6
370
371    EMail: patr@xcert.com
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394 Boeyen, et al.              Standards Track                     [Page 7]
395 \f
396 RFC 2587                   PKIX LDAPv2 Schema                  June 1999
397
398
399 Full Copyright Statement
400
401    Copyright (C) The Internet Society (1999).  All Rights Reserved.
402
403    This document and translations of it may be copied and furnished to
404    others, and derivative works that comment on or otherwise explain it
405    or assist in its implementation may be prepared, copied, published
406    and distributed, in whole or in part, without restriction of any
407    kind, provided that the above copyright notice and this paragraph are
408    included on all such copies and derivative works.  However, this
409    document itself may not be modified in any way, such as by removing
410    the copyright notice or references to the Internet Society or other
411    Internet organizations, except as needed for the purpose of
412    developing Internet standards in which case the procedures for
413    copyrights defined in the Internet Standards process must be
414    followed, or as required to translate it into languages other than
415    English.
416
417    The limited permissions granted above are perpetual and will not be
418    revoked by the Internet Society or its successors or assigns.
419
420    This document and the information contained herein is provided on an
421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
426
427 Acknowledgement
428
429    Funding for the RFC Editor function is currently provided by the
430    Internet Society.
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450 Boeyen, et al.              Standards Track                     [Page 8]
451 \f