[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Draft on X509 Certificate repository
I think this is a valid concern and an appropriate representation of part
of the problem with PKI adoption on a wide scale. The draft proposed below
is a good document, but I think a draft on CRL/CKL storage should also be
prepared as a compliment to the certificate.
Thanks,
Matthew Schwienteck
PricewaterhouseCoopers
Security Integration Services - Directory Services
832-444-8168 (c)
Peter Gietz
<peter.gietz@daasi To: LDAP extension <ietf-ldapext@netscape.com>
.de> cc:
03/11/2002 09:48 Subject: Draft on X509 Certificate repository
AM
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]
----------------------------------------------------------------
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance
upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from any
computer.