[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Draft on X509 Certificate repository
Have you considered a component level matching? It
seems well suited for this kind of application.
<draft-legg-ldapext-component-matching-06.txt>
Kurt
At 07:48 AM 2002-03-11, Peter Gietz wrote:
>FYI,
>
>an Internet-Draft on how to store certificate information in LDAP attributes has been sent to PKIX and will be discussed in Mineapolis.
>
>Any comments from LDAP ext members are most welcome.
>
>Cheers,
>
>Peter
>--
>_______________________________________________________________________
>
>Peter Gietz (CEO)
>DAASI International GmbH phone: +49 7071 2970336
>Wilhelmstr. 106 Fax: +49 7071 295114
>D-72074 Tübingen email: peter.gietz@daasi.de
>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: norbert.klasen@daasi.de
>
>
> Peter Gietz
> DAASI International GmbH
> Wilhelmstr. 106
> Tübingen 72074
> DE
>
> Phone: +49 7071 29 70336
> EMail: peter.gietz@daasi.de
> URI: http://www.daasi.de/
>
>
> Bruce Greenblatt
> DTASI
> 6841 Heaton Moor Drive
> San Jose, CA 95119
> US
>
> Phone: +1 408 224 5349
> EMail: bgreenblatt@directory-applications.com
> 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=certify@pca.dfn.de,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=certify@pca.dfn.de,CN=DFN Toplevel Certificatio
> n Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsnetz,C=DE
> x509validityNotBefore: 20020110170112Z
> x509validityNotAfter: 20060110170112Z
> x509subject: EMAILADDRESS=ca@daasi.de,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: ca@daasi.de
> 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
> tificate@trustcenter.de,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=certificate@trustcenter.de,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=norbert.klasen@daasi.de,CN=Norbert Klasen,C=DE
> x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1
> mail: norbert.klasen@daasi.de
> 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 "norbert.klasen@daasi.de"
>
> ldap:///O=TC%20TrustCenter%20for%20Security%20in%20Data%20Networks
> %20GmbH,L=Hamburg,ST=Hamburg,C=de?userCertificate;binary?sub?
> (&(objectClass=x509certificate)(mail=norbert.klasen@daasi.de)
> (|(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]