Network Working Group                                      S. BoeyenRequest for Comments: 2559                                   EntrustUpdates: 1778                                               T. HowesCategory: Standards Track                                   Netscape                                                          P. Richard                                                               Xcert                                                          April 1999                Internet X.509 Public Key Infrastructure                     Operational Protocols - LDAPv2Status 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.1.  Abstract   The protocol described in this document is designed to satisfy some   of the operational requirements within the Internet X.509 Public Key   Infrastructure (IPKI).  Specifically, this document addresses   requirements to provide access to Public Key Infrastructure (PKI)   repositories for the purposes of retrieving PKI information and   managing that same information.  The mechanism described in this   document is based on the Lightweight Directory Access Protocol (LDAP)   v2, defined in RFC 1777, defining a profile of that protocol for use   within the IPKI and updates encodings for certificates and revocation   lists from RFC 1778. Additional mechanisms addressing PKIX   operational requirements are specified in separate documents.   The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'   in this document are to be interpreted as described in RFC 2119.2.  Introduction   This specification is part of a multi-part standard for development   of a Public Key Infrastructure (PKI) for the Internet. This   specification addresses requirements to provide retrieval of X.509   PKI information, including certificates and CRLs from a repository.   This specification also addresses requirements to add, delete andBoeyen, et al.              Standards Track                     [Page 1]RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999   modify PKI information in a repository. A profile based on the LDAP   version 2 protocol is provided to satisfy these requirements.3.  Model   The PKI components, as defined in PKIX Part 1, which are involved in   PKIX operational protocol interactions include:      -  End Entities      -  Certification Authorities (CA)      -  Repository   End entities and CAs using LDAPv2, retrieve PKI information from the   repository using a subset of the LDAPv2 protocol.   CAs populate the repository with PKI information using a subset of   the LDAPv2 protocol.4.  Lightweight Directory Access Protocol (LDAP)   The following sections examine the retrieval of PKI information from   a repository and management of PKI information in a repository. A   profile of the LDAPv2 protocol is defined for providing these   services.   Section 5 satisfies the requirement to retrieve PKI information (a   certificate, CRL, or other information of interest) from an entry in   the repository, where the retrieving entity (either an end entity or   a CA) has knowledge of the name of the entry. This is termed   "repository read".   Section 6 satisfies the same requirement as 5 for the situation where   the name of the entry is not known, but some other related   information which may optionally be used as a filter against   candidate entries in the repository, is known.  This is termed   "repository search".   Section 7 satisfies the requirement of CAs to add, delete and modify   PKI information information (a certificate, CRL, or other information   of interest)in the repository. This is termed "repository modify".   The subset of LDAPv2 needed to support each of these functions is   described below.  Note that the repository search service is a   superset of the repository read service in terms of the LDAPv2   functionality needed.   Note that all tags are implicit by default in the ASN.1 definitions   that follow.Boeyen, et al.              Standards Track                     [Page 2]RFC 2559          PKIX Operational Protocols - LDAPv2         April 19995.  LDAP Repository Read   To retrieve information from an entry corresponding to the subject or   issuer name of a certificate, requires a subset of the following   three LDAP operations:     BindRequest (and BindResponse)     SearchRequest (and SearchResponse)     UnbindRequest   The subset of each REQUIRED operation is given below.5.1.  Bind5.1.1.  Bind Request   The full LDAP v2 Bind Request is defined in RFC 1777.   An application providing a LDAP repository read service MUST   implement the following subset of this operation:      BindRequest ::=        [APPLICATION 0] SEQUENCE {           version      INTEGER (2),           name         LDAPDN, -- MUST accept NULL LDAPDN           simpleauth [0] OCTET STRING  -- MUST accept NULL simple           }   An application providing a LDAP repository read service MAY implement   other aspects of the BindRequest as well.   Different services may have different security requirements.  Some   services may allow anonymous search, others may require   authentication. Those services allowing anonymous search may choose   only to allow search based on certain criteria and not others.   A LDAP repository read service SHOULD implement some level of   anonymous search access. A LDAP repository read service MAY implement   authenticated search access.5.1.2.  Bind Response   The full LDAPv2 BindResponse is described in RFC 1777.   An application providing a LDAP repository read service MUST   implement this entire protocol element, though only the following   error codes may be returned from a Bind operation:Boeyen, et al.              Standards Track                     [Page 3]RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999       success                      (0),       operationsError              (1),       protocolError                (2),       authMethodNotSupported       (7),       noSuchObject                 (32),       invalidDNSyntax              (34),       inappropriateAuthentication  (48),       invalidCredentials           (49),       busy                         (51),       unavailable                  (52),       unwillingToPerform           (53),       other                        (80)5.2.  Search5.2.1.  Search Request   The full LDAPv2 SearchRequest is defined in RFC 1777.   An application providing a LDAP repository read service MUST   implement the following subset of the SearchRequest.      SearchRequest ::=        [APPLICATION 3] SEQUENCE {           baseObject     LDAPDN,           scope             ENUMERATED {                             baseObject   (0),                                        },           derefAliases   ENUMERATED {                             neverDerefAliases   (0),                                     },           sizeLimit      INTEGER (0),           timeLimit      INTEGER (0),           attrsOnly      BOOLEAN, -- FALSE only           filter         Filter,           attributes     SEQUENCE OF AttributeType                               }      Filter ::=        CHOICE {          present        [7] AttributeType, -- "objectclass" only                 }   This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"   operation: a base object search with a filter testing for the   existence of the objectClass attribute.Boeyen, et al.              Standards Track                     [Page 4]RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999   An application providing a LDAP repository read service MAY implement   other aspects of the SearchRequest as well.5.2.2.   The full LDAPv2 SearchResponse is defined in RFC 1777.   An application providing a LDAP repository read service over LDAPv2   MUST implement the full SearchResponse.   Note that in the case of multivalued attributes such as   userCertificate a SearchResponse containing this attribute will   include all values, assuming the requester has sufficient access   permissions.  The application/relying party may need to select an   appropriate value to be used. Also note that retrieval of a   certificate from a named entry does not guarantee that the   certificate will include that same Distinguished Name (DN) and in   some cases the subject DN in the certificate may be NULL.5.3.  Unbind   The full LDAPv2 UnbindRequest is defined in RFC 1777.   An application providing a LDAP repository read service MUST   implement the full UnbindRequest.6.  LDAP Repository Search   To search, using arbitrary criteria, for an entry in a repository   containing a certificate, CRL, or other information of interest,   requires a subset of the following three LDAP operations:     BindRequest (and BindResponse)     SearchRequest (and SearchResponse)     UnbindRequest   The subset of each operation REQUIRED is given below.6.1.  Bind   The BindRequest and BindResponse subsets needed are the same as those   described in Section 5.1.   The full LDAP v2 Bind Request is defined in RFC 1777.Boeyen, et al.              Standards Track                     [Page 5]RFC 2559          PKIX Operational Protocols - LDAPv2         April 19996.2.  Search6.2.1.  Search Request   The full LDAPv2 SearchRequest is defined in RFC 1777.   An application providing a LDAP repository search service MUST   implement the following subset of the SearchRequest protocol unit.      SearchRequest ::=        [APPLICATION 3] SEQUENCE {           baseObject     LDAPDN,           scope          ENUMERATED {                               baseObject     (0),                               singleLevel    (1),                               wholeSubtree   (2)                                     },           derefAliases   ENUMERATED {                               neverDerefAliases     (0),                                     },           sizeLimit      INTEGER (0 .. maxInt),           timeLimit      INTEGER (0 .. maxInt),           attrsOnly      BOOLEAN,  -- FALSE only           filter         Filter,           attributes     SEQUENCE OF AttributeType                                }   All aspects of the SearchRequest MUST be supported, except for the   following:   - Only the neverDerefAliases value of derefAliases needs to be     supported   - Only the FALSE value for attrsOnly needs to be supported   This subset provides a more general search capability.  It is a   superset of the SearchRequest subset defined in Section 5.2.1. The   elements added to this service are:   - singleLevel and wholeSubtree scope needs to be supported   - sizeLimit is included   - timeLimit is included   - Enhanced filter capabilityBoeyen, et al.              Standards Track                     [Page 6]RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999   An application providing a LDAP repository search service MAY   implement other aspects of the SearchRequest as well.6.2.2.  Search Response   The full LDAPv2 SearchResponse is defined in RFC 1777.   An application providing a LDAP repository search service over LDAPv2   MUST implement the full SearchResponse.6.3.  Unbind   An application providing a LDAP repository search service MUST   implement the full UnbindRequest.7.  LDAP Repository Modify   To add, delete and modify PKI information in a repository  requires a   subset of the following LDAP operations:     BindRequest (and BindResponse)     ModifyRequest (and ModifyResponse)     AddRequest (and AddResponse)     DelRequest (and DelResponse