Most of these comments apply to the other two I-Ds. >Network Working Group P. Gietz >Internet-Draft DAASI International GmbH >Expires: April 25, 2005 N. Klasen > Avinci - The Know-How Company > October 25, 2004 > Is "The Know-How Company" part of the company name, or a slogan? If the latter, it should be dropped here and below. > Internet X.509 Public Key Infrastructure Lightweight Directory Access > Protocol Schema for X.509 Certificates > draft-ietf-pkix-ldap-pkc-schema-01 > > >Status of this Memo > > > By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3668. > > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > This Internet-Draft will expire on April 25, 2005. > > >Copyright Notice > > > Copyright (C) The Internet Society (2004). All Rights Reserved. > > >Abstract > > > This document describes a Lightweight Directory Access Protocol > schema which can be used to implement a certificate store for X.509 > certificates. Specifically, two structural object classes for X.509 > user and CA certificates are defined. Key fields of a certificate > are stored in LDAP attributes so that applications can easily > retrieve the certificates needed by using basic LDAP search filters. > Multiple certificates for a single entity can be stored and > retrieved. s/Protocol/Protocol (LDAP)/ Spell out CA. s/applications/clients/ >Conventions used in this document This subsection should be moved into the body of the 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]. As this document itself does not define any syntaxes, I am not sure why this statement exists. > > Schema definitions are provided using LDAPv3 description formats > [RFC2252]. Definitions provided here are formatted (line wrapped) > for readability. > >Table of Contents > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Comparison with Values Return Filter Control . . . . . . . . . 5 > 3. Comparison with Component Matching approach . . . . . . . . . 6 > 4. X.509 certificate object classes . . . . . . . . . . . . . . . 7 > 4.1 X.509 base object class . . . . . . . . . . . . . . . . . 7 > 4.2 X.509 PKC object class . . . . . . . . . . . . . . . . . . 7 > 4.3 X.509 user certificate object class . . . . . . . . . . . 8 > 4.4 X.509 CA certificate object class . . . . . . . . . . . . 8 > 4.5 X.509 PKC extensions auxiliary object class . . . . . . . 9 > 4.6 X.509 certificate holder object class . . . . . . . . . . 9 > 5. The attribute types of the X.509 certificate object classes . 9 > 5.1 Attributes for mandatory fields of an X.509 certificate . 10 > 5.1.1 X.509 version . . . . . . . . . . . . . . . . . . . . 10 > 5.1.2 Serial number . . . . . . . . . . . . . . . . . . . . 10 > 5.1.3 Signature algorithm . . . . . . . . . . . . . . . . . 10 > 5.1.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1.5 Validity . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1.6 Subject . . . . . . . . . . . . . . . . . . . . . . . 12 > 5.1.7 Subject public key info algorithm . . . . . . . . . . 12 > 5.2 Attributes for selected extensions . . . . . . . . . . . . 12 > 5.2.1 Authority key identifier extension . . . . . . . . . . 13 > 5.2.2 Subject key identifier extension . . . . . . . . . . . 14 > 5.2.3 Key usage extension . . . . . . . . . . . . . . . . . 14 > 5.2.4 Policy information identifier extension . . . . . . . 14 > 5.2.5 Subject alternative name extension . . . . . . . . . . 15 > 5.2.6 Issuer alternative name extension . . . . . . . . . . 16 > 5.2.7 Basic constraints extension . . . . . . . . . . . . . 18 > 5.2.8 Extended key usage extension . . . . . . . . . . . . . 19 > 5.2.9 CRL distribution points extension . . . . . . . . . . 19 > 5.3 Additional attributes . . . . . . . . . . . . . . . . . . 20 > 5.3.1 Certificate location . . . . . . . . . . . . . . . . . 20 > 5.3.2 Certificate holder . . . . . . . . . . . . . . . . . . 20 > 6. DIT structure and naming . . . . . . . . . . . . . . . . . . . 20 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 23 > 10.2 Non-normative references . . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 > A. Sample directory entries . . . . . . . . . . . . . . . . . . . 25 > B. Sample searches . . . . . . . . . . . . . . . . . . . . . . . 28 > C. Changes from previous Drafts . . . . . . . . . . . . . . . . . 29 > C.1 Changes in draft-klasen-ldap-x509certificate-schema-01 . . 29 > C.2 Changes in draft-klasen-ldap-x509certificate-schema-02 . . 29 > C.3 Changes in draft-klasen-ldap-x509certificate-schema-03 . . 29 > C.4 Changes in draft-ietf-pkix-ldap-pkc-schema-00 . . . . . . 30 > C.5 Changes in draft-ietf-pkix-ldap-pkc-schema-01 . . . . . . 31 > Intellectual Property and Copyright Statements . . . . . . . . 32 > > > >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 s/Infrastructure/Infrastructure (PKI)/ > compliant directory service. These directories are accessed by s/are/may/ > applications using the LDAP v3 [RFC3377] protocol. An LDAPv3 schema Spell LDAP out on first use. s/applications/clients/ > for PKI repository objects is specified in [pkix-ldap-schema], where Since you referenced RFC3377 here (and RFC2252 above), you should reference RFC2256 here for basic X.509/X.521 schema elements. If you want to reference the revised LDAP TS (draft-ietf-ldapbis-roadmap,models,etc.), then you should reference draft-zeilenga-ldap-x509. > a set of object classes, attribute types, syntaxes, and extended > matching rules are defined. For storing certificates, the s/extended// > "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. Since the introduction of LDAP/X.500 component matching and LDAP Matched Values extensions (both Proposed Standards), this is not true. > 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. The client can and should use LDAP Matched Values control to address this issue. > 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. Spell out CA. With this flexibility comes complexity. > > 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 > > > 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. s/applications/clients/ The attributes seem to copies of the data, not data about the data. I suggest not referring to this as a "metadata" approach. > 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. I would argue that instead of this approach, we design an mechanism for communicating component indexing which can support both LDAP servers w/ component matching facilities as well as external CIP servers which extract values from certificates (obtained from LDAP servers, or elsewhere). This eliminates the need to actual store component values in separate attributes to support CIP, and is certainly no more complex than implementing XPS. Also, this approach ensures that the entry the indices refer to are that of the subject, not some certificate entry. > 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 second MUST says that PKI applications are not to use the standard track schema. That seems inappropriate. If there is a MUST leave out, it should be to leave out these certificate entries. Also, both of these MUSTs appear to apply to maintainers not implementations, and hence likely should be downcased. > 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] Spell out CRL. > 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. s/pkix/PKIX/ Spell out PKIX on first use. > 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. > > The major benefit of the Values Return Filter Control is that it does > not require any changes to the DIT. This one of the major drawbacks to the extraction approach. > 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, Conceptually, maybe. But XPS in itself is a significantly complex program. And implementing a generic parsing server (as needed if this approach spreads to other applications, as invisioned by some), is even more complex. So, I don't think its really "a simple matter". > it is less simple to simultaneously modify all > of the applications that depend on certificates being stored in the > entry. Some would say its not feasible. 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. It is not desirable to duplicate the certificate information. Hence, we should not duplicate the certificate information. > 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. But we cannot ensure integrity and consistency of the information. I wonder what security considerations are appropriate here. I see none are discussed below. > 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. This is not true. Only those fields which have been extracted can be matched. For instance, this mechanism does not by itself provide for matching against components of the subject DN. > Even information that doesn't appear in the certificate can > be used in a search filter. What? If the client wants to ask for all entries whose common name contains X and whose certificate was issued by Y, they cannot do that in one search if the information is held in separate entries. By separating certificate information from the non-certificate information, you are now requiring LDAP to support join capabilties for searches > 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. But the disadvantage of pushing complexity on to clients, adding a parsing server to the system, etc.. > 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 > 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. > > ( 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 ) > This implies there will be two copies of the user's certificate. One in the user's entry and one in userCertificate attribute of x509userCertificate OC, as well as the extracted values. > 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. Which implementations are required to implement this prohibition? > 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. s/filled in/provided/ >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. Which implementations are required to implement this prohibition? > >4.5 X.509 PKC extensions auxiliary object class > > > The x509PKCext auxiliary object class is used to hold the attributes > extracted from the PKC extensions defined in [X.509-2000] and > profiled in [RFC3280]. > > > Note. If a PKC holds additional extensions to these, then another > auxiliary object class and supporting attributes will need to be > defined. > > > ( 1.3.6.1.4.1.10126.1.5.4.2.6 > NAME 'x509PKCext' > SUP top > AUXILIARY > MAY ( x509authorityKeyIdentifier $ > x509authorityCertIssuer $ > x509authorityCertSerialNumber $ > x509subjectKeyIdentifier $ x509keyUsage $ > x509policyInformationIdentifier $ > x509subjectRfc822Name $ x509subjectDnsName $ > x509subjectDirectoryName $ x509subjectURI $ > x509subjectIpAddress $ x509subjectRegisteredID $ > x509issuerRfc822Name $ x509issuerDnsName $ > x509issuerDirectoryName $ x509issuerURI $ > x509issuerIpAddress $ x509issuerRegisteredID $ > x509basicConstraintsCa $ x509basicConstraintsPathLen $ > x509extKeyUsage $ x509fullCRLDistributionPointURI ) ) Why is this inherited from top? Seems it doesn't need a SUP. > >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. pointer or pointers? > ( 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]. > > > > > > > >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 ) why no ordering rule? > > 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 ) > why no ordering rule? why not single-valued? >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 ) > > >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) Define the attribute in abstract terms. That is: This attribute holds the DN of certificate or CRL issuer (see ...). In LDAP, this is transferred using the RFC 2253 string representation, but that doesn't matter to the info model. Much like you did for the above two attributes, you didn't meantion at all the wire encoding format. That simply is not needed. Likewise elsewhere (and not just for this string representation). > > ( 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. > > >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 > > > > > > > > > >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 ) > > > > > > > > > > > >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 > > > > > > > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > > >5.2.5 Subject alternative name extension > > > The subject alternative name extension allows additional identities > to be bound to the subject of the certificate (see X.509(2000) > 8.3.2.1, RFC3280 4.2.1.7). Separate attribute types are defined for > all choices of the ASN.1 type "GeneralName" except for "otherName", > "x400Address" and "ediPartyName". > > >5.2.5.1 Subject RFC822 name > > > ( 1.3.6.1.4.1.10126.1.5.3.17 > NAME 'x509subjectRfc822Name' > DESC 'Internet electronic mail address of the entity > associated with this public-key' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > > Values of this attribute must be encoded according to the syntax > given in [RFC0822]. > > >5.2.5.2 Subject DNS name > > > ( 1.3.6.1.4.1.10126.1.5.3.18 > NAME 'x509subjectDnsName' > DESC 'Internet domain name of the entity > associated with this public-key' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > > Values of this attribute must be encoded as Internet domain names in > accordance with [RFC1035]. > > >5.2.5.3 Subject directory name > > > ( 1.3.6.1.4.1.10126.1.5.3.19 > NAME 'x509subjectDirectoryName' > DESC 'Distinguished name of the entity > associated with this public-key' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > > Values of this attribute type must be encoded according to the syntax > given in [RFC2253]. > > > > > > > >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". > > > > > > > > > > >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 ) > > Values of this attribute must be encoded according to the syntax > given in [RFC2396]. > > >5.2.6.5 Issuer IP address > > > ( 1.3.6.1.4.1.10126.1.5.3.27 > NAME 'x509issuerIpAddress' > DESC 'Internet Protocol address of the entity who has > signed and issued the certificate' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > > Values of this attribute type must be stored in the syntax given in > Appendix B of [RFC2373]. > > >5.2.6.6 Issuer registered ID > > > ( 1.3.6.1.4.1.10126.1.5.3.28 > NAME 'x509issuerRegisteredID' > DESC 'OID of any registered object identifying the entity who > has signed and issued the certificate' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > > registeredID is an identifier of any registered object assigned in > accordance with ITU-T Rec. X.660. > > >5.2.7 Basic constraints extension > > The basic constraints extension (see X.509(2000) 8.4.2.1, RFC3280 > 4.2.1.10) identifies whether the subject of the certificate is a CA > and the maximum depth of valid certification paths that include this > certificate. This can be stored in the following two LDAP > attributes: > > > The attribute x509basicConstraintsCa indicates whether the subject of > the certificate is a CA. If the value of this attribute is "TRUE", > the certificate MUST be stored in the "caCertificate" attribute. > > > ( 1.3.6.1.4.1.10126.1.5.3.29 > NAME 'x509basicConstraintsCa' > DESC 'Identifies whether the subject of the certificate is a > CA' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE ) > > The attribute x509basicConstraintsPathlen contains the maximum number > of non-self-issued intermediate certificates that may follow this > certificate in a valid certification path. It is only meaningfull, > if x509basicConstraintsCa is set to "TRUE". > > ( 1.3.6.1.4.1.10126.1.5.3.33 > NAME 'x509basicConstraintsPathLen' > DESC 'maximum number of non-self-issued > intermediate certificates that may follow this > certificate in a valid certification path.' > EQUALITY integerMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > SINGLE-VALUE ) > > > >5.2.8 Extended key usage extension > > > This attribute indicates one or more purposes for which the certified > public key may be used, in addition to or in place of the basic > purposes indicated in the "x509keyUsage" attribute (see X.509(2000) > 8.2.2.4, RFC3280 4.2.1.13). These purposes are identified by their > OID. > > > ( 1.3.6.1.4.1.10126.1.5.3.30 > NAME 'x509extKeyUsage' > DESC 'Purposes for which the certified public key may be used, > identified by an OID' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > > >5.2.9 CRL distribution points extension > > > This attribute identifies how the full CRL information for this > certifacte can be obtained (see X.509(2000) 8.6.2.1, RFC3280 > 4.2.1.14). > > > ( 1.3.6.1.4.1.10126.1.5.3.32 > NAME 'x509fullCRLDistributionPointURI' > DESC 'URI type of DistributionPointName for the full CRL' > EQUALITY caseExactIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > > In this specification, only the "uniformResourceIdentifier" choice of > "distributionPoint.fullName" field is supported. If this attribute > exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be > absent from the certificate, i.e. the CRL distributed by the > distribution point contains revocations for all revocation reasons > 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. pointer or pointers? > ( 1.3.6.1.4.1.10126.1.5.4.74 > NAME 'x509certLocation' > DESC 'Pointer to a x509certificate Entry' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > > >5.3.2 Certificate holder > > > This attribute contains a pointer to the directory entry of the end > entity to which this certificate was issued. Thus it is possible to > link a certificate entry in a certificate repository to, e.g., a > white pages entry of the subject. pointer or pointers? > ( 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 > 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. Why this statement? > > In order to protect the directory and its contents, secure > authentication MUST have been used to identify the Client when an > update operation is requested. > > > See [RFC2829] for additional information on how to protect sensitive > LDAP data. Reference RFC 2830 as well. > >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. Need to register short names... >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", > . > > > [RFC0822] Crocker, D., "Standard for the format of ARPA Internet > text messages", STD 11, RFC 822, August 1982. > > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997. > > > [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, > "Lightweight Directory Access Protocol (v3): Attribute > Syntax Definitions", RFC 2252, December 1997. > > > [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory > Access Protocol (v3): UTF-8 String Representation of > Distinguished Names", RFC 2253, December 1997. > > > [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use > with LDAPv3", RFC 2256, December 1997. > > > [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. > > > [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform > Resource Identifiers (URI): Generic Syntax", RFC 2396, > August 1998. > > > [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object > Class", RFC 2798, April 2000. > > > [RFC3280] Housley, R., Polk, T., Ford, W. and D. Solo, "Internet > 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, . > > > [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, > . > > > [pkix-ldap-schema] > Chadwick, D. and S. Legg, "Internet X.509 Public Key > Infrastructure - LDAP Schema and Syntaxes for PKIs", > Internet Draft (work in progress), June 2002, > . replace with RFC 2256 or draft-zeilenga-ldap-x509. (See above note.) > >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, > . > > > [matchedval] > Chadwick, D. and S. Mullan, "Returning Matched Values with > LDAPv3", Internet Draft (work in progress), September > 2002, . This is now an RFC. > > >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: Add reference to RFC 2849. > 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 s/EMAILADDRESS/EMAIL/, like below. > x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 > x509signatureAlgorithm: 1.2.840.113549.1.1.5 > x509basicConstraintsCa: TRUE > x509subjectKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA= > x509authorityCertIssuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Tople > vel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches > Forschungsnetz,C=DE > x509authorityCertSerialNumber: 1429501 > x509authorityKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA= > x509keyUsage: keyCertSign > x509keyUsage: cRLSign > x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1 > caCertificate;binary:: MIIG2jCCBcKgAwIBAgIDFc/9MA0GCSqGSIb3DQEBBQUAMI > GsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MR > YwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEy > RERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQ > EWEmNlcnRpZnlAcGNhLmRmbi5kZTAeFw0wMTEyMDExMjExMTZaFw0xMDAxMzExMjExMT > ZaMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZX > R6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQ > QDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w > 0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQ > oCggEBAMF5rhMt6zmhxK5oWPwT2FG7Up7T5DovHSD/YKPIRxsvDWmC4dTzByIBLnOmEf > lk+5KAqAYao6eY1qF0hR4WiS4DjCsn7l3zNo/4i2eF4EmGEksBygb4tRlTThcO7heFX+ > Du5qFoks+ONqa70RlwOr2l53KVwjMXBCtCLFSKRLVuxeh5+Smkm+FuOmwEugndM2n74D > jjyf9DCOaHGZrHwVDh+Vpy5Ny4bKCSboujRxd5NxsStUshDVbTeS3B8TuzAJbywYWEE7 > erox+7WTfQr8ivSCBhrNJ36VRjAb8hiV9Iuy2TmJYo2oPyC8a3eM3xj9Ku2IW3tS2zpf > iIzt9xvFMCAwEAAaOCAwEwggL9MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAYL+r > X4SHijILELPs+g0MTRf33QMIHbBgNVHSMEgdMwgdCAFAYL+rX4SHijILELPs+g0MTRf3 > 3QoYGypIGvMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaH > VuZ3NuZXR6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS > 0wKwYDVQQDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBg > kqhkiG9w0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZYIDFc/9MAsGA1UdDwQEAwIBBjARBg > lghkgBhvhCAQEEBAMCAAcwgaUGA1UdHwSBnTCBmjBLoEmgR4ZFaHR0cDovL3d3dy5kZm > 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: > > 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. Add reference to RFC 2255. Also, I recommended use of example DNs (e.g., dc=example,dc=com). > > Retrieve all certificates for an end entity from a certstore using > the first DIT structure: > > 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 Please note that this appendix is to be removed by the RFC Editor. >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. > > > > > > > > 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 > > > > > > > > > o added an IANA considerations section > o added another acknowledgement > > >C.5 Changes in draft-ietf-pkix-ldap-pkc-schema-01 > o changed attribute type x509policyInformationIdentifier to > MULTI-VALUE > o added new attribute for stroring the basic contraints path length > and included it into the x509PKCext object class. > > > >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. > > > > >