Network Working Group                                           P. Gietz
Internet-Draft                                  DAASI International GmbH
Expires: April 25, 2005                                        N. Klasen
                                           Avinci - The Know-How Company
                                                        October 25, 2004



 Internet X.509 Public Key Infrastructure Lightweight Directory Access
                 Protocol Schema for X.509 Certificates
                   draft-ietf-pkix-ldap-pkc-schema-01


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   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 April 25, 2005.


Copyright Notice


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


Abstract


   This document describes a Lightweight Directory Access Protocol
   schema which can be used to implement a certificate store for X.509
   certificates.  Specifically, two structural object classes for X.509
   user and CA certificates are defined.  Key fields of a certificate
   are stored in LDAP attributes so that applications can easily
   retrieve the certificates needed by using basic LDAP search filters.
   Multiple certificates for a single entity can be stored and




Gietz & Klasen           Expires April 25, 2005                 [Page 1]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   retrieved.


Conventions used in this document


   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.  Comparison with Component Matching approach  . . . . . . . . .  6
   4.  X.509 certificate object classes . . . . . . . . . . . . . . .  7
     4.1   X.509 base object class  . . . . . . . . . . . . . . . . .  7
     4.2   X.509 PKC object class . . . . . . . . . . . . . . . . . .  7
     4.3   X.509 user certificate object class  . . . . . . . . . . .  8
     4.4   X.509 CA certificate object class  . . . . . . . . . . . .  8
     4.5   X.509 PKC extensions auxiliary object class  . . . . . . .  9
     4.6   X.509 certificate holder object class  . . . . . . . . . .  9
   5.  The attribute types of the X.509 certificate object classes  .  9
     5.1   Attributes for mandatory fields of an X.509 certificate  . 10
       5.1.1   X.509 version  . . . . . . . . . . . . . . . . . . . . 10
       5.1.2   Serial number  . . . . . . . . . . . . . . . . . . . . 10
       5.1.3   Signature algorithm  . . . . . . . . . . . . . . . . . 10
       5.1.4   Issuer . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.5   Validity . . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.6   Subject  . . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.7   Subject public key info algorithm  . . . . . . . . . . 12
     5.2   Attributes for selected extensions . . . . . . . . . . . . 12
       5.2.1   Authority key identifier extension . . . . . . . . . . 13
       5.2.2   Subject key identifier extension . . . . . . . . . . . 14
       5.2.3   Key usage extension  . . . . . . . . . . . . . . . . . 14
       5.2.4   Policy information identifier extension  . . . . . . . 14
       5.2.5   Subject alternative name extension . . . . . . . . . . 15
       5.2.6   Issuer alternative name extension  . . . . . . . . . . 16
       5.2.7   Basic constraints extension  . . . . . . . . . . . . . 18
       5.2.8   Extended key usage extension . . . . . . . . . . . . . 19
       5.2.9   CRL distribution points extension  . . . . . . . . . . 19
     5.3   Additional attributes  . . . . . . . . . . . . . . . . . . 20
       5.3.1   Certificate location . . . . . . . . . . . . . . . . . 20




Gietz & Klasen           Expires April 25, 2005                 [Page 2]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



       5.3.2   Certificate holder . . . . . . . . . . . . . . . . . . 20
   6.  DIT structure and naming . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10.1  Normative references . . . . . . . . . . . . . . . . . . . . 23
   10.2  Non-normative references . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  Sample directory entries . . . . . . . . . . . . . . . . . . . 25
   B.  Sample searches  . . . . . . . . . . . . . . . . . . . . . . . 28
   C.  Changes from previous Drafts . . . . . . . . . . . . . . . . . 29
     C.1   Changes in draft-klasen-ldap-x509certificate-schema-01 . . 29
     C.2   Changes in draft-klasen-ldap-x509certificate-schema-02 . . 29
     C.3   Changes in draft-klasen-ldap-x509certificate-schema-03 . . 29
     C.4   Changes in draft-ietf-pkix-ldap-pkc-schema-00  . . . . . . 30
     C.5   Changes in draft-ietf-pkix-ldap-pkc-schema-01  . . . . . . 31
       Intellectual Property and Copyright Statements . . . . . . . . 32


































Gietz & Klasen           Expires April 25, 2005                 [Page 3]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



1.  Introduction


   A key component in the wide-spread adoption of a Public Key
   Infrastructure is the general availability of public keys and their
   certificates.  Today, certificates are often published in an X.500
   compliant directory service.  These directories are accessed by
   applications using the LDAP v3 [RFC3377] protocol.  An LDAPv3 schema
   for PKI repository objects is specified in [pkix-ldap-schema], where
   a set of object classes, attribute types, syntaxes, and extended
   matching rules are defined.  For storing certificates, the
   "userCertificate" and "cACertificate" attribute types are used.  All
   certificates of an entity are stored as values in these multi-valued
   attributes.  This solution has a serious drawback.  In LDAP, the
   smallest granularity of data access is the attribute.  The directory
   server will therefore always return the full list of certificates of
   an entry to clients dealing with certificates.  If the number of
   certificates for an entity is large this will result in considerable
   overhead and burden to the client.


   This document proposes to solve this problem by the use of the
   structural object classes x509userCertificate and x509caCertificate
   for storing certificates.  Each certificate will be stored in a
   separate entry in the directory.  Having each certificate stored in a
   separate entry provides flexibility in structuring the Directory
   Information Tree.  The certificate entries can be stored either below
   a person entry or below a CA entry as a certificate only repository,
   as shown in figure 1.


   1.) below Person entry:


                            person
                           /  |    \
                          /   |     \
                     cert1  cert2   cert3



   2.) below CA cert repository:


                            CA
                             |
                             |
                      certificate repository
                     /       |          \
                    /        |           \
                 cert1     cert2 ...    cert1008



   Figure 1: examples of possible DIT-structures




