7 Network Working Group S. Boeyen
8 Request for Comments: 2559 Entrust
10 Category: Standards Track Netscape
16 Internet X.509 Public Key Infrastructure
17 Operational Protocols - LDAPv2
21 This document specifies an Internet standards track protocol for the
22 Internet community, and requests discussion and suggestions for
23 improvements. Please refer to the current edition of the "Internet
24 Official Protocol Standards" (STD 1) for the standardization state
25 and status of this protocol. Distribution of this memo is unlimited.
29 Copyright (C) The Internet Society (1999). All Rights Reserved.
33 The protocol described in this document is designed to satisfy some
34 of the operational requirements within the Internet X.509 Public Key
35 Infrastructure (IPKI). Specifically, this document addresses
36 requirements to provide access to Public Key Infrastructure (PKI)
37 repositories for the purposes of retrieving PKI information and
38 managing that same information. The mechanism described in this
39 document is based on the Lightweight Directory Access Protocol (LDAP)
40 v2, defined in RFC 1777, defining a profile of that protocol for use
41 within the IPKI and updates encodings for certificates and revocation
42 lists from RFC 1778. Additional mechanisms addressing PKIX
43 operational requirements are specified in separate documents.
45 The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
46 in this document are to be interpreted as described in RFC 2119.
50 This specification is part of a multi-part standard for development
51 of a Public Key Infrastructure (PKI) for the Internet. This
52 specification addresses requirements to provide retrieval of X.509
53 PKI information, including certificates and CRLs from a repository.
54 This specification also addresses requirements to add, delete and
58 Boeyen, et al. Standards Track [Page 1]
60 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
63 modify PKI information in a repository. A profile based on the LDAP
64 version 2 protocol is provided to satisfy these requirements.
68 The PKI components, as defined in PKIX Part 1, which are involved in
69 PKIX operational protocol interactions include:
72 - Certification Authorities (CA)
75 End entities and CAs using LDAPv2, retrieve PKI information from the
76 repository using a subset of the LDAPv2 protocol.
78 CAs populate the repository with PKI information using a subset of
81 4. Lightweight Directory Access Protocol (LDAP)
83 The following sections examine the retrieval of PKI information from
84 a repository and management of PKI information in a repository. A
85 profile of the LDAPv2 protocol is defined for providing these
88 Section 5 satisfies the requirement to retrieve PKI information (a
89 certificate, CRL, or other information of interest) from an entry in
90 the repository, where the retrieving entity (either an end entity or
91 a CA) has knowledge of the name of the entry. This is termed
94 Section 6 satisfies the same requirement as 5 for the situation where
95 the name of the entry is not known, but some other related
96 information which may optionally be used as a filter against
97 candidate entries in the repository, is known. This is termed
100 Section 7 satisfies the requirement of CAs to add, delete and modify
101 PKI information information (a certificate, CRL, or other information
102 of interest)in the repository. This is termed "repository modify".
104 The subset of LDAPv2 needed to support each of these functions is
105 described below. Note that the repository search service is a
106 superset of the repository read service in terms of the LDAPv2
107 functionality needed.
109 Note that all tags are implicit by default in the ASN.1 definitions
114 Boeyen, et al. Standards Track [Page 2]
116 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
119 5. LDAP Repository Read
121 To retrieve information from an entry corresponding to the subject or
122 issuer name of a certificate, requires a subset of the following
123 three LDAP operations:
125 BindRequest (and BindResponse)
126 SearchRequest (and SearchResponse)
129 The subset of each REQUIRED operation is given below.
135 The full LDAP v2 Bind Request is defined in RFC 1777.
137 An application providing a LDAP repository read service MUST
138 implement the following subset of this operation:
141 [APPLICATION 0] SEQUENCE {
143 name LDAPDN, -- MUST accept NULL LDAPDN
144 simpleauth [0] OCTET STRING -- MUST accept NULL simple
147 An application providing a LDAP repository read service MAY implement
148 other aspects of the BindRequest as well.
150 Different services may have different security requirements. Some
151 services may allow anonymous search, others may require
152 authentication. Those services allowing anonymous search may choose
153 only to allow search based on certain criteria and not others.
155 A LDAP repository read service SHOULD implement some level of
156 anonymous search access. A LDAP repository read service MAY implement
157 authenticated search access.
161 The full LDAPv2 BindResponse is described in RFC 1777.
163 An application providing a LDAP repository read service MUST
164 implement this entire protocol element, though only the following
165 error codes may be returned from a Bind operation:
170 Boeyen, et al. Standards Track [Page 3]
172 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
178 authMethodNotSupported (7),
180 invalidDNSyntax (34),
181 inappropriateAuthentication (48),
182 invalidCredentials (49),
185 unwillingToPerform (53),
190 5.2.1. Search Request
192 The full LDAPv2 SearchRequest is defined in RFC 1777.
194 An application providing a LDAP repository read service MUST
195 implement the following subset of the SearchRequest.
198 [APPLICATION 3] SEQUENCE {
203 derefAliases ENUMERATED {
204 neverDerefAliases (0),
206 sizeLimit INTEGER (0),
207 timeLimit INTEGER (0),
208 attrsOnly BOOLEAN, -- FALSE only
210 attributes SEQUENCE OF AttributeType
215 present [7] AttributeType, -- "objectclass" only
218 This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
219 operation: a base object search with a filter testing for the
220 existence of the objectClass attribute.
226 Boeyen, et al. Standards Track [Page 4]
228 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
231 An application providing a LDAP repository read service MAY implement
232 other aspects of the SearchRequest as well.
236 The full LDAPv2 SearchResponse is defined in RFC 1777.
238 An application providing a LDAP repository read service over LDAPv2
239 MUST implement the full SearchResponse.
241 Note that in the case of multivalued attributes such as
242 userCertificate a SearchResponse containing this attribute will
243 include all values, assuming the requester has sufficient access
244 permissions. The application/relying party may need to select an
245 appropriate value to be used. Also note that retrieval of a
246 certificate from a named entry does not guarantee that the
247 certificate will include that same Distinguished Name (DN) and in
248 some cases the subject DN in the certificate may be NULL.
252 The full LDAPv2 UnbindRequest is defined in RFC 1777.
254 An application providing a LDAP repository read service MUST
255 implement the full UnbindRequest.
257 6. LDAP Repository Search
259 To search, using arbitrary criteria, for an entry in a repository
260 containing a certificate, CRL, or other information of interest,
261 requires a subset of the following three LDAP operations:
263 BindRequest (and BindResponse)
264 SearchRequest (and SearchResponse)
267 The subset of each operation REQUIRED is given below.
271 The BindRequest and BindResponse subsets needed are the same as those
272 described in Section 5.1.
274 The full LDAP v2 Bind Request is defined in RFC 1777.
282 Boeyen, et al. Standards Track [Page 5]
284 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
289 6.2.1. Search Request
291 The full LDAPv2 SearchRequest is defined in RFC 1777.
293 An application providing a LDAP repository search service MUST
294 implement the following subset of the SearchRequest protocol unit.
297 [APPLICATION 3] SEQUENCE {
304 derefAliases ENUMERATED {
305 neverDerefAliases (0),
307 sizeLimit INTEGER (0 .. maxInt),
308 timeLimit INTEGER (0 .. maxInt),
309 attrsOnly BOOLEAN, -- FALSE only
311 attributes SEQUENCE OF AttributeType
314 All aspects of the SearchRequest MUST be supported, except for the
317 - Only the neverDerefAliases value of derefAliases needs to be
320 - Only the FALSE value for attrsOnly needs to be supported
322 This subset provides a more general search capability. It is a
323 superset of the SearchRequest subset defined in Section 5.2.1. The
324 elements added to this service are:
326 - singleLevel and wholeSubtree scope needs to be supported
328 - sizeLimit is included
330 - timeLimit is included
332 - Enhanced filter capability
338 Boeyen, et al. Standards Track [Page 6]
340 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
343 An application providing a LDAP repository search service MAY
344 implement other aspects of the SearchRequest as well.
346 6.2.2. Search Response
348 The full LDAPv2 SearchResponse is defined in RFC 1777.
350 An application providing a LDAP repository search service over LDAPv2
351 MUST implement the full SearchResponse.
355 An application providing a LDAP repository search service MUST
356 implement the full UnbindRequest.
358 7. LDAP Repository Modify
360 To add, delete and modify PKI information in a repository requires a
361 subset of the following LDAP operations:
363 BindRequest (and BindResponse)
364 ModifyRequest (and ModifyResponse)
365 AddRequest (and AddResponse)
366 DelRequest (and DelResponse
369 The subset of each operation REQUIRED is given below.
373 The full LDAP v2 Bind Request is defined in RFC 1777.
375 An application providing a LDAP repository modify service MUST
376 implement the following subset of this operation:
379 [APPLICATION 0] SEQUENCE {
382 simpleauth [0] OCTET STRING
385 A LDAP repository modify service MUST implement authenticated access.
387 The BindResponse subsets needed are the same as those described in
394 Boeyen, et al. Standards Track [Page 7]
396 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
401 7.2.1. Modify Request
403 The full LDAPv2 ModifyRequest is defined in RFC 1777.
405 An application providing a LDAP repository modify service MUST
406 implement the following subset of the ModifyRequest protocol unit.
409 [APPLICATION 6] SEQUENCE {
411 modification SEQUENCE OF SEQUENCE {
412 operation ENUMERATED {
416 modification SEQUENCE {
424 All aspects of the ModifyRequest MUST be supported, except for the
427 - Only the add and delete values of operation need to be supported
429 7.2.2. Modify Response
431 The full LDAPv2 ModifyResponse is defined in RFC 1777.
433 An application providing a LDAP repository modify service MUST
434 implement the full ModifyResponse.
440 The full LDAPv2 AddRequest is defined in RFC 1777.
442 An application providing a LDAP repository modify service MUST
443 implement the full AddRequest.
450 Boeyen, et al. Standards Track [Page 8]
452 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
457 The full LDAPv2 AddResponse is defined in RFC 1777.
459 An application providing a LDAP repository modify service MUST
460 implement the full AddResponse.
464 7.4.1. Delete Request
466 The full LDAPv2 DelRequest is defined in RFC 1777.
468 An application providing a LDAP repository modify service MUST
469 implement the full DelRequest.
471 7.4.2. Delete Response
473 The full LDAPv2 DelResponse is defined in RFC 1777.
475 An application providing a LDAP repository modify service MUST
476 implement the full DelResponse.
480 An application providing a LDAP repository modify service MUST
481 implement the full UnbindRequest.
483 8. Non-standard attribute value encodings
485 When conveyed in LDAP requests and results, attributes defined in
486 X.500 are to be encoded using string representations defined in RFC
487 1778, The String Representation of Standard Attribute Syntaxes.
488 These string encodings were based on the attribute definitions from
489 X.500(1988). Thus, the string representations of the PKI information
490 elements are for version 1 certificates and version 1 revocation
491 lists. Since this specification uses version 3 certificates and
492 version 2 revocation lists, as defined in X.509(1997), the RFC 1778
493 string encoding of these attributes is inappropriate.
495 For this reason, these attributes MUST be encoded using a syntax
496 similar to the syntax "Undefined" from section 2.1 of RFC 1778:
497 values of these attributes are encoded as if they were values of type
498 "OCTET STRING", with the string value of the encoding being the DER-
499 encoding of the value itself. For example, when writing a
500 userCertificate to the repository, the CA generates a DER-encoding of
501 the certificate and uses that encoding as the value of the
502 userCertificate attribute in the LDAP Modify request.This encoding
506 Boeyen, et al. Standards Track [Page 9]
508 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
511 style is consistent with the encoding scheme proposed for LDAPv3,
512 which is now being defined within the IETF.
514 Note that certificates and revocation lists will be transferred using
515 this mechanism rather than the string encodings in RFC 1778 and
516 client systems which do not understand this encoding may experience
517 problems with these attributes.
521 An application providing a LDAP repository read service, LDAP
522 repository search service, or LDAP repository modify service MUST
523 support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
526 An application providing a LDAP repository read service, LDAP
527 repository search service, or LDAP repository modify service MAY
528 support LDAPv2 transport over other reliable transports as well.
530 10. Security Considerations
532 Since the elements of information which are key to the PKI service
533 (certificates and CRLs) are both digitally signed pieces of
534 information, additional integrity service is NOT REQUIRED. As
535 neither information element need be kept secret and anonymous access
536 to such information, for retrieval purposes is generally acceptable,
537 privacy service is NOT REQUIRED for information retrieval requests.
539 CAs have additional requirements, including modification of PKI
540 information. Simple authentication alone is not sufficient for these
541 purposes. It is RECOMMENDED that some stronger means of
542 authentication and/or (if simple authentication is used) some means
543 of protecting the privacy of the password is used, (e.g. accept
544 modifications only via physically secure networks, use IPsec, use SSH
545 or TLS or SSL tunnel). Without such authentication, it is possible
546 that a denial-of-service attack could occur where the attacker
547 replaces valid certificates with bogus ones.
549 For the LDAP repository modify service, profiled in section 7, there
550 are some specific security considerations with respect to access
551 control. These controls apply to a repository which is under the same
552 management control as the CA. Organizations operating directories are
553 NOT REQUIRED to provide external CAs access permission to their
562 Boeyen, et al. Standards Track [Page 10]
564 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
567 The CA MUST have access control permissions allowing it to:
570 - add, modify and delete all PKI attributes for its own
572 - add, modify and delete all values of these attributes.
574 For CRL distribution point entries (if used):
575 - create, modify and delete entries of object class
576 cRLDistributionPoint immediately subordinate to its own
578 - add, modify and delete all attributes, and all values of
579 these attributes for these entries.
581 For subscriber (end-entity) entries:
582 - add, modify and delete the attribute userCertificate and all
583 values of that attribute, issued by this CA to/from these
586 The CA is the ONLY entity with these permissions.
588 An application providing LDAP repository read, LDAP repository
589 search, or LDAP repository modify service as defined in this
590 specification is NOT REQUIRED to implement any additional security
591 features other than those described herein, however an implementation
596 [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
597 Protocol", RFC 1777, March 1995.
599 [2] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
600 Representation of Standard Attribute Syntaxes", RFC 1778, March
603 [3] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
604 Levels", BCP 14, RFC 2119, March 1997.
618 Boeyen, et al. Standards Track [Page 11]
620 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
623 12. Authors' Addresses
626 Entrust Technologies Limited
631 EMail: sharon.boeyen@entrust.com
635 Netscape Communications Corp.
636 501 E. Middlefield Rd.
637 Mountain View, CA 94043
640 EMail: howes@netscape.com
645 Suite 1001, 701 W. Georgia Street
651 EMail: patr@xcert.com
674 Boeyen, et al. Standards Track [Page 12]
676 RFC 2559 PKIX Operational Protocols - LDAPv2 April 1999
679 13. Full Copyright Statement
681 Copyright (C) The Internet Society (1999). All Rights Reserved.
683 This document and translations of it may be copied and furnished to
684 others, and derivative works that comment on or otherwise explain it
685 or assist in its implementation may be prepared, copied, published
686 and distributed, in whole or in part, without restriction of any
687 kind, provided that the above copyright notice and this paragraph are
688 included on all such copies and derivative works. However, this
689 document itself may not be modified in any way, such as by removing
690 the copyright notice or references to the Internet Society or other
691 Internet organizations, except as needed for the purpose of
692 developing Internet standards in which case the procedures for
693 copyrights defined in the Internet Standards process must be
694 followed, or as required to translate it into languages other than
697 The limited permissions granted above are perpetual and will not be
698 revoked by the Internet Society or its successors or assigns.
700 This document and the information contained herein is provided on an
701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
730 Boeyen, et al. Standards Track [Page 13]