Subject: New draft on storing certificates in directories

From: Peter Gietz <[email-masked]>
Date: Fri, 01 Mar 2002 20:04:42 +0100

Hello,

Since quite a while we are dealing with the problem of multiple 
certificates of one entity. As alternative to the Values Return Filter 
Control proposed in draft-ietf-ldapext-matchedval-05.txt we propose
a different approach that might be more scalable with respect to widely 
distributed certificate repositories that are combined by an CIP based 
indexing service.

We had some discussion on this with Bruce Greenblatt and he might want 
to join the team of authors.

So here is (a bit late, but hopefully not too late) our draft, which I 
would very much like to have discussed in Minneapolis. Would it be 
possible to get a small time slot in the pkix WG?

Cheers,

Peter

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

Network Working Group                                          N. Klasen
Internet-Draft                                                  P. Gietz
Expires: August 28, 2002                        DAASI International GmbH

                                                       February 27, 2002

                An LDAPv3 Schema for X.509 Certificates
                  draft-klasen-x509certificate-schema

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes an LDAP schema which can be used to implement
   a certificate store for X.509 certificates.  Specifically, a
   structural object class for a X.509 certificate is defined.  Key
   fields of a certificate are stored as normal attributes so that
   applications can easily retrieve the certficates needed for
   encryption or chain building by using basic LDAP search filters.
   Multiple certificates for a single entity can be stored and retrieved

Conventions used in this document

Klasen, et al.           Expires August 28, 2002                [Page 1]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following syntax specifications use the augmented Backus-Naur
   Form (ABNF) as described in [RFC2234].

   Schema definitions are provided using LDAPv3 description formats
   [RFC2252].  Definitions provided here are formatted (line wrapped)
   for readability.

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   2.      Comparison with Values Return Filter Control . . . . . . .  5
   3.      The x509certificate object class and its attribute types .  6
   3.1     Attributes for mandatory fields of an X.509 certificate  .  6
   3.1.1   x509version  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.2   serialNumber . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1.3   signatureAlgorithm . . . . . . . . . . . . . . . . . . . .  6
   3.1.4   issuer . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.5   validity . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.6   subject  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.7   subjectPublicKeyInfoAlgorithm  . . . . . . . . . . . . . .  8
   3.2     Attributes for selected extensions . . . . . . . . . . . .  8
   3.2.1   Subject key identifier extension . . . . . . . . . . . . .  9
   3.2.2   Key usage extension  . . . . . . . . . . . . . . . . . . .  9
   3.2.3   Policy information identifier extension  . . . . . . . . .  9
   3.2.4   Subject alternative name extension . . . . . . . . . . . . 10
   3.2.4.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2.4.2 DnsName  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2.4.3 DirectoryName  . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.4.4 UniformResourceIdentifier  . . . . . . . . . . . . . . . . 11
   3.2.4.5 IpAddress  . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.4.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5   Isssuer alternatvie name extension . . . . . . . . . . . . 12
   3.2.5.1 Rfc822Name . . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5.2 DnsName  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.5.3 DirectoryName  . . . . . . . . . . . . . . . . . . . . . . 13
   3.2.5.4 UniformResourceIdentifier  . . . . . . . . . . . . . . . . 13
   3.2.5.5 IpAddress  . . . . . . . . . . . . . . . . . . . . . . . . 13
   3.2.5.6 RegisteredID . . . . . . . . . . . . . . . . . . . . . . . 14
   3.2.6   Extended key usage extension . . . . . . . . . . . . . . . 14
   3.2.7   CRL distribution points extension  . . . . . . . . . . . . 14
   3.3     Additional attributes  . . . . . . . . . . . . . . . . . . 15
   3.3.1   Email addresses  . . . . . . . . . . . . . . . . . . . . . 15
   3.4     x509certificate object class . . . . . . . . . . . . . . . 15
   4.      DIT Structure and Naming . . . . . . . . . . . . . . . . . 17

Klasen, et al.           Expires August 28, 2002                [Page 2]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   5.      Security Considerations  . . . . . . . . . . . . . . . . . 19
   6.      Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20
           References . . . . . . . . . . . . . . . . . . . . . . . . 21
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23
   A.      Sample directory entries . . . . . . . . . . . . . . . . . 24
   B.      Sample searches  . . . . . . . . . . . . . . . . . . . . . 27
           Full Copyright Statement . . . . . . . . . . . . . . . . . 28

Klasen, et al.           Expires August 28, 2002                [Page 3]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

1. Introduction

   A key component in the wide-spread adoption of a PKI infrastructure
   is the general availabilty of public key and their certificates.
   Today, certificates are often published in an X.500 compliant
   directory service.  These directories are accessed by applications
   using the LDAP v2 [RFC1777] or v3 [RFC2251] protocol.  [RFC2559]
   defines a subset of LDAP v2 operations required for Internet X.509
   Public Key Infrastructure.  An LDAPv2 schema to PKI repository
   objects is specified in [RFC2587], were a set of attribute types and
   auxiliary object classes are defined.  For stroring certficates, the
   "userCertficate" attribute type is used.  All certificates of an
   entity are stored as values in a multi-valued  attribute.  This
   solution has a serious drawback.  In LDAP, the smallest granularity
   of data access is the attribute.  It is not possible to request a
   specific value of an attribute (see also [matchedval]).  The
   directory server will therefore always return the full list of
   certficates of an entry to applications dealing with certificates.
   If the number of certficates for a entity is large this will result
   in considerable overhead.

   This document proposes the use of the x509certificate structural
   object class for storing certficates.  Each certficate will be stored
   in a separate entry in the directory.  Fields of certificates, which
   are needed to identify a certificate and those which are often used
   in searching for an appropriate certificate, are extracted from the
   certificate and stored as attributes of the entry.  Applications can
   thus search for specific certficates with simple LDAP filters.  The
   use of simple attributes also makes a large scale widely distributed
   certificate repository service possible by using an indexing service
   based on the Common Indexing Protocol [RFC2651].

