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 Netscape P. Richard Xcert 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 2119. 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