Internet X.509 Public Key Infrastructure LDAPv2 Schema
RFC 2587

Document Type RFC - Proposed Standard (June 1999; No errata)
Obsoleted by RFC 4523
Authors Sharon Boeyen  , Tim Howes  , Patrick Richard 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2587 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                     S. Boeyen
Request for Comments: 2587                                  Entrust
Category: Standards Track                                  T. Howes
                                                         P. Richard
                                                          June 1999

                Internet X.509 Public Key Infrastructure
                             LDAPv2 Schema

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.

1.  Abstract

   The schema defined in this document is a minimal schema to support
   PKIX in an LDAPv2 environment, as defined in RFC 2559.  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 RFC

2.  Introduction

   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

Boeyen, et al.              Standards Track                     [Page 1]
RFC 2587                   PKIX LDAPv2 Schema                  June 1999

   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.

3.  PKIX Repository Objects

   The primary PKIX objects to be represented in a repository are:

      -  End Entities
      -  Certification Authorities (CA)

   These objects are defined in RFC 2459.

3.1.  End Entities

   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:

Boeyen, et al.              Standards Track                     [Page 2]
RFC 2587                   PKIX LDAPv2 Schema                  June 1999

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) }
Show full document text