Klasen, et al.           Expires August 28, 2002                [Page 4]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

2. Comparison with Values Return Filter Control

   In [matchedval] a control has been defined that allows for only
   certain values of a specified attribute to be returned from a
   matching entry.  In this section, this approach is compared with the
   one proposed in this document.  The major benefit of the Values
   Return Filter Control is that it does not require any changes to the
   DIT.  If a customer has deployed certificate information in such a
   way that individual entries have numerous certificates attached to
   them then the Values Return Filter Control is useful.  While it is a
   simple matter to modify the DIT in such a way that all certificate
   information is removed from the entries, and placed in the container
   directly beneath the entries according to the definitions of this
   specification, it is less simple to simultaneously modify all of the
   applications that depend on certificates being stored in the entry.
   Thus, it may be desirable to duplicate the certificate information,
   by having it appear in the entry, as well as in the container beneath
   the entry for a short period of time, in order to allow for migration
   of the applications to the new LDAP schema.  As in any situation in
   which information is duplicated, great care must be taken in order to
   insure the integrity of the information.

   There are several advantages in using the x509certificate object
   class.  No special matching rules are needed to retrieve a specific
   certificate.  Any field in the certificate can be used in the search
   filter.  Even information that doesn't appear in the certificate can
   be used in a search filter.  It is easier to remove certificates from
   the DIT, since the entire certificate DER encoding does not have to
   be supplied in the modify operation.  Searches that don't need
   extensible matching rules and Values Return Filter Control will
   perform faster.

   Another advantage of the solution proposed here is that it will not
   necessary to modify existing server implementations to support this
   schema.  The extended matching rules proposed in [pkix-ldap-schema]
   would require substantial changes the servers' indexing mechanisms.
   In contrast, servers implementing the x509certificate schema can
   easily levarage their indexing support for standard LDAPv3 syntaxes.

Klasen, et al.           Expires August 28, 2002                [Page 5]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3. The x509certificate object class and its attribute types

3.1 Attributes for mandatory fields of an X.509 certificate

3.1.1 x509version

   Version of the encoded certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.1
           NAME 'x509version'
           DESC 'Version of the certificate, X.509(2000) 7, RFC2459 4.1.2.1'
           EQUALITY integerMatch
           ORDERING integerOrderingMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
           SINGLE-VALUE )

   Values of this attribute may either be 0, 1 or 2 correspoding to
   X.509 v1, v2 or v3.

3.1.2 serialNumber

   The serial number is an integer assigned by the CA to each
   certificate.  It is unique for each certificate issued by a given CA
   (i.e., the issuer name and serial number uniquely identify a
   certificate).

   ( 1.3.6.1.4.1.10126.1.5.3.2
   	NAME 'x509serialNumber'
   	DESC 'Unique integer for each cerfiticate issued by a
   	      particular CA, X.509(2000) 7, RFC2459 4.1.2.2'
   	EQUALITY integerMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
   	SINGLE-VALUE )

3.1.3 signatureAlgorithm

   OID identifying the algorithm and hash function used by the CA in
   signing the certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.3
   	NAME 'x509signatureAlgorithm'
   	DESC 'OID of the algorithm and hash function used by the CA in
   	      signing the certificate, X.509(2000) 7, RFC2459 4.1.2.3'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )

Klasen, et al.           Expires August 28, 2002                [Page 6]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.1.4 issuer

   String representation of the issuer's distinguished name.

   ( 1.3.6.1.4.1.10126.1.5.3.4
   	NAME 'x509issuer'
   	DESC 'Distinguished name of the entity who has signed and
   	      issued the certificate, X.509(2000) 7, RFC2459 4.1.2.4'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
   	SINGLE-VALUE )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.1.5 validity

   The "validity" attribute in an X.509 certficate consists of an ASN.1
   sequence of two timestamps, which define the begin and end of the
   certficate's validity period.  This sequence has been split up into
   two seperate attributes "x509validityNotBefore" and
   "x509validityNotAfter".  The times are represented in string form as
   defined in [RFC2252].

   ( 1.3.6.1.4.1.10126.1.5.3.5
   	NAME 'x509validityNotBefore'
   	DESC 'Date on which the certificate validity period begins,
   	      X.509(2000) 7, RFC2459 4.1.2.5'
   	EQUALITY generalizedTimeMatch
   	ORDERING generalizedTimeOrderingMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   	SINGLE-VALUE )

   ( 1.3.6.1.4.1.10126.1.5.3.6
   	NAME 'x509validityNotAfter'
   	DESC 'Date on which the certificate validity period ends,
   	      X.509(2000) 7, RFC2459 4.1.2.5'
   	EQUALITY generalizedTimeMatch
   	ORDERING generalizedTimeOrderingMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   	SINGLE-VALUE )

3.1.6 subject

   String representation of the subject's distinguished name.

Klasen, et al.           Expires August 28, 2002                [Page 7]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   ( 1.3.6.1.4.1.10126.1.5.3.7
   	NAME 'x509subject'
   	DESC 'Distinguished name of the entity associated with this
   	      public-key, X.509(2000) 7, RFC2459 4.1.2.6'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
   	SINGLE-VALUE )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.1.7 subjectPublicKeyInfoAlgorithm

   OID of the algorithm of which the certified public key is an instance
   of.

   ( 1.3.6.1.4.1.10126.1.5.3.8
   	NAME 'x509subjectPublicKeyInfoAlgorithm'
   	DESC 'OID of the algorithm which this public key is an
   	      instance of, X.509(2000) 7, RFC2459 4.1.2.7'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )

3.2 Attributes for selected extensions

   As this specification intends to only facilitate applications in
   finding certficates, only those extensions have to be defined that
   might be searched for.  Thus the following extensions described in
   [RFC2459] are not dealt with here:

   o  authority key identifier extension

   o  private key usage period extension

   o  policy mappings extension

   o  subject directory attributes extension

   o  pathLenConstraint of basic constraints extension

   o  name contraints extensions

   o  policy contraints extensions

   o  inhibit any policy extension

Klasen, et al.           Expires August 28, 2002                [Page 8]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.2.1 Subject key identifier extension

   This attribute identifies the public key being certified.  It enables
   distinct keys used by the same subject to be differentiated.

   ( 1.3.6.1.4.1.10126.1.5.3.14
   	NAME 'x509subjectKeyIdentifier'
   	DESC 'Key identifier which must be unique with respect to all
   	      key identifiers for the subject, X.509(2000) 8.2.2.2,
   	      RFC2459 4.2.1.2'
   	EQUALITY octetStringMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
   	SINGLE-VALUE )

3.2.2 Key usage extension

   This attribute defines the purpose (e.g., encipherment, signature,
   certificate signing) of the key contained in the certificate.

   ( 1.3.6.1.4.1.10126.1.5.3.15
   	NAME 'x509keyUsage'
   	DESC 'Purpose for which the certified public key is used,
   	      X.509(2000) 8.2.2.3, RFC2459 4.2.1.3'
   	EQUALITY caseIgnoreMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Values of this type are encoded according to the following BNF, so
   that each value corresponds to the respective bit in the ASN.1
   "KeyUsage" bitstring:

   x509keyUsage-value ="digitalSignature" / "nonRepudiation" /
   	"keyEncipherment" / "dataEncipherment" / "keyAgreement" /
   	"keyCertSign" / "cRLSign" / "encipherOnly" / "decipherOnly"

3.2.3 Policy information identifier extension

   This attribute contains OIDs which indicate the policy under which
   the certificate has been issued and the purposes for which the
   certificate may be used.

Klasen, et al.           Expires August 28, 2002                [Page 9]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   ( 1.3.6.1.4.1.10126.1.5.3.16
   	NAME 'x509policyInformationIdentifier'
   	DESC 'OID which indicates the policy under which the
   	      certificate has been issued and the purposes for which
   	      the certificate may be used, X.509(2000) 8.2.2.6, RFC2459
   	      4.2.1.5'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   	SINGLE-VALUE )

3.2.4 Subject alternative name extension

   The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Separate attribute
   types are defined for all choices of the ASN.1 type "GeneralName"
   exept for "otherName", "x400Address" and "ediPartyName".

3.2.4.1 Rfc822Name

   ( 1.3.6.1.4.1.10126.1.5.3.17
   	NAME 'x509subjectAltNameRfc822Name'
   	DESC 'Internet electronic mail address, X.509(2000) 8.3.2.1,
   	      RFC2459 4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded accroding to the syntax
   given in [RFC0822].

3.2.4.2 DnsName

   ( 1.3.6.1.4.1.10126.1.5.3.18
   	NAME 'x509subjectAltNameDnsName'
   	DESC 'Internet domain name, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded as Internet domain names in
   accordance with [RFC1035].

Klasen, et al.           Expires August 28, 2002               [Page 10]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.2.4.3 DirectoryName

   ( 1.3.6.1.4.1.10126.1.5.3.19
   	NAME 'x509subjectAltNameDirectoryName'
   	DESC 'Distinguished name, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.2.4.4 UniformResourceIdentifier

   ( 1.3.6.1.4.1.10126.1.5.3.20
   	NAME  'x509subjectAltNameUniformResourceIdentifier'
   	DESC 'Uniform Resource Identifier for the World-Wide Web,
   	      X.509(2000) 8.3.2.1, RFC2459 4.2.1.7'
   	EQUALITY caseExactMatch
   	SUBSTR caseExactSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded according to the syntax
   given in [RFC2396].

3.2.4.5 IpAddress

   ( 1.3.6.1.4.1.10126.1.5.3.21
   	NAME 'x509subjectAltNameIpAddress'
   	DESC 'Internet Protocol address, X.509(2000) 8.3.2.1, RFC2459
   	      4.2.1.7'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute type must be stored in the syntax given in
   Appendix B of [RFC2373].

Klasen, et al.           Expires August 28, 2002               [Page 11]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.2.4.6 RegisteredID

   ( 1.3.6.1.4.1.10126.1.5.3.22
   	NAME 'x509subjectAltNameRegisteredID'
   	DESC 'OID of any registered object, X.509(2000) 8.3.2.1,
   	      RFC2459 4.2.1.7'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

3.2.5 Isssuer alternatvie name extension

   The issuer alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Separate attribute
   types are defined for all choices of the ASN.1 type "GeneralName"
   exept for "otherName", "x400Address" and "ediPartyName".

3.2.5.1 Rfc822Name

   ( 1.3.6.1.4.1.10126.1.5.3.23
   	NAME 'x509isssuerAltNameRfc822Name'
   	DESC 'Internet electronic mail address, X.509(2000) 8.3.2.2,
   	      RFC2459 4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded accroding to the syntax
   given in [RFC0822].

3.2.5.2 DnsName

   ( 1.3.6.1.4.1.10126.1.5.3.24
   	NAME 'x509isssuerAltNameDnsName'
   	DESC 'Internet domain name, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded as Internet domain names in
   accordance with [RFC1035].

Klasen, et al.           Expires August 28, 2002               [Page 12]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.2.5.3 DirectoryName

   ( 1.3.6.1.4.1.10126.1.5.3.25
   	NAME 'x509isssuerAltNameDirectoryName'
   	DESC 'Distinguished name, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY distinguishedNameMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

   Values of this attribute type must be encoded according to the syntax
   given in [RFC2253].

3.2.5.4 UniformResourceIdentifier

   ( 1.3.6.1.4.1.10126.1.5.3.26
   	NAME  'x509isssuerAltNameUniformResourceIdentifier'
   	DESC 'Uniform Resource Identifier for the World-Wide Web,
   	      X.509(2000) 8.3.2.2, RFC2459 4.2.1.8'
   	EQUALITY caseExactMatch
   	SUBSTR caseExactSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute must be encoded according to the syntax
   given in [RFC2396].

3.2.5.5 IpAddress

   ( 1.3.6.1.4.1.10126.1.5.3.27
   	NAME 'x509isssuerAltNameIpAddress'
   	DESC 'Internet Protocol address, X.509(2000) 8.3.2.2, RFC2459
   	      4.2.1.8'
   	EQUALITY caseIgnoreMatch
   	SUBSTR caseIgnoreSubstringsMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   Values of this attribute type must be stored in the syntax given in
   Appendix B of [RFC2373].

Klasen, et al.           Expires August 28, 2002               [Page 13]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.2.5.6 RegisteredID

   ( 1.3.6.1.4.1.10126.1.5.3.28
   	NAME 'x509isssuerAltNameRegisteredID'
   	DESC 'OID of any registered object, X.509(2000) 8.3.2.2,
   	      RFC2459 4.2.1.8'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   registeredID is an identifier of any registered object assigned in
   accordance with ITU-T Rec.  X.660.

3.2.6 Extended key usage extension

   This attribute indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the "x509keyUsage" attribute.  These purposes
   are identified by their OID.

   ( 1.3.6.1.4.1.10126.1.5.3.30
   	NAME 'x509extKeyUsage'
   	DESC 'Purposes for which the certified public key may be used
   	      (identified by OID), X.509(2000) 8.2.2.4, RFC2459
   	      4.2.1.13'
   	EQUALITY objectIdentifierMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

3.2.7 CRL distribution points extension

   This attribute identifies how CRL information for this certifacte can
   be obtained.

   ( 1.3.6.1.4.1.10126.1.5.3.31
   	NAME 'x509cRLDistributionPointURI'
   	DESC 'DistributionPointName of type URI, X.509(2000) 8.6.2.1, RFC2459 4.2.1.13'
   	EQUALITY caseExactMatch
   	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   In this specification, only the "uniformResourceIdentifier" choice of
   "distributionPoint.fullName" field is supported.  If this attribute
   exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be
   absent from the certificate, i.e.  the CRL distributed by the
   distribution point contains revocations for all revocation reasons
   and the CRL issuer is identical to the certificate issuer.

   Values of this attribute must be encoded accroding to the URI syntax
   given in [RFC2396].

Klasen, et al.           Expires August 28, 2002               [Page 14]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

3.3 Additional attributes

3.3.1 Email addresses

   The "mail" (0.9.2342.19200300.100.1.3) attribute from [RFC2798] is
   used to store the subject's email address.  This attribute MUST be
   populated with the values from a subject alternative name extension
   of type rfc822Name if such an extension is present.  Legacy
   applications conforming to [RFC2312] include an "EmailAddress"
   (1.2.840.113549.1.9.1) attribute in the subject's distinguished name.
   If the subject alternative name extension is absent from the
   certificate, this value MUST be used to populate the "mail"
   attribute.

3.4 x509certificate object class

   This structural object class contains the fields of an X.509
   certificate that are used in searches as attributes.

   ( 1.3.6.1.4.1.10126.1.5.4.2.1
   	NAME 'x509certificate'
   	STRUCTURAL
   	MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $
   		x509validityNotBefore $ x509validityNotAfter $ x509subject $
   		x509subjectPublicKeyInfoAlgorithm )
   	MAY  ( mail $ x509authorityKeyIdentifier $
   		x509authorityCertIssuer $ x509authorityCertSerialNumber $
   		x509subjectKeyIdentifier $ x509keyUsage $
   		x509policyInformationIdentifier $
   		x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName $
   		x509subjectAltNameDirectoryName $ x509subjectAltNameURI $
   		x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID $
   		x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName $
   		x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI $
   		x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID $
   		x509basicConstraintsCa $ x509extKeyUsage $
   		x509cRLDistributionPoint ) )

   Entries of this structural object class MUST also have one of the one
   of the following auxiliary object classes: "pkiUser" or "pkiCA".
   This way the entry can contain the binary certificate in the
   "userCertificate" or "caCertficate" attribute.

   These object classes and attribute types are chosen to allow
   interoperability with older clients.  As defined in [X.509-2000] the
   "pkiUser" and "pkiCA" object classes include the "userCertificate"
   and respectivly "caCertficate" attributes as optional attribute.
   Furthermore, both attributes are multi-valued.  For the purpose of

Klasen, et al.           Expires August 28, 2002               [Page 15]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   this specification, each entry with a structural objectclass of
   x509certificate MUST have one and only one value of the
   userCertificate attribute or caCertificate attribute, respectively.

Klasen, et al.           Expires August 28, 2002               [Page 16]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

4. DIT Structure and Naming

   If the schema presented in this document is used to store certficate
   information in a directory that contains entries for organizations,
   persons, services, etc., each certficate belonging to an entity
   SHOULD be stored as a direct subordinate to the entity's entry.  In
   this case, these entries MUST be named by a multi-valued RDN formed
   by the certficate issuer and serial number, as this is the only way
   to enforce unique RDN under the siblings.  This is expressed in the
   following name form:

   ---------------------------------------------------------------------

   ( 1.3.6.1.4.1.10126.1.5.5.1
   	NAME "x509certficate nameform"
   	OC x509certificate
   	MUST ( x509issuer $ x509serial ) )

                          certficate name form

   ---------------------------------------------------------------------

   For public directories of CAs that, besides the data stored in the
   certficates, do not hold any additional data about end entities the
   folloing DIT structure might be preferable.  Entries for certficates
   are stored directly below the issuing CA's entry.  In this case these
   entries SHOULD be named by the certficate serial number.  This is
   expressed in the following name form:

   ---------------------------------------------------------------------

   ( 1.3.6.1.4.1.10126.1.5.5.2
   	NAME "x509certficate alternate nameform"
   	OC x509certificate
   	MUST x509serial )

                     certficate alternate name form

   ---------------------------------------------------------------------

   Care must be taken, when encoding DNs, that contain an x509issuer
   attribute.  Such a value is a string representation according to
   [RFC2253].  These strings contain RFC2253 special characters and must
   therefor be escaped.  For example, the issuer name in a certificate
   may be:

Klasen, et al.           Expires August 28, 2002               [Page 17]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   x509issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\2c Inc. - For aut
    horized use only,OU=Class 1 Public Primary Certification Authority - G2,O=V
    eriSign\2c Inc.,C=US

   When used in a DN, this will be appear as:

   dn: x509serial=123456+x509issuer=OU\3dVeriSign Trust Network \2cOU\3d(c) 199
    8 VeriSign\5c\2c Inc. - For authorized use only\2cOU\3dClass 1 Public Prima
    ry Certification Authority - G2\2cO\3dVeriSign\5c\2c Inc.\2cC\3dUS,cn=Joe E
    xample

Klasen, et al.           Expires August 28, 2002               [Page 18]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

5. Security Considerations

   Attributes of directory entries are used to provide descriptive
   information about the real-world objects they represent, which can be
   people, organizations or devices.  Most countries have privacy laws
   regarding the publication of information about people.

   Without additional mechanisms such as Operation Signatures [RFC2649]
   which allow a client to verify the origin and integrity of the data
   contained in the attributes defined in this document, a client MUST
   NOT treat this data as authentic.  Clients MUST only use - after
   proper validation - the data which they obtained directly from the
   binary certificate.  Directory administrators MAY deploy ACLs which
   limit access to the attributes defined in this document to search
   filters.

   Transfer of cleartext passwords is strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and may
   result in disclosure of the password to unauthorized parties.

   In order to protect the directory and its contents, strong
   authentication MUST have been used to identify the Client when an
   update operation is requested.

Klasen, et al.           Expires August 28, 2002               [Page 19]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

6. Acknowledgements

   This document borrows from a number of IETF documents, including
   [certinfo-schema].

   The authors wish to thank Michael StrÃ¶der for his significant
   contribution to this document.

   This work is part of the DFN Project "Ausbau und Weiterbetrieb eines
   Directory Kompetenzzentrums" funded by the German ministry of
   research (BMBF).

   This document has been written in XML according to the DTD specified
   in RFC2629.  xml2rfc has been used to generate an RFC2033 compliant
   plain text form.  The XML source and a HTML version are available on
   request.

Klasen, et al.           Expires August 28, 2002               [Page 20]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

References

   [RFC0822]           Crocker, D., "Standard for the format of ARPA
                       Internet text messages", STD 11, RFC 822, August
                       1982.

   [RFC1035]           Mockapetris, P., "Domain names - implementation
                       and specification", STD 13, RFC 1035, November
                       1987.

   [RFC1777]           Yeong, W., Howes, T. and S. Kille, "Lightweight
                       Directory Access Protocol", RFC 1777, March 1995.

   [RFC2119]           Bradner, S., "Key words for use in RFCs to
                       Indicate Requirement Levels", BCP 14, RFC 2119,
                       March 1997.

   [RFC2234]           Crocker, D. and P. Overell, "Augmented BNF for
                       Syntax Specifications: ABNF", RFC 2234, November
                       1997.

   [RFC2251]           Wahl, M., Howes, T. and S. Kille, "Lightweight
                       Directory Access Protocol (v3)", RFC 2251,
                       December 1997.

   [RFC2252]           Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
                       "Lightweight Directory Access Protocol (v3):
                       Attribute Syntax Definitions", RFC 2252, December
                       1997.

   [RFC2253]           Wahl, M., Kille, S. and T. Howes, "Lightweight
                       Directory Access Protocol (v3): UTF-8 String
                       Representation of Distinguished Names", RFC 2253,
                       December 1997.

   [RFC2256]           Wahl, M., "A Summary of the X.500(96) User Schema
                       for use with LDAPv3", RFC 2256, December 1997.

   [RFC2312]           Dusse, S., Hoffman, P., Ramsdell, B. and J.
                       Weinstein, "S/MIME Version 2 Certificate
                       Handling", RFC 2312, March 1998.

   [RFC2373]           Hinden, R. and S. Deering, "IP Version 6
                       Addressing Architecture", RFC 2373, July 1998.

   [RFC2396]           Berners-Lee, T., Fielding, R. and L. Masinter,
                       "Uniform Resource Identifiers (URI): Generic
                       Syntax", RFC 2396, August 1998.

Klasen, et al.           Expires August 28, 2002               [Page 21]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   [RFC2459]           Housley, R., Ford, W., Polk, T. and D. Solo,
                       "Internet X.509 Public Key Infrastructure
                       Certificate and CRL Profile", RFC 2459, January
                       1999.

   [RFC2559]           Boeyen, S., Howes, T. and P. Richard, "Internet
                       X.509 Public Key Infrastructure Operational
                       Protocols - LDAPv2", RFC 2559, April 1999.

   [RFC2560]           Myers, M., Ankney, R., Malpani, A., Galperin, S.
                       and C. Adams, "X.509 Internet Public Key
                       Infrastructure Online Certificate Status Protocol
                       - OCSP", RFC 2560, June 1999.

   [RFC2587]           Boeyen, S., Howes, T. and P. Richard, "Internet
                       X.509 Public Key Infrastructure LDAPv2 Schema",
                       RFC 2587, June 1999.

   [RFC2649]           Greenblatt, B. and P. Richard, "An LDAP Control
                       and Schema for Holding Operation Signatures", RFC
                       2649, August 1999.

   [RFC2651]           Allen, J. and M. Mealling, "The Architecture of
                       the Common Indexing Protocol (CIP)", RFC 2651,
                       August 1999.

   [RFC2798]           Smith, M., "Definition of the inetOrgPerson LDAP
                       Object Class", RFC 2798, April 2000.

   [X.501-93]          ITU, "Information  Technology  - Open  Systems
                       Interconnection - The  Directory: Models", ITU-T
                       Recommendation   X.501, November 1993.

   [X.509-2000]        ITU, "Information  Technology - Open Systems
                       Interconnection - The  Directory: Public-key and
                       attribute certificate frameworks", ITU-T
                       Recommendation   X.509, March 2000.

   [certinfo-schema]   Greenblatt, B., "LDAP Object Class for Holding
                       Certificate Information", Internet Draft (work in
                       progress), Februar 2000, <http://
                       www.watersprings.org/pub/id/draft-greenblatt-
                       ldap-certinfo-schema-02.txt>.

   [matchedval]        Chadwick, D. and S. Mullan, "Returning Matched
                       Values with LDAPv3", Internet Draft (work in
                       progress), December 2000, <http://
                       www.watersprings.org/pub/id/draft-ietf-ldapext-

Klasen, et al.           Expires August 28, 2002               [Page 22]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

                       matchedval-05.txt>.

   [pkix-ldap-schema]  Chadwick, D. and S. Legg, "Internet X.509 Public
                       Key Infrastructure - Additional LDAP Schema for
                       PKIs and PMIs", Internet Draft (work in
                       progress), November 2001, <http://
                       www.watersprings.org/pub/id/draft-ietf-pkix-ldap-
                       schema-02.txt>.

Authors' Addresses

   Norbert Klasen
   DAASI International GmbH
   Wilhelmstr. 106
   TÃ¼bingen  72074
   DE

   EMail: [email-masked]

   Peter Gietz
   DAASI International GmbH
   Wilhelmstr. 106
   TÃ¼bingen  72074
   DE

   Phone: +49 7071 29 70336
   EMail: [email-masked]
   URI:   http://www.daasi.de/

   Bruce Greenblatt
   DTASI
   6841 Heaton Moor Drive
   San Jose, CA  95119
   US

   Phone: +1 408 224 5349
   EMail: [email-masked]
   URI:   http://www.dtasi.com/

Klasen, et al.           Expires August 28, 2002               [Page 23]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

Appendix A. Sample directory entries

   A sample x509certificate directory entry for an intermediate CA in
   LDIF format:

   dn: x509serialNumber=4903272,EMAILADDRESS=[email-masked],CN=DFN Topl
    evel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Fo
    rschungsnetz,C=DE
   objectclass: x509certficate
   x509version: 2
   x509serialNumber: 4903272
   x509issuer: EMAILADDRESS=[email-masked],CN=DFN Toplevel Certificatio
    n Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsnetz,C=DE
   x509validityNotBefore: 20020110170112Z
   x509validityNotAfter: 20060110170112Z
   x509subject: EMAILADDRESS=[email-masked],OU=DAASI CA,O=DAASI International
    GmbH,C=DE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   x509basicConstraintsCa: TRUE
   x509keyUsage: keyCertSign
   x509keyUsage: cRLSign
   x509subjectKeyIdentifier:: 5nrZFpVK4RKfIglqQ4N4JXBS4Bk=
   x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/g1
    /data/crls/root-ca-crl.crx
   x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509/g1
    /data/crls/root-ca-crl.crl
   x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1
   mail: [email-masked]
   objectClass: pkiCa
   caCertificate;binary:: MIIHTTCCBjWgAwIBAgIDStFoMA0GCSqGSIb3DQEBBQUAMIGsM
    QswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MRYwFAYD
    VQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEyRERk4gVG9
    wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmNlcnRpZn
    lAcGNhLmRmbi5kZTAeFw0wMjAxMTAxNzAxMTJaFw0wNjAxMTAxNzAxMTJaMF8xCzAJBgNVB
    AYTAkRFMSEwHwYDVQQKExhEQUFTSSBJbnRlcm5hdGlvbmFsIEdtYkgxETAPBgNVBAsTCERB
    QVNJIENBMRowGAYJKoZIhvcNAQkBFgtjYUBkYWFzaS5kZTCCASIwDQYJKoZIhvcNAQEBBQA
    DggEPADCCAQoCggEBAKmQBp+Gr28/qlEWjnJoiH3AwmhNEYMRWgXMXMMjM3S4mSmXZ8FZfT
    SPhi5O1zx5nyHecfl01fAO79Kpc6XkOTOl4iKBwu7+DM6my9Iizp2puhOQ6iuuchAIyJQPR
    0lfWAvvW+4n7Nf13Js5qFHvXBDqvgt6fud1l8XZ4nPWBSbs6OnB4EUDlRLx5fdCX2sEPQIN
    Keu0INMtjHI6eGbspmahup0ArPA9RYZVjVq6ZHkh4205/JAhji9KtFifKCztXNTRMba7AHd
    2uS6GbF9+chGLPWGNZKtMhad1SvU7Zlw/ySHkFbBFZMu6x3kAVgwW8gKQa5qSFnMw/WTKAT
    JRPekCAwEAAaOCA8IwggO+MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdD
    gQWBBTmetkWlUrhEp8iCWpDg3glcFLgGTCB2wYDVR0jBIHTMIHQgBQGC/q1+Eh4oyCxCz7P
    oNDE0X990KGBsqSBrzCBrDELMAkGA1UEBhMCREUxITAfBgNVBAoTGERldXRzY2hlcyBGb3J
    zY2h1bmdzbmV0ejEWMBQGA1UECxMNREZOLUNFUlQgR21iSDEQMA4GA1UECxMHREZOLVBDQT
    EtMCsGA1UEAxMkREZOIFRvcGxldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSEwHwYJK
    oZIhvcNAQkBFhJjZXJ0aWZ5QHBjYS5kZm4uZGWCAxXP/TCBpQYDVR0fBIGdMIGaMEugSaBH
    hkVodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NTA5L2cxL2RhdGEvY3J

Klasen, et al.           Expires August 28, 2002               [Page 24]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

    scy9yb290LWNhLWNybC5jcngwS6BJoEeGRWh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aW
    ZpY2F0aW9uL3g1MDkvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDARBglghkgBhvhCA
    QEEBAMCAQYwSwYJYIZIAYb4QgEIBD4WPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aWZp
    Y2F0aW9uL3BvbGljaWVzL3g1MDlwb2xpY3kuaHRtbDCB+QYJYIZIAYb4QgENBIHrFoHoVGh
    pcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGJ5IHRoZSBERk4tUENBLCB0aGUgVG9wCkxldm
    VsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIHRoZSBHZXJtYW4gUmVzZWFyY2gKTmV0d
    29yayAoRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6LCBERk4pLgpUaGUga2V5IG93bmVyJ3Mg
    aWRlbnRpdHkgd2FzIGF1dGhlbnRpY2F0ZWQgaW4KYWNjb3JkYW5jZSB3aXRoIHRoZSBERk4
    tUENBIHg1MDkgUG9saWN5LjA3BglghkgBhvhCAQMEKhYoaHR0cHM6Ly93d3cuZGZuLXBjYS
    5kZS9jZ2kvY2hlY2stcmV2LmNnaTBkBgNVHSAEXTBbMFkGCysGAQQB2RqCLAEBMEowSAYIK
    wYBBQUHAgEWPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aWZpY2F0aW9uL3BvbGljaWVz
    L3g1MDlwb2xpY3kuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAU9GmwCW6LwsyHfC241afldq
    j/GULv8mfSkUEpK2OtYU1JAYFzmQx69iweOKHbgXZKZA2Wox+9AydIe98MJCSCOFKYjkzgX
    U4fEZbEgnZBo+/1+W2BoB6gFAWy77KVHgimA7AqCcfbObeyCmyfLg1ro8/KpE01OjNr0S+E
    fZ3gX9sezjVkCy12HBNQknz/hT2af25UUhyFTcvUY4xvlKAQpla29qyO28sfO93Qhkum6SU
    2XPlsKU+3lyqF33Xy84Y2z8ScVlsMuVWbUGtmVshnpT5K91n42pu/f0rLtkZDssEDbcLnQD
    LWEz1aUDkLC++4CeFJxC/Dd/SOrE0yR0hNQ=

   A sample x509certificate directory entry for an end identity in LDIF
   format:

Klasen, et al.           Expires August 28, 2002               [Page 25]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

   dn: x509serialNumber=1581631808272310054353257112721713,EMAILADDRESS=cer
    [email-masked],OU=TC TrustCenter Class 1 CA,O=TC TrustCenter f
    or Security in Data Networks GmbH,L=Hamburg,ST=Hamburg,C=DE
   objectclass: x509certficate
   x509version: 2
   x509serialNumber: 1581631808272310054353257112721713
   x509issuer: EMAILADDRESS=[email-masked],OU=TC TrustCenter Cl
    ass 1 CA,O=TC TrustCenter for Security in Data Networks GmbH,L=Hamburg,
    ST=Hamburg,C=DE
   x509validityNotBefore: 20011030180757Z
   x509validityNotAfter: 20021030180757Z
   x509subject: EMAILADDRESS=[email-masked],CN=Norbert Klasen,C=DE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   mail: [email-masked]
   objectClass: pkiUser
   userCertificate;binary:: MIIDOTCCAqKgAwIBAgIOTfsAAAACxOstmlOu2TEwDQYJKoZ
    IhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEw
    dIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0Y
    SBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkw
    JwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw0wMTEwMzAxODA
    3NTdaFw0wMjEwMzAxODA3NTdaME4xCzAJBgNVBAYTAkRFMRcwFQYDVQQDEw5Ob3JiZXJ0IE
    tsYXNlbjEmMCQGCSqGSIb3DQEJARYXbm9yYmVydC5rbGFzZW5AZGFhc2kuZGUwgZ8wDQYJK
    oZIhvcNAQEBBQADgY0AMIGJAoGBAL8+XK98p4YjD7Wq7ApmhAN/j2tfVsFCS0ufy12vGpEt
    G4ny1tbbBORCJI8vIlDr2/vVTESl6UjzceloVUCib5V855mKUVmLL9Ay4qQLFd4wAoRSPAu
    9DkfbR+ygjzaYq+MUKMwaB61sG6911xk/e2/IIq8/IHKrRoYQGmHkaaJpAgMBAAGjgaowga
    cwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lc
    zARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0
    Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS80REZCMDAwMDAwMDJDNEVCMkQ5QTU
    zQUVEOTMxPzANBgkqhkiG9w0BAQQFAAOBgQCrAzuZzLztupeqcHa8OUOcnRuTacMpBEeICb
    ZMKv6mN9rMYkAxFKerj/yXbdCE8/3X3L00eGj+a8A7PumATiJSfmvYqa4EMZwHC2FFqPxYy
    Aj+xVuSlL5AC4HGHu4SOCp/UJu1xysoD16chOOLpj7+ZWZWLHIjA3zeXwUGl4kFvw==

Klasen, et al.           Expires August 28, 2002               [Page 26]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

Appendix B. Sample searches

   This section details how clients should access the certstore.  The
   searches are presented in LDAP URL format.

   Retrieve all certificates for an end entity from a certstore using
   the first DIT structure:

   ldap:///CN=Norbert%20Klasen,O=DAASI%20International%20GmbH,C=de?
   	userCertificate;binary?one?(objectClass=x509certificate)

   Find a certificate in a trustcenter's certstore suitable for sending
   an encrypted S/MIME message to "[email-masked]"

   ldap:///O=TC%20TrustCenter%20for%20Security%20in%20Data%20Networks
   	%20GmbH,L=Hamburg,ST=Hamburg,C=de?userCertificate;binary?sub?
   	(&(objectClass=x509certificate)(mail=[email-masked])
   	 (|(x509keyUsage=keyEncipherment)(x509keyUsage=keyAgreement)
   	   (x509extendedKeyUsage=1.3.6.1.5.5.7.3.4)))

   Find a CA certificate by its "subjectKeyIdentifier" obtained from the
   "keyIdentifier" field of the "autorityKeyIdentifier" extension in an
   end entity certificate:

   ldap:///?caCertificate;binary?sub?
   	(&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6
   	 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43%5C83
   	 %5C78%5C25%5C70%5C52%5CE0%5C19))

Klasen, et al.           Expires August 28, 2002               [Page 27]

Internet-Draft    An LDAPv3 Schema for X.509 Certificates  February 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.

Klasen, et al.           Expires August 28, 2002               [Page 28]