Gietz & Klasen           Expires April 25, 2005                 [Page 4]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   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
   certificates with simple LDAP filters.  This approach could be named
   a "metadata" approach, since data (attributes) about data
   (certificate) are stored.


   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 (CIP)
   [RFC2651], which defines a protocol between index servers for
   exchanging index objects in order to facilitate query routing.  The
   Tagged Index Object format as specified in [RFC2654] was specified to
   carry directory server information, by collecting the single
   attribute types and values.  By using the schema proposed in this
   document, index objects can include certificate information in
   attributes.


   If certificates are stored redundantly in person entries and in
   certificate entries below the person entries, maintainers of
   repositories MUST make sure that the same certificates are stored in
   the person entry and the respective certificate entries and keep this
   consistency.  Alternatively, they MUST leave out any certificates in
   the person entry.


   This document is part of a set following this metadata approach
   comprising:
   1.  the LDAP schema for X.509 public key certificates (this document)
   2.  the LDAP schema for X.509 attribute certificates [ldap-ac-schema]
   3.  the LDAP schema for X.509 CRLs [ldap-crl-schema]


   Future documents may be written that use the same method for
   Qualified certificates as described in [RFC3039] or any other
   evolving pkix certificate standard.  An auxiliary object class for
   including additional metadata that is not included in the certificate
   is outside the scope of this document.


   Two alternative approaches are discussed in the next two sections.


2.  Comparison with Values Return Filter Control


   In [matchedval] a control has been defined that allows for only a
   subset of values of a specified attribute to be returned from a
   matching entry, by defining a filter for the returned values.  In
   this section, this approach is compared with the one proposed in this
   document.





Gietz & Klasen           Expires April 25, 2005                 [Page 5]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   The major benefit of the Values Return Filter Control is that it does
   not require any changes to the DIT.


   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 ensure the integrity and consistency 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 BER/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
   be necessary to modify existing server implementations to support
   this schema.  The extended matching rules proposed in
   [pkix-ldap-schema] would require substantial changes in the servers'
   indexing mechanisms.  In contrast, servers implementing the
   x509certificate schema can easily leverage their indexing support for
   standard LDAPv3 syntaxes.


   A CIP-based indexing system for a wide scale distributed certificate
   repository will rather be possible by using the solution proposed
   here due to its dependency on attribute values.


3.  Comparison with Component Matching approach


   [RFC3687]Component matching defines a mechanism for matching against
   complex syntaxes, by defining generic matching rules that can match
   against any user selected component parts in an attribute value of
   any arbitrarily complex attribute syntax.  This might prove to be the
   proper way to solve LDAP search problems in the longer term, but it
   will take a long time until such ASN.1 based mechanisms are
   implemented in all LDAP servers and clients.  Even when this has
   happened the mechanism proposed in this document will still be useful




Gietz & Klasen           Expires April 25, 2005                 [Page 6]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   to some applications such as CIP.


   A simple and easy to implement mechanism is needed today to search
   for X.509 attributes.


4.  X.509 certificate object classes


   The object classes have been designed to form a logical set and be
   extensible in an orderly way as new PKC/CRL/AC extensions are
   defined.  The methodology is as follows.  Every X.509 entry (for a
   PKC, CRL or AC) is of the x509base abstract object class.  There is
   then an additional abstract object class for each, derived from
   x509base, which holds the attributes extracted from the basic PKC/AC/
   CRL ASN.1 structure (excluding all extensions).  The PKC object class
   is then instantiated by two structural object classes for user
   certificates and for CA certificates.  The extensions are added by an
   additional auxiliary object class.


   Thus the inheritance chains for PKCs are:



                 x509base                            top
                    |                                 |
                 x509PKC                          x509PKCext
                /       \
               /         \
   x509caCertificate   x509userCertificate




4.1  X.509 base object class


   The x509base object class is the abstract object class that is the
   superior of all of the x.509 entry object classes


   ( 1.3.6.1.4.1.10126.1.5.4.2.1
         NAME 'x509base'
         ABSTRACT
         MAY x509version )



4.2  X.509 PKC object class


   This abstract object class contains the fields of an X.509 user
   certificate or CA certificate that are used in searches as attributes
   and in name forms.  It is derived from the abstract object class
   x.509base as specified in [ldap-crl-schema] and is base for the two
   following object classes.




Gietz & Klasen           Expires April 25, 2005                 [Page 7]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   ( 1.3.6.1.4.1.10126.1.5.4.2.3
         NAME 'x509PKC'
         SUP x509base
         ABSTRACT
         MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $
                x509validityNotBefore $ x509validityNotAfter $
                x509subjectPublicKeyInfoAlgorithm )
         MAY  ( x509certHolder $ x509issuerSerial ) )


   The attribute description of x509issuerSerial can be found in
   [ldap-ac-schema]


4.3  X.509 user certificate object class


   This object class is for storing user certificates.


   ( 1.3.6.1.4.1.10126.1.5.4.2.4
         NAME 'x509userCertificate'
         SUP x509PKC
         STRUCTURAL
         MUST userCertificate
         MAY  x509subject )


   The attribute description of userCertificate can be found in
   [pkix-ldap-schema].  Although this attribute type is specified as
   multi-valued it MUST NOT contain more than one certificate if used
   with this object class.


   The attribute type x509subject is specified here as a MAY attribute.
   Nevertheless if this attribute is not used at least one of the
   following attributes MUST be filled in: x509subjectRfc822Name,
   x509subjectDnsName, x509subjectDirectoryName, x509subjectURI,
   x509subjectIpAddress, or x509subjectRegisteredID.


