GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2587

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:
  1. End Entities
  2. 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) }
 An end entity may obtain one or more certificates from one or more
 Certification Authorities.  The userCertificate attribute MUST be
 used to represent these certificates in the directory entry
 representing that user.

3.2. Certification Authorities

 As with end entities, Certification Authorities are typically
 represented in directories as auxiliary components of entries
 representing a more generic object, such as organizations,
 organizational units etc. The non PKIX-specific schema elements for
 these entries, such as the structural object class of the object, are
 outside the scope of this specification.
 The following auxiliary object class MAY be used to represent
 Certification Authorities:

pkiCA OBJECT-CLASS ::= {

 SUBCLASS OF   { top}
 KIND          auxiliary
 MAY CONTAIN   {cACertificate |
                certificateRevocationList |
                authorityRevocationList |
                crossCertificatePair }
 ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}

cACertificate ATTRIBUTE ::= {

   WITH SYNTAX   Certificate
   EQUALITY MATCHING RULE   certificateExactMatch
   ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }

crossCertificatePairATTRIBUTE::={

 WITH SYNTAX   CertificatePair
 EQUALITY MATCHING RULE certificatePairExactMatch

ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}

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

 The cACertificate attribute of a CA's directory entry shall be used
 to store self-issued certificates (if any) and certificates issued to
 this CA by CAs in the same realm as this CA.
 The forward elements of the crossCertificatePair attribute of a CA's
 directory entry shall be used to store all, except self-issued
 certificates issued to this CA.  Optionally, the reverse elements of
 the crossCertificatePair attribute, of a CA's directory entry may
 contain a subset of certificates issued by this CA to other CAs.
 When both the forward and the reverse elements are present in a
 single attribute value, issuer name in one certificate shall match
 the subject name in the other and vice versa, and the subject public
 key in one certificate shall be capable of verifying the digital
 signature on the other certificate and vice versa.
 When a reverse element is present, the forward element value and the
 reverse element value need not be stored in the same attribute value;
 in other words, they can be stored in either a single attribute value
 or two attribute values.
 In the case of V3 certificates, none of the above CA certificates
 shall include a basicConstraints extension with the cA value set to
 FALSE.
 The definition of realm is purely a matter of local policy.
    certificateRevocationListATTRIBUTE::={
         WITH SYNTAX  CertificateList
         EQUALITY MATCHING RULE certificateListExactMatch
      ID joint-iso-ccitt(2) ds(5) attributeType(4)
         certificateRevocationList(39)}
 The certificateRevocationList attribute, if present in a particular
 CA's entry, contains CRL(s) as defined in RFC 2459.
    authorityRevocationListATTRIBUTE::={
       WITH SYNTAX   CertificateList
       EQUALITY MATCHING RULE certificateListExactMatch
     ID joint-iso-ccitt(2) ds(5) attributeType(4)
        authorityRevocationList(38)}
 The authorityRevocationList attribute, if present in a particular
 CA's entry, includes revocation information regarding certificates
 issued to other CAs.

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

3.2.1. CRL distribution points

 CRL distribution points are an optional mechanism, specified in RFC
 2459, which MAY be used to distribute revocation information.
 A patent statement regarding CRL distribution points can be found at
 the end of this document.
 If a CA elects to use CRL distribution points, the following object
 class is used to represent these.

cRLDistributionPoint OBJECT-CLASS::= {

  SUBCLASS OF     { top }
  KIND            structural
  MUST CONTAIN    { commonName }
  MAY CONTAIN     { certificateRevocationList |
                    authorityRevocationList |
                    deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
 The certificateRevocationList and authorityRevocationList attributes
 are as defined above.
 The commonName attribute and deltaRevocationList attributes, defined
 in X.509, are duplicated below.
    commonName   ATTRIBUTE::={
       SUBTYPE OF     name
       WITH SYNTAX   DirectoryString
       ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
    deltaRevocationList        ATTRIBUTE ::= {
       WITH SYNTAX             CertificateList
       EQUALITY MATCHING RULE  certificateListExactMatch
       ID joint-iso-ccitt(2) ds(5) attributeType(4)
          deltaRevocationList(53) }

3.2.2. Delta CRLs

 Delta CRLs are an optional mechanism, specified in RFC 2459, which
 MAY be used to enhance the distribution of revocation information.
 If a CA elects to use delta CRLs, the following object class is used
 to represent these.

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

    deltaCRL   OBJECT-CLASS::= {
       SUBCLASS OF     { top }
       KIND            auxiliary
       MAY CONTAIN     { deltaRevocationList }
       ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }

4. Security Considerations

 Since the elements of information which are key to the PKI service
 (certificates and CRLs) are both digitally signed pieces of
 information, no additional integrity service is REQUIRED.
 Security considerations with respect to retrieval, addition,
 deletion, and modification of the information supported by this
 schema definition are addressed in RFC 2559.

5. References

 [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
      Protocol", RFC 1777, March 1995.
 [2]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

6 Intellectual Property Rights

 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this
 document.  For more information consult the online list of claimed
 rights.
 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights. Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11. Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.

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

7. Authors' Addresses

 Sharon Boeyen
 Entrust Technologies Limited
 750 Heron Road
 Ottawa, Ontario
 Canada K1V 1A7
 EMail: sharon.boeyen@entrust.com
 Tim Howes
 Netscape Communications Corp.
 501 E. Middlefield Rd.
 Mountain View, CA 94043
 USA
 EMail: howes@netscape.com
 Patrick Richard
 Xcert Software Inc.
 Suite 1001, 701 W. Georgia Street
 P.O. Box 10145
 Pacific Centre
 Vancouver, B.C.
 Canada V7Y 1C6
 EMail: patr@xcert.com

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

Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Boeyen, et al. Standards Track [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2587.txt · Last modified: 1999/06/04 22:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki