One document matched: draft-ietf-pkix-ldap-pkc-schema-00.txt
Network Working Group P. Gietz
Internet-Draft DAASI International GmbH
Expires: Januar 10, 2005 N. Klasen
Avinci - The Know-How Company
July 12, 2004
Internet X.509 Public Key Infrastructure Lightweight Directory Access
Protocol Schema for X.509 Certificates
draft-ietf-pkix-ldap-pkc-schema-00
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 Januar 10, 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 Januar 10, 2005 [Page 1]
Internet-Draft PKIX LDAP PKC Schema July 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 . . . . . . . . . . . . . 18
5.2.9 CRL distribution points extension . . . . . . . . . . 19
5.3 Additional attributes . . . . . . . . . . . . . . . . . . 19
5.3.1 Certificate location . . . . . . . . . . . . . . . . . 19
Gietz & Klasen Expires Januar 10, 2005 [Page 2]
Internet-Draft PKIX LDAP PKC Schema July 2004
5.3.2 Certificate holder . . . . . . . . . . . . . . . . . . 20
6. DIT structure and naming . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1 Normative references . . . . . . . . . . . . . . . . . . . . 22
10.2 Non-normative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
A. Sample directory entries . . . . . . . . . . . . . . . . . . . 25
B. Sample searches . . . . . . . . . . . . . . . . . . . . . . . 27
C. Changes from previous Drafts . . . . . . . . . . . . . . . . . 28
C.1 Changes in draft-klasen-ldap-x509certificate-schema-01 . . 28
C.2 Changes in draft-klasen-ldap-x509certificate-schema-02 . . 28
C.3 Changes in draft-klasen-ldap-x509certificate-schema-03 . . 28
C.4 Changes in draft-ietf-pkix-ldap-pkc-schema-00 . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 31
Gietz & Klasen Expires Januar 10, 2005 [Page 3]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 4]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 5]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 6]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 7]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 8]
Internet-Draft PKIX LDAP PKC Schema July 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 $ 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 Januar 10, 2005 [Page 9]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 10]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 11]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 12]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 13]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 14]
Internet-Draft PKIX LDAP PKC Schema July 2004
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE )
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
Gietz & Klasen Expires Januar 10, 2005 [Page 15]
Internet-Draft PKIX LDAP PKC Schema July 2004
given in [RFC2253].
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 Januar 10, 2005 [Page 16]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 17]
Internet-Draft PKIX LDAP PKC Schema July 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
This attribute indicates whether the subject of the certificate is a
CA (see X.509(2000) 8.4.2.1, RFC3280 4.2.1.10). 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 )
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
Gietz & Klasen Expires Januar 10, 2005 [Page 18]
Internet-Draft PKIX LDAP PKC Schema July 2004
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
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 )
Gietz & Klasen Expires Januar 10, 2005 [Page 19]
Internet-Draft PKIX LDAP PKC Schema July 2004
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'
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
Gietz & Klasen Expires Januar 10, 2005 [Page 20]
Internet-Draft PKIX LDAP PKC Schema July 2004
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,...
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
Gietz & Klasen Expires Januar 10, 2005 [Page 21]
Internet-Draft PKIX LDAP PKC Schema July 2004
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
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
Gietz & Klasen Expires Januar 10, 2005 [Page 22]
Internet-Draft PKIX LDAP PKC Schema July 2004
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
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
Gietz & Klasen Expires Januar 10, 2005 [Page 23]
Internet-Draft PKIX LDAP PKC Schema July 2004
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.
[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>.
Gietz & Klasen Expires Januar 10, 2005 [Page 24]
Internet-Draft PKIX LDAP PKC Schema July 2004
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
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
Gietz & Klasen Expires Januar 10, 2005 [Page 25]
Internet-Draft PKIX LDAP PKC Schema July 2004
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
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 Januar 10, 2005 [Page 26]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 27]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 28]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 29]
Internet-Draft PKIX LDAP PKC Schema July 2004
o added an IANA considerations section
o added another acknowledgement
Gietz & Klasen Expires Januar 10, 2005 [Page 30]
Internet-Draft PKIX LDAP PKC Schema July 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 Januar 10, 2005 [Page 31]| PAFTECH AB 2003-2026 | 2026-04-24 03:27:17 |