4.4  X.509 CA certificate object class


   This object class is for storing CA certificates.


   ( 1.3.6.1.4.1.10126.1.5.4.2.5
         NAME 'x509caCertificate'
         SUP x509PKC
         STRUCTURAL
         MUST ( caCertificate $ x509subject ) )


   The attribute description of caCertificate can be found in
   [pkix-ldap-schema].  Although this attribute type is specified as
   multi-valued it MUST NOT contain more than one certificate if used
   with this object class.




Gietz & Klasen           Expires April 25, 2005                 [Page 8]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



4.5  X.509 PKC extensions auxiliary object class


   The x509PKCext auxiliary object class is used to hold the attributes
   extracted from the PKC extensions defined in [X.509-2000] and
   profiled in [RFC3280].


   Note.  If a PKC holds additional extensions to these, then another
   auxiliary object class and supporting attributes will need to be
   defined.


   ( 1.3.6.1.4.1.10126.1.5.4.2.6
         NAME 'x509PKCext'
         SUP top
         AUXILIARY
         MAY  ( x509authorityKeyIdentifier $
                x509authorityCertIssuer $
                x509authorityCertSerialNumber $
                x509subjectKeyIdentifier $ x509keyUsage $
                x509policyInformationIdentifier $
                x509subjectRfc822Name $ x509subjectDnsName $
                x509subjectDirectoryName $ x509subjectURI $
                x509subjectIpAddress $ x509subjectRegisteredID $
                x509issuerRfc822Name $ x509issuerDnsName $
                x509issuerDirectoryName $ x509issuerURI $
                x509issuerIpAddress $ x509issuerRegisteredID $
                x509basicConstraintsCa $ x509basicConstraintsPathLen $
                x509extKeyUsage $ x509fullCRLDistributionPointURI ) )



4.6  X.509 certificate holder object class


   This auxiliary object class has an attribute that contains a pointer
   to an entry with x509certicate objectclass.  Thus it is possible to
   link, e.g., an entry of a white pages directory to an entry in a
   certificate store.  Such a link points to the opposite direction of
   the link stored in the attribute type x509certHolder.


   ( 1.3.6.1.4.1.10126.1.5.4.2.2
         NAME 'x509certificateHolder'
         AUXILIARY
         MAY  ( x509certLocation ) )



5.  The attribute types of the X.509 certificate object classes


   The description of all attributes with relevance to fields and
   extensions of an X.509 certificate include a respective reference to
   [X.509-2000] and to [RFC3280].




Gietz & Klasen           Expires April 25, 2005                 [Page 9]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.1  Attributes for mandatory fields of an X.509 certificate


5.1.1  X.509 version


   X.509 Version of the encoded certificate (See X.509(2000) 7, RFC3280
   4.1.2.1.) or of the CRL.


   ( 1.3.6.1.4.1.10126.1.5.3.1
         NAME 'x509version'
         DESC 'X.509 Version of the certificate, or of the CRL'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE )


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


5.1.2  Serial number


   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).  See X.509(2000) 7, RFC3280 4.1.2.2


   ( 1.3.6.1.4.1.10126.1.5.3.2
         NAME 'x509serialNumber'
         DESC 'Unique integer for each certificate issued by a
               particular CA'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )



5.1.3  Signature algorithm


   OID identifying the algorithm used by the CA in signing the
   certificate (see X.509(2000) 7, RFC3280 4.1.2.3) or the CRL.


   ( 1.3.6.1.4.1.10126.1.5.3.3
         NAME 'x509signatureAlgorithm'
         DESC 'OID of the algorithm used by the CA in
               signing the CRL or the certificate'
         EQUALITY objectIdentifierMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
         SINGLE-VALUE )








Gietz & Klasen           Expires April 25, 2005                [Page 10]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.1.4  Issuer


   String representation of the certificate or CRL issuer's
   distinguished name (see X.509(2000) 7, RFC3280 4.1.2.4)


   ( 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'
         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].


5.1.5  Validity


   The "validity" attribute in an X.509 certificate (see X.509(2000) 7,
   RFC3280 4.1.2.5) consists of an ASN.1 sequence of two timestamps
   which define the begin and end of the certificate's validity period.
   This sequence has been split up into two separate 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'
         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'
         EQUALITY generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE )


   Note that the field in the certificate may be in UTC or
   GeneralizedTime format.  If in UTC format, it MUST be converted into
   GeneralisedTime format when creating the attribute value.







Gietz & Klasen           Expires April 25, 2005                [Page 11]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.1.6  Subject


   String representation of the subject's distinguished name (see
   X.509(2000) 7, RFC3280 4.1.2.6).


   ( 1.3.6.1.4.1.10126.1.5.3.7
         NAME 'x509subject'
         DESC 'Distinguished name of the entity associated with this
               public-key'
         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].


5.1.7  Subject public key info algorithm


   OID identifying the algorithm associated with the certified public
   key (see X.509(2000) 7, RFC3280 4.1.2.7).


   ( 1.3.6.1.4.1.10126.1.5.3.8
         NAME 'x509subjectPublicKeyInfoAlgorithm'
         DESC 'OID identifying the algorithm associated with the
               certified public key'
         EQUALITY objectIdentifierMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
         SINGLE-VALUE )



5.2  Attributes for selected extensions


   As this specification intends to facilitate applications in finding
   certificates, only those extensions have to be defined that might be
   searched for.  Thus extensions described in [RFC3280] like the
   following are not dealt with here:
   o  private key usage period extension
   o  policy mappings extension
   o  subject directory attributes extension
   o  basic constraints extension
   o  name constraints extensions
   o  policy constraints extensions
   o  inhibit any policy extension
   o  freshest CRL extension
   o  authority information access extension
   o  subject information access extension






Gietz & Klasen           Expires April 25, 2005                [Page 12]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.2.1  Authority key identifier extension


   This attribute identifies the public key to be used to verify the
   signature on this certificate or CRL (see X.509(2000) 8.2.2.1,
   RFC3280 4.2.1.1).  The key may be identified by an explicit key
   identifier in the keyIdentifier component, by identification of a
   certificate for the key (giving certificate issuer in the
   authorityCertIssuer component and certificate serial number in the
   authorityCertSerialNumber component), or by both explicit key
   identifier and identification of a certificate for the key.


5.2.1.1  Authority key identifier


   ( 1.3.6.1.4.1.10126.1.5.3.11
         NAME 'x509authorityKeyIdentifier'
         DESC 'Key Identifier field of the Authority Key
               Identifier extension'
         EQUALITY octetStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
         SINGLE-VALUE )



5.2.1.2  Authority cert issuer


   ( 1.3.6.1.4.1.10126.1.5.3.12
         NAME 'x509authorityCertIssuer'
         DESC 'Authority Cert Issuer field of the Authority Key
               Identifier extension'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
         SINGLE-VALUE )


   In this specification, only the "Name" choice, encoded according to
   [RFC2253], of the "GeneralName" type may be used.


5.2.1.3  Authority cert serial number


   ( 1.3.6.1.4.1.10126.1.5.3.13
         NAME 'x509authorityCertSerialNumber'
         DESC 'Authority Cert Serial Number field of the
               Authority Key Identifier extension'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE )








Gietz & Klasen           Expires April 25, 2005                [Page 13]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.2.2  Subject key identifier extension


   This attribute identifies the public key being certified (see
   X.509(2000) 8.2.2.2, RFC3280 4.2.1.2).  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'
         EQUALITY octetStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
         SINGLE-VALUE )



5.2.3  Key usage extension


   This attribute defines the purpose (e.g., encipherment, signature,
   certificate signing) of the key contained in the certificate (see
   X.509(2000) 8.2.2.3, RFC3280 4.2.1.3).


   ( 1.3.6.1.4.1.10126.1.5.3.15
         NAME 'x509keyUsage'
         DESC 'Purpose for which the certified public key is used'
         EQUALITY caseIgnoreIA5Match
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )


   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"



5.2.4  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 (see X.509(2000) 8.2.2.6, RFC3280 4.2.1.5).


   ( 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'
         EQUALITY objectIdentifierMatch




Gietz & Klasen           Expires April 25, 2005                [Page 14]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )



5.2.5  Subject alternative name extension


   The subject alternative name extension allows additional identities
   to be bound to the subject of the certificate (see X.509(2000)
   8.3.2.1, RFC3280 4.2.1.7).  Separate attribute types are defined for
   all choices of the ASN.1 type "GeneralName" except for "otherName",
   "x400Address" and "ediPartyName".


5.2.5.1  Subject RFC822 name


   ( 1.3.6.1.4.1.10126.1.5.3.17
         NAME 'x509subjectRfc822Name'
         DESC 'Internet electronic mail address of the entity
               associated with this public-key'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         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 [RFC0822].


5.2.5.2  Subject DNS name


   ( 1.3.6.1.4.1.10126.1.5.3.18
         NAME 'x509subjectDnsName'
         DESC 'Internet domain name of the entity
               associated with this public-key'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         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].


5.2.5.3  Subject directory name


   ( 1.3.6.1.4.1.10126.1.5.3.19
         NAME 'x509subjectDirectoryName'
         DESC 'Distinguished name of the entity
               associated with this public-key'
         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].




Gietz & Klasen           Expires April 25, 2005                [Page 15]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.2.5.4  Subject Uniform Resource Identifier


   ( 1.3.6.1.4.1.10126.1.5.3.20
         NAME  'x509subjectURI'
         DESC 'Uniform Resource Identifier for the World-Wide Web
               of the entity associated with this public-key'
         EQUALITY caseExactIA5Match
         SUBSTR caseExactIA5SubstringsMatch
         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].


5.2.5.5  Subject IP address


   ( 1.3.6.1.4.1.10126.1.5.3.21
         NAME 'x509subjectIpAddress'
         DESC 'Internet Protocol address of the entity
               associated with this public-key'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )


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


5.2.5.6  Subject registered ID


   ( 1.3.6.1.4.1.10126.1.5.3.22
         NAME 'x509subjectRegisteredID'
         DESC 'OID of any registered object identifying the entity
               associated with this public-key'
         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.


5.2.6  Issuer alternative name extension


   The issuer alternative names extension allows additional identities
   to be bound to the subject of the certificate or CRL (see X.509(2000)
   8.3.2.2, RFC3280 4.2.1.8).  Separate attribute types are defined for
   all choices of the ASN.1 type "GeneralName" except for "otherName",
   "x400Address" and "ediPartyName".







Gietz & Klasen           Expires April 25, 2005                [Page 16]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



5.2.6.1  Issuer RFC 822 name


   ( 1.3.6.1.4.1.10126.1.5.3.23
         NAME 'x509issuerRfc822Name'
         DESC 'Internet electronic mail address of the entity who has
               signed and issued the certificate'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         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 [RFC0822].


5.2.6.2  Issuer DNS name


   ( 1.3.6.1.4.1.10126.1.5.3.24
         NAME 'x509issuerDnsName'
         DESC 'Internet domain name of the entity who has
               signed and issued the certificate'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         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].


5.2.6.3  Issuer directory name


   ( 1.3.6.1.4.1.10126.1.5.3.25
         NAME 'x509issuerDirectoryName'
         DESC 'Distinguished name of the entity who has
               signed and issued the certificate'
         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].


5.2.6.4  Issuer Uniform Resource Identifier


   ( 1.3.6.1.4.1.10126.1.5.3.26
         NAME 'x509issuerURI'
         DESC 'Uniform Resource Identifier for the World-Wide Web
               of the entity who has signed and issued the certificate'
         EQUALITY caseExactIA5Match
         SUBSTR caseExactIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )





Gietz & Klasen           Expires April 25, 2005                [Page 17]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



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


5.2.6.5  Issuer IP address


   ( 1.3.6.1.4.1.10126.1.5.3.27
         NAME 'x509issuerIpAddress'
         DESC 'Internet Protocol address of the entity who has
               signed and issued the certificate'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         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].


5.2.6.6  Issuer registered ID


   ( 1.3.6.1.4.1.10126.1.5.3.28
         NAME 'x509issuerRegisteredID'
         DESC 'OID of any registered object identifying the entity who
               has signed and issued the certificate'
         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.


5.2.7  Basic constraints extension


   The basic constraints extension (see X.509(2000) 8.4.2.1, RFC3280
   4.2.1.10) identifies whether the subject of the certificate is a CA
   and the maximum depth of valid certification paths that include this
   certificate.  This can be stored in the following two LDAP
   attributes:


   The attribute x509basicConstraintsCa indicates whether the subject of
   the certificate is a CA.  If the value of this attribute is "TRUE",
   the certificate MUST be stored in the "caCertificate" attribute.


   ( 1.3.6.1.4.1.10126.1.5.3.29
         NAME 'x509basicConstraintsCa'
         DESC 'Identifies whether the subject of the certificate is a
               CA'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         SINGLE-VALUE )





Gietz & Klasen           Expires April 25, 2005                [Page 18]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   The attribute x509basicConstraintsPathlen contains the maximum number
   of non-self-issued intermediate certificates that may follow this
   certificate in a valid certification path.  It is only meaningfull,
   if x509basicConstraintsCa is set to "TRUE".


   ( 1.3.6.1.4.1.10126.1.5.3.33
         NAME 'x509basicConstraintsPathLen'
         DESC 'maximum number of non-self-issued
            intermediate certificates that may follow this
            certificate in a valid certification path.'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE )



5.2.8  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 (see X.509(2000)
   8.2.2.4, RFC3280 4.2.1.13).  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 an OID'
         EQUALITY objectIdentifierMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )



5.2.9  CRL distribution points extension


   This attribute identifies how the full CRL information for this
   certifacte can be obtained (see X.509(2000) 8.6.2.1, RFC3280
   4.2.1.14).


   ( 1.3.6.1.4.1.10126.1.5.3.32
         NAME 'x509fullCRLDistributionPointURI'
         DESC 'URI type of DistributionPointName for the full CRL'
         EQUALITY caseExactIA5Match
         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




Gietz & Klasen           Expires April 25, 2005                [Page 19]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   and the CRL issuer is identical to the certificate issuer.


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


5.3  Additional attributes


5.3.1  Certificate location


   This attribute contains a pointer to the directory entry of a
   certificate.  Thus it is possible to point to the certificate from
   an, e.g., white pages entry.


   ( 1.3.6.1.4.1.10126.1.5.4.74
         NAME 'x509certLocation'
         DESC 'Pointer to a x509certificate Entry'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )



5.3.2  Certificate holder


   This attribute contains a pointer to the directory entry of the end
   entity to which this certificate was issued.  Thus it is possible to
   link a certificate entry in a certificate repository to, e.g., a
   white pages entry of the subject.


   ( 1.3.6.1.4.1.10126.1.5.4.75
         NAME 'x509certHolder'
         DESC 'Pointer to the directory entry of the end entity to which
               this certificate was issued'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )



6.  DIT structure and naming


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


   ( 1.3.6.1.4.1.10126.1.5.5.6
         NAME 'x509userCertificateNameform'




Gietz & Klasen           Expires April 25, 2005                [Page 20]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



         OC x509userCeriticate
         MUST ( x509serialNumber $ x509issuer ) )



   ( 1.3.6.1.4.1.10126.1.5.5.7
         NAME 'x509caCertificateNameform'
         OC x509caCertificate
         MUST ( x509serialNumber $ x509issuer ) )


   There are some LDAP implementations that don't support multi-valued
   RDNs.  These can use following alternative two name forms:


   ( 1.3.6.1.4.1.10126.1.5.5.8
         NAME 'x509PKCAltNameForm'
         OC x509PKC
         MUST x509issuerSerial )


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


   ( 1.3.6.1.4.1.10126.1.5.5.10
         NAME 'x509PKCSerialNumberNameForm'
         OC x509PKC
         MUST x509serialNumber )


   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
   therefore be escaped.  For example, the issuer name in a certificate
   may be:


   x509issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\2c Inc. -
    For authorized use only,OU=Class 1 Public Primary Certification Au
    thority - G2,O=VeriSign\2c Inc.,C=US


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


   dn: x509serialNumber=123456+x509issuer=OU\3dVeriSign Trust Network
    \2cOU\3d(c) 1998 VeriSign\5c\2c Inc. - For authorized use only\2c
    OU\3d Class 1 Public Primary Certification Authority - G2\2cO\3d
    VeriSign\5c\2c Inc.\2cC\3dUS,cn=Joe Example,...







Gietz & Klasen           Expires April 25, 2005                [Page 21]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



7.  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
   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, secure
   authentication MUST have been used to identify the Client when an
   update operation is requested.


   See [RFC2829] for additional information on how to protect sensitive
   LDAP data.


8.  IANA Considerations


   This document uses the OIDs below 1.3.6.1.4.1.10126.1.5 to identify
   the LDAP schema elements described here.  This OID was assigned by
   DAASI International, under its IANA-assigned private enterprise
   allocation [PRIVATE], for use in this specification.


9.  Acknowledgments


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


   The authors wish to thank David Chadwick, Russ Housley, Mikhail
   Sahalayev, Michael Stroeder, and Kurt Zeilenga for their
   contributions 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).


   The last versions of this work were made in the frame of the project
   "PKI/LDAP" funded by the Ministry of Science, Research and The Arts




Gietz & Klasen           Expires April 25, 2005                [Page 22]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   of Baden-Wuerttemberg, Germany.


   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.


10.  References


10.1  Normative references


   [PRIVATE]  IANA, "Private Enterprise Numbers",
              <http://www.iana.org/assignements/enterprise-numbers>.


   [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.


   [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.


   [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.


   [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.


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


   [RFC3280]  Housley, R., Polk, T., Ford, W. and D. Solo, "Internet




Gietz & Klasen           Expires April 25, 2005                [Page 23]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 3280, April 2002.


   [RFC3377]  Hodges, J. and RL. Morgan, "Lightweight Directory Access
              Protocol (v3):  Technical Specification", RFC 3377,
              September 2002.


   [ldap-ac-schema]
              Chadwick, D. and M. Sahalayev, "Internet X.509 Public Key
              Infrastructure -  LDAP Schema for X.509 Attribute
              Certificates", Internet Draft (work in progress), June
              2004, <draft-ietf-pkix-ldap-ac-schema-02.txt>.


   [ldap-crl-schema]
              Chadwick, D. and M. Sahalayev, "Internet X.509 Public Key
              Infrastructure -  LDAP Schema for X.509 CRLs", Internet
              Draft (work in progress), June 2004,
              <draft-ietf-pkix-ldap-crl-schema-02.txt>.


   [pkix-ldap-schema]
              Chadwick, D. and S. Legg, "Internet X.509 Public Key
              Infrastructure -  LDAP Schema and Syntaxes for PKIs",
              Internet Draft (work in progress), June 2002,
              <draft-ietf-pkix-ldap-pki-schema-00.txt>.


10.2  Non-normative references


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


   [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.


   [RFC2654]  Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A
              Tagged Index Object for use in the Common Indexing
              Protocol", RFC 2654, August 1999.


   [RFC2829]  Wahl, M., Alvestrand, H., Hodges, J. and RL. Morgan,
              "Authentication Methods for LDAP", RFC 2829, May 2000.


   [RFC3039]  Santesson, S., Polk, T., Barzin, P. and M. Nystrom,
              "Internet X.509 Public Key Infrastructure Qualified
              Certificate Profile", RFC 3039, January 2001.





Gietz & Klasen           Expires April 25, 2005                [Page 24]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   [RFC3687]  Legg, S., "Lightweight Directory Access Protocol and X.500
              Component Matching Rules", RFC 3687, February 2004.


   [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 (expired), Februar 2000,
              <draft-greenblatt-ldap-certinfo-schema-02.txt>.


   [matchedval]
              Chadwick, D. and S. Mullan, "Returning Matched Values with
              LDAPv3", Internet Draft (work in progress), September
              2002, <draft-ietf-ldapext-matchedval-07.txt>.



Authors' Addresses


   Peter Gietz
   DAASI International GmbH
   Wilhelmstr. 106
   Tuebingen  72074
   DE


   Phone: +49 7071 29 70336
   EMail: peter.gietz@daasi.de
   URI:   http://www.daasi.de/



   Norbert Klasen
   Avinci - The Know-How Company
   Halskestr. 38
   Ratingen  40880
   DE


   EMail: norbert.klasen@avinci.de


Appendix A.  Sample directory entries


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


   dn: x509serialNumber=1429501,EMAILADDRESS=certify@pca.dfn.de,CN=DFN T
    oplevel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsc




Gietz & Klasen           Expires April 25, 2005                [Page 25]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



    hes Forschungsnetz,C=DE
   objectclass: x509base
   objectclass: x509PKC
   objectclass: x509caCertficate
   objectclass: x509PKCext
   x509version: 2
   x509serialNumber: 1429501
   x509issuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Toplevel Certifica
    tion Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsnet
    z,C=DE
   x509validityNotBefore: 20011201121116Z
   x509validityNotAfter: 20100131121116Z
   x509subject: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Toplevel Certific
    ation Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsne
    tz,C=DE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   x509signatureAlgorithm: 1.2.840.113549.1.1.5
   x509basicConstraintsCa: TRUE
   x509subjectKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA=
   x509authorityCertIssuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Tople
    vel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches
    Forschungsnetz,C=DE
   x509authorityCertSerialNumber: 1429501
   x509authorityKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA=
   x509keyUsage: keyCertSign
   x509keyUsage: cRLSign
   x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1
   caCertificate;binary:: MIIG2jCCBcKgAwIBAgIDFc/9MA0GCSqGSIb3DQEBBQUAMI
    GsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MR
    YwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEy
    RERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQ
    EWEmNlcnRpZnlAcGNhLmRmbi5kZTAeFw0wMTEyMDExMjExMTZaFw0xMDAxMzExMjExMT
    ZaMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZX
    R6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQ
    QDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w
    0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQ
    oCggEBAMF5rhMt6zmhxK5oWPwT2FG7Up7T5DovHSD/YKPIRxsvDWmC4dTzByIBLnOmEf
    lk+5KAqAYao6eY1qF0hR4WiS4DjCsn7l3zNo/4i2eF4EmGEksBygb4tRlTThcO7heFX+
    Du5qFoks+ONqa70RlwOr2l53KVwjMXBCtCLFSKRLVuxeh5+Smkm+FuOmwEugndM2n74D
    jjyf9DCOaHGZrHwVDh+Vpy5Ny4bKCSboujRxd5NxsStUshDVbTeS3B8TuzAJbywYWEE7
    erox+7WTfQr8ivSCBhrNJ36VRjAb8hiV9Iuy2TmJYo2oPyC8a3eM3xj9Ku2IW3tS2zpf
    iIzt9xvFMCAwEAAaOCAwEwggL9MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAYL+r
    X4SHijILELPs+g0MTRf33QMIHbBgNVHSMEgdMwgdCAFAYL+rX4SHijILELPs+g0MTRf3
    3QoYGypIGvMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaH
    VuZ3NuZXR6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS
    0wKwYDVQQDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBg
    kqhkiG9w0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZYIDFc/9MAsGA1UdDwQEAwIBBjARBg
    lghkgBhvhCAQEEBAMCAAcwgaUGA1UdHwSBnTCBmjBLoEmgR4ZFaHR0cDovL3d3dy5kZm




Gietz & Klasen           Expires April 25, 2005                [Page 26]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



    4tcGNhLmRlL2NlcnRpZmljYXRpb24veDUwOS9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcm
    wuY3J4MEugSaBHhkVodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NT
    A5L2cxL2RhdGEvY3Jscy9yb290LWNhLWNybC5jcmwwOAYJYIZIAYb4QgEDBCsWKWh0dH
    BzOi8vd3d3LmRmbi1wY2EuZGUvY2dpL2NoZWNrLXJldi5jZ2k/MEsGCWCGSAGG+EIBCA
    Q+FjxodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi9wb2xpY2llcy94NT
    A5cG9saWN5Lmh0bWwwOAYJYIZIAYb4QgENBCsWKVRoZSBERk4gVG9wLUxldmVsIENlcn
    RpZmljYXRpb24gQXV0aG9yaXR5MGQGA1UdIARdMFswWQYLKwYBBAHZGoIsAQEwSjBIBg
    grBgEFBQcCARY8aHR0cDovL3d3dy5kZm4tcGNhLmRlL2NlcnRpZmljYXRpb24vcG9saW
    NpZXMveDUwOXBvbGljeS5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQAmbai6JMt7nkuavy
    vxKzLGn04Gyt0zKrp8zmERp4inktvY7p+vkaomYu2QYC7cHq0tlrPXQQhhetjiXGb+36
    aJtHDkEA0NwrJzYnHgPsvx7z0wysENP4wxf97KsSWm07RY+f6/gIQF7Je7CW30Rzq7N6
    R0NMBs32mJgdn3ntqlFNw3Nbs050FEjPNq54RdawlJo85x+w+QJd7uQM4yZjHpRhvwgt
    e9Ge1UqCUdpMsLHzeMKJ0B9GhwIIqOJCMiPgKjcUBrn6ehSX70POvXvjjE2+FzhPGTyT
    kS474d2UCAnL9qhPrdWXzBjOumOjhJutT1aecm9eljlshmh1cNen00


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



































Gietz & Klasen           Expires April 25, 2005                [Page 27]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   dn: x509serialNumber=2,ou=DAASI CA,o=DAASI International GmbH,c=DE
   objectClass: x509base
   objectClass: x509PKC
   objectClass: x509userCertificate
   objectClass: x509PKCext
   x509version: 2
   x509serialNumber: 2
   x509issuer: email=ca@daasi.de,ou=DAASI CA,o=DAASI International GmbH,
    c=DE
   x509validityNotBefore: 20040712095656Z
   x509validityNotAfter: 20050713095656Z
   x509subject: email=peter@daasi.de,cn=Peter Gietz,ou=People,o=DAASI In
    ternational GmbH,l=Tuebingen,st=Some-State,c=DE
   x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
   x509signatureAlgorithm: 1.2.840.113549.1.1.5
   x509keyUsage: digitalSignature
   x509keyUsage: nonRepudiation
   x509keyUsage: keyEncipherment
   x509extKeyUsage: 1.3.6.1.5.5.7.3.4
   x509extKeyUsage: 1.3.6.1.5.5.7.3.2
   userCertificate;binary:: MIIDXzCCAkegAwIBAgIBAjANBgkqhkiG9w0BAQUFADBf
    MQswCQYDVQQGEwJERTEhMB8GA1UEChMYREFBU0kgSW50ZXJuYXRpb25hbCBHbWJIMREw
    DwYDVQQLEwhEQUFTSSBDQTEaMBgGCSqGSIb3DQEJARYLY2FAZGFhc2kuZGUwHhcNMDQw
    NzEyMDk1NjU2WhcNMDUwNzEzMDk1NjU2WjCBnzELMAkGA1UEBhMCREUxEzARBgNVBAgT
    ClNvbWUtU3RhdGUxEjAQBgNVBAcTCVR1ZWJp bmdlbjEhMB8GA1UEChMYREFBU0kgSW5
    0ZXJuYXRpb25hbCBHbWJIMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1BldGVyIEd
    pZXR6MR0wGwYJKoZIhvcNAQkBFg5wZXRlckBkYWFzaS5kZTCBnzANBgkqhkiG9w0BAQE
    FAAOBjQAwgYkCgYEAsnuapogKMPEkVFL7WaATMJPFGkijIOgATa9uTdAzwoPS+Pxuk8y
    CK8amM5MfX0O7nkj9Lq36RTUm08hxRGV2gTqRiKuycxulmHU1YXayr4tWrblKwFy69JR
    7TiQvWnCCA83YxEkdmZMjw9qxq5IRtqFHkLmCe+1Uz1jpBvfbr2cCAwEAAaNpMGcwCwY
    DVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAmBglghkgBhvh
    CAQ0EGRYXQW5vbnltb3VzIE1haWwgKFRlc3RDQSkwEQYJYIZIAYb4QgEBBAQDAgUgMA0
    GCSqGSIb3DQEBBQUAA4IBAQB5FDS+GDqEjD69zXUSWNun59JWvVvq5bj7rWzhSgzcAeT
    FQxmErhwSSQcAiIXmARoJfNdF118Lrv9Tuqq3yus7zFUwWKCXhTY9wrtnp3M4dc0ocMP
    bDXE56GFuJOroTgoAOOZV4gp0em49d1wr5tDIJgiL28wzSOLiRT+j2FcfEsu0fSc4UIq
    msU3Jg16dOKCwtexCtz8uii7WhwYCCu7NJK0dBZ0Cas9sQwRzZg5T0+LZiRXpXKJ3Jr6
    5YYjS8iUzbpEDisVgEKVSLuFSNxfQICACZHtwDLOuTcQAWnf0Pps8mVZlQOoRCgd2Nr7
    ChMFx8esGaTFXlOwUitWkDqTa



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:





Gietz & Klasen           Expires April 25, 2005                [Page 28]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   ldap:///CN=Peter%20Gietz,O=DAASI%20International%20GmbH,C=de?
         userCertificate?one?(objectClass=x509userCertificate)


   Find a certificate in a trustcenter's certstore suitable for sending
   an encrypted S/MIME message to "peter@daasi.de"


   ldap:///ou=DAASI%20CA,o=DAASI%20International%20GmbH,c=DE?
          userCertificate?sub?
          (&(&(objectClass=x509userCertificate)
          (x509subjectRfc822Name=peter@daasi.de)
          (|(x509keyUsage=keyEncipherment)
          (x509extKeyUsage=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?sub?
          (&(objectClass=x509caCertificate)(x509subjectKeyIdentifier=
          %5CE6%5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A
          %5C43%5C83%5C78%5C25%5C70%5C52%5CE0%5C19))



Appendix C.  Changes from previous Drafts


C.1  Changes in draft-klasen-ldap-x509certificate-schema-01
   o  Included new Attributes x509authorityKeyIdentifier,
      x509authorityCertissuer, x509authorityCertSerialNumber,
      x509certificateLocation, x509certificateHolder, and new
      objectclass x509certificateHolder
   o  Fixed bug in definition of objectclass x509certificate
   o  Changed references from RFC 2459 to RFC 3280 and included some
      respective language in 3.2.
   o  Changed references from RFC 2251 to RFC 3377 and deleted all
      references to LDAPv2.
   o  Deleted ";binary" in examples
   o  Included new section: Comparision with component matching approach
   o  Some changes in wording and section titles, and elimination of
      typos
   o  Changed order of authors, and one author's address


C.2  Changes in draft-klasen-ldap-x509certificate-schema-02
   o  abstract object class x509PKC
   o  aligned to [ldap-ac-schema] and [ldap-crl-schema]


C.3  Changes in draft-klasen-ldap-x509certificate-schema-03
   o  Changed Matching Rules from caseIgnoreMatch to caseIgnoreIA5Match
      etc.




Gietz & Klasen           Expires April 25, 2005                [Page 29]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   o  moved the references to RFC 3280 from the DESC part of the
      attribute definition to the text
   o  added some additional text about CIP in Introduction
   o  reworded text for x509subjectPublicKeyInfoAlgorithm
   o  changed x509userCert and x509caCert to be inherited from
      userCertificate and caCertificate respectively
   o  added clarification about x509subject and subject alternative
      names
   o  added attribute type x509issuerSerial to x509PKC object class
   o  added attribute type x509basicConstraintsCa to x509PKC object
      class
   o  renamed attribute type x509cRLDistributionPointURI to
      x509FullcRLDistributionPointURI
   o  devided references in normative and non normative
   o  deleted attribute type mail from x509PKC objectclass
   o  created separate Name Forms for x509userCertificate and
      x509caCertificate object classes.
   o  changed attribute type x509SerialNumber to MULTI-VALUE
   o  adjusted examples to new schema
   o  Fixed more typos


C.4  Changes in draft-ietf-pkix-ldap-pkc-schema-00
   o  renamed the title and file name
   o  deleted attribute types x509userCert and x509caCert and replaced
      them with the standard userCertificate and caCertificate attribute
      types.
   o  included the description of x509base object class assigning a new
      OID to it.
   o  separated the extensions attributes from the object class x509PKC
      and included them into the new auxiliary object class x509PKCext
   o  renamed x509issuerUniforResourceIdentifier and
      x509subjectUniforResourceIdentifier to x509issuerURI and
      x509subjectURI respectivly.
   o  replaced separate Name Forms for x509userCertificate and
      x509caCertificate object classes by a single x509PKCNameForm.
   o  included a super section x509 Schema Object Classes with
      introductory remarks (inspired by [ldap-ac-schema])
   o  added some additional wording and some ASCII art in the
      introduction
   o  added some additional wording and some ASCII art in the
      introduction to the object classes
   o  changed the MUST for using multi-valued RDNs into a SHOULD in
      section on DIT Structure and Naming
   o  re-ordered the text so that the section on object classes precedes
      the section on attribute types
   o  included a refernce to RFC 2829 into the security considerations
   o  updated references





Gietz & Klasen           Expires April 25, 2005                [Page 30]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



   o  added an IANA considerations section
   o  added another acknowledgement


C.5  Changes in draft-ietf-pkix-ldap-pkc-schema-01
   o  changed attribute type x509policyInformationIdentifier to
      MULTI-VALUE
   o  added new attribute for stroring the basic contraints path length
      and included it into the x509PKCext object class.












































Gietz & Klasen           Expires April 25, 2005                [Page 31]


Internet-Draft            PKIX LDAP PKC Schema              October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


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





Gietz & Klasen           Expires April 25, 2005                [Page 32]