idnits 2.17.1 draft-klasen-ldap-x509certificate-schema-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 4) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 144 characters in excess of 72. == There are 41 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2003) is 7724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2256' is defined on line 918, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Downref: Normative reference to an Historic RFC: RFC 2312 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Experimental RFC: RFC 2649 ** Downref: Normative reference to an Informational RFC: RFC 2798 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gietz 3 Internet-Draft DAASI International GmbH 4 Expires: September 4, 2003 N. Klasen 5 Avinci 6 March 3, 2003 8 An LDAPv3 Schema for X.509 Certificates 9 draft-klasen-ldap-x509certificate-schema-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 4, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document describes an LDAP schema which can be used to implement 41 a certificate store for X.509 certificates. Specifically, a 42 structural object class for a X.509 certificate is defined. Key 43 fields of a certificate are stored in LDAP attributes so that 44 applications can easily retrieve the certificates needed by using 45 basic LDAP search filters. Multiple certificates for a single entity 46 can be stored and retrieved. 48 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 The following syntax specifications use the augmented Backus-Naur 54 Form (ABNF) as described in [RFC2234]. 56 Schema definitions are provided using LDAPv3 description formats 57 [RFC2252]. Definitions provided here are formatted (line wrapped) 58 for readability. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Comparison with Values Return Filter Control . . . . . . . 5 64 3. Comparision with component matching approach . . . . . . . 6 65 4. The x509certificate object class and its attribute types . 6 66 4.1 Attributes for mandatory fields of an X.509 certificate . 7 67 4.1.1 X.509 version . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1.2 Serial number . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.3 Signature algorithm . . . . . . . . . . . . . . . . . . . 7 70 4.1.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.5 Validity . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1.6 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.7 Subject public key info algorithm . . . . . . . . . . . . 9 74 4.2 Attributes for selected extensions . . . . . . . . . . . . 9 75 4.2.1 Authority key identifier extension . . . . . . . . . . . . 10 76 4.2.1.1 Authority key identifier . . . . . . . . . . . . . . . . . 10 77 4.2.1.2 Authority cert issuer . . . . . . . . . . . . . . . . . . 10 78 4.2.1.3 Authority cert serial number . . . . . . . . . . . . . . . 11 79 4.2.2 Subject key identifier extension . . . . . . . . . . . . . 11 80 4.2.3 Key usage extension . . . . . . . . . . . . . . . . . . . 11 81 4.2.4 Policy information identifier extension . . . . . . . . . 12 82 4.2.5 Subject alternative name extension . . . . . . . . . . . . 12 83 4.2.5.1 Subject RFC822 name . . . . . . . . . . . . . . . . . . . 12 84 4.2.5.2 Subject DNS name . . . . . . . . . . . . . . . . . . . . . 13 85 4.2.5.3 Subject directory name . . . . . . . . . . . . . . . . . . 13 86 4.2.5.4 Subject Uniform Resource Identifier . . . . . . . . . . . 13 87 4.2.5.5 Subject IP address . . . . . . . . . . . . . . . . . . . . 14 88 4.2.5.6 Subject registered ID . . . . . . . . . . . . . . . . . . 14 89 4.2.6 Isssuer alternatvie name extension . . . . . . . . . . . . 14 90 4.2.6.1 Issuer RFC 822 name . . . . . . . . . . . . . . . . . . . 14 91 4.2.6.2 Issuer DNS name . . . . . . . . . . . . . . . . . . . . . 15 92 4.2.6.3 Issuer directory name . . . . . . . . . . . . . . . . . . 15 93 4.2.6.4 Issuer Uniform Resource Identifier . . . . . . . . . . . . 15 94 4.2.6.5 Issuer IP address . . . . . . . . . . . . . . . . . . . . 16 95 4.2.6.6 Issuer registered ID . . . . . . . . . . . . . . . . . . . 16 96 4.2.7 Extended key usage extension . . . . . . . . . . . . . . . 16 97 4.2.8 CRL distribution points extension . . . . . . . . . . . . 16 98 4.3 Additional attributes . . . . . . . . . . . . . . . . . . 17 99 4.3.1 Certificate location . . . . . . . . . . . . . . . . . . . 17 100 4.3.2 Certificate holder . . . . . . . . . . . . . . . . . . . . 17 101 4.3.3 Email addresses . . . . . . . . . . . . . . . . . . . . . 17 102 4.4 x509certificate object class . . . . . . . . . . . . . . . 18 103 4.5 x509certificateHolder object class . . . . . . . . . . . . 19 104 5. DIT Structure and Naming . . . . . . . . . . . . . . . . . 19 105 6. Security Considerations . . . . . . . . . . . . . . . . . 20 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21 107 References . . . . . . . . . . . . . . . . . . . . . . . . 21 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23 109 A. Sample directory entries . . . . . . . . . . . . . . . . . 23 110 B. Sample searches . . . . . . . . . . . . . . . . . . . . . 26 111 C. Changes from previous Drafts . . . . . . . . . . . . . . . 26 112 C.1 Changes in Draft 01 . . . . . . . . . . . . . . . . . . . 26 113 Full Copyright Statement . . . . . . . . . . . . . . . . . 28 115 1. Introduction 117 A key component in the wide-spread adoption of a PKI infrastructure 118 is the general availabilty of public key and their certificates. 119 Today, certificates are often published in an X.500 compliant 120 directory service. These directories are accessed by applications 121 using the LDAP v3 [RFC3377] protocol. An LDAPv3 schema for PKI 122 repository objects is specified in [pkix-ldap-schema], where a set of 123 object classes, attribute types, syntaxes, and extended matching 124 rules are defined. For storing certificates, the "userCertificate" 125 and "cACertificate" attribute types are used. All certificates of an 126 entity are stored as values in these multi-valued attributes. This 127 solution has a serious drawback. In LDAP, the smallest granularity 128 of data access is the attribute. The directory server will therefore 129 always return the full list of certificates of an entry to clients 130 dealing with certificates. If the number of certificates for an 131 entity is large this will result in considerable overhead and burden 132 to the client. 134 This document proposes to solve this problem by the use of the 135 structural object classes x509userCertificate and x509caCertificate 136 for storing certificates. Each certificate will be stored in a 137 separate entry in the directory. Fields of certificates which are 138 needed to identify a certificate and those which are often used in 139 searching for an appropriate certificate, are extracted from 140 the certificate and stored as attributes of the entry. Applications 141 can thus search for specific certificates with simple LDAP filters. 142 This approach could be named a metadata approach, since data 143 (attributes) about data (certificate) are stored. The use of simple 144 attributes also makes a large scale widely distributed certificate 145 repository service possible by using an indexing service based on The 146 Common Indexing Protocol (CIP) [RFC2651]. 148 This document is one of a set following this approach comprising: 149 i) the LDAP schema for X.509 public key certificates (this document) 150 ii) the LDAP schema for X.509 attribute certificates [ldap-ac-schema] 151 iii) the LDAP schema for X.509 CRLs [ldap-crl-schema] 153 Two alternative approaches are discussed in the next two sections. 155 2. Comparison with Values Return Filter Control 157 In [matchedval] a control has been defined that allows for only a 158 subset of values of a specified attribute to be returned from a 159 matching entry, by defining a filter for the returned values. In 160 this section, this approach is compared with the one proposed in this 161 document. 163 The major benefit of the Values Return Filter Control is that it does 164 not require any changes to the DIT. While it is a simple matter to 165 modify the DIT in such a way that all certificate information is 166 removed from the entries and placed in the container directly beneath 167 the entries according to the definitions of this specification, it is 168 less simple to simultaneously modify all of the applications that 169 depend on certificates being stored in the entry. Thus, it may be 170 desirable to duplicate the certificate information, by having it 171 appear in the entry, as well as in the container beneath the entry 172 for a short period of time, in order to allow for migration of the 173 applications to the new LDAP schema. As in any situation in which 174 information is duplicated, great care must be taken in order to 175 ensure the integrity of the information. 177 There are several advantages in using the x509certificate object 178 class. No special matching rules are needed to retrieve a specific 179 certificate. Any field in the certificate can be used in the search 180 filter. Even information that doesn't appear in the certificate can 181 be used in a search filter. It is easier to remove certificates from 182 the DIT, since the entire certificate BER/DER encoding does not have 183 to be supplied in the modify operation. Searches that don't need 184 extensible matching rules and Values Return Filter Control will 185 perform faster. 187 Another advantage of the solution proposed here is that it will not 188 be necessary to modify existing server implementations to support 189 this schema. The extended matching rules proposed in [pkix-ldap- 190 schema] would require substantial changes in the servers' indexing 191 mechanisms. In contrast, servers implementing the x509certificate 192 schema can easily levarage their indexing support for standard LDAPv3 193 syntaxes. 195 A CIP based indexing system for a wide scale distributed certificate 196 repository will only be possible by using the solution proposed here. 198 3. Comparision with component matching approach 200 [componentmatch] defines a new mechanism for matching in complex 201 syntaxes, by defining generic matching rules that can match any user 202 selected component parts in an attribute value of any arbitrarily 203 complex attribute syntax. We believe that this might be the proper 204 way to solve search problems in the longer term, but that it will 205 take a long time untill such ASN.1 based mechanisms will be 206 implemented in LDAP servers and clients. Even if this has happened 207 the mechanism proposed here, will still be usefull in the frame of 208 CIP. A simple and easy to implement mechanism is needed today and 209 this is what this memo wants to provide. 211 4. The x509certificate object class and its attribute types 213 The description of all attributes with relevance to fields of an 214 X.509 certificate include a respective reference to [X.509-2000] and 215 to [RFC3280]. 217 4.1 Attributes for mandatory fields of an X.509 certificate 219 4.1.1 X.509 version 221 X.509 Version of the encoded certificate (See X.509(2000) 7, 222 RFC3280 4.1.2.1.) or of the CRL. 224 ( 1.3.6.1.4.1.10126.1.5.3.1 225 NAME 'x509version' 226 DESC 'X.509 Version of the certificate, or of the CRL' 227 EQUALITY integerMatch 228 ORDERING integerOrderingMatch 229 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 230 SINGLE-VALUE ) 232 Values of this attribute may either be 0, 1, or 2 correspoding to 233 X.509 v1, v2 or v3. 235 4.1.2 Serial number 237 The serial number is an integer assigned by the CA to each 238 certificate. It is unique for each certificate issued by a given CA 239 (i.e., the issuer name and serial number uniquely identify a 240 certificate). See X.509(2000) 7, RFC3280 4.1.2.2 242 ( 1.3.6.1.4.1.10126.1.5.3.2 243 NAME 'x509serialNumber' 244 DESC 'Unique integer for each cerfiticate issued by a 245 particular CA' 246 EQUALITY integerMatch 247 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 249 4.1.3 Signature algorithm 251 OID identifying the algorithm used by the CA in signing the 252 certificate (See X.509(2000) 7, RFC3280 4.1.2.3) or the CRL. 254 ( 1.3.6.1.4.1.10126.1.5.3.3 255 NAME 'x509signatureAlgorithm' 256 DESC 'OID of the algorithm used by the CA in signing 257 the CRL or the certificate' 258 EQUALITY objectIdentifierMatch 259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 260 SINGLE-VALUE ) 262 4.1.4 Issuer 264 String representation of the issuer's distinguished name. 265 See X.509(2000) 7, RFC3280 4.1.2.4 267 ( 1.3.6.1.4.1.10126.1.5.3.4 268 NAME 'x509issuer' 269 DESC 'Distinguished name of the entity who has signed and 270 issued the certificate or CRL' 271 EQUALITY distinguishedNameMatch 272 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 273 SINGLE-VALUE ) 275 Values of this attribute type must be encoded according to the syntax 276 given in [RFC2253]. 278 4.1.5 Validity 280 The "validity" attribute in an X.509 certificate (see X.509(2000) 7, 281 RFC3280 4.1.2.5) consists of an ASN.1 sequence of two 282 timestamps which define the begin and end of the certificate's 283 validity period. This sequence has been split up into two separate 284 attributes "x509validityNotBefore" and "x509validityNotAfter". 285 The times are represented in string form as defined in [RFC2252]. 287 ( 1.3.6.1.4.1.10126.1.5.3.5 288 NAME 'x509validityNotBefore' 289 DESC 'Date on which the certificate validity period begins' 290 EQUALITY generalizedTimeMatch 291 ORDERING generalizedTimeOrderingMatch 292 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 293 SINGLE-VALUE ) 295 ( 1.3.6.1.4.1.10126.1.5.3.6 296 NAME 'x509validityNotAfter' 297 DESC 'Date on which the certificate validity period ends, 298 X.509(2000) 7, RFC3280 4.1.2.5' 299 EQUALITY generalizedTimeMatch 301 ORDERING generalizedTimeOrderingMatch 302 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 303 SINGLE-VALUE ) 305 Note that the field in the certificate may be in UTC or GeneralizedTime format. If in UTC format, the creator of this attribute MUST convert the UTC time into GeneralisedTime format when creating the attribute value. 307 4.1.6 Subject 309 String representation of the subject's distinguished name. 311 ( 1.3.6.1.4.1.10126.1.5.3.7 312 NAME 'x509subject' 313 DESC 'Distinguished name of the entity associated with this 314 public-key, X.509(2000) 7, RFC3280 4.1.2.6' 315 EQUALITY distinguishedNameMatch 316 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 317 SINGLE-VALUE ) 319 Values of this attribute type must be encoded according to the syntax 320 given in [RFC2253]. 322 4.1.7 Subject public key info algorithm 324 OID of the algorithm of which the certified public key is an instance 325 of. 327 ( 1.3.6.1.4.1.10126.1.5.3.8 328 NAME 'x509subjectPublicKeyInfoAlgorithm' 329 DESC 'OID of the algorithm which this public key is an 330 instance of, X.509(2000) 7, RFC3280 4.1.2.7' 331 EQUALITY objectIdentifierMatch 332 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 333 SINGLE-VALUE ) 335 4.2 Attributes for selected extensions 337 As this specification intends to only facilitate applications in 338 finding certificates, only those extensions have to be defined that 339 might be searched for. Thus extensions described in [RFC3280] like 340 the following are not dealt with here: 342 o private key usage period extension 344 o policy mappings extension 346 o subject directory attributes extension 348 o pathLenConstraint of basic constraints extension 350 o name constraints extensions 352 o policy constraints extensions 354 o inhibit any policy extension 356 o freshest CRL extension 357 o authority information access extension 359 o subject information access extension 361 4.2.1 Authority key identifier extension 363 This attribute identifies the public key to be used to verify the 364 signature on this certificate or CRL. The key may be identified by 365 an explicit key identifier in the keyIdentifier component, by 366 identification of a certificate for the key (giving certificate 367 issuer in the authorityCertIssuer component and certificate serial 368 number in the authorityCertSerialNumber component), or by both 369 explicit key identifier and identification of a certificate for the 370 key. 372 4.2.1.1 Authority key identifier 374 ( 1.3.6.1.4.1.10126.1.5.3.11 375 NAME 'x509authorityKeyIdentifier' 376 DESC 'keyIdentifier field of the authorityKeyIdentifier 377 extension, X.509(2000) 8.2.2.1, RFC3280 4.2.1.1' 378 EQUALITY octetStringMatch 379 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 380 SINGLE-VALUE ) 382 4.2.1.2 Authority cert issuer 384 ( 1.3.6.1.4.1.10126.1.5.3.12 385 NAME 'x509authorityCertIssuer' 386 DESC 'authorityCertIssuer field of the authorityKeyIdentifier 387 extension, X.509(2000) 8.2.2.1, RFC3280 4.2.1.1' 388 EQUALITY distinguishedNameMatch 389 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 390 SINGLE-VALUE ) 392 In this specification, only the "Name" choice, encoded according to 393 [RFC2253], of the "GeneralName" type may be used. 395 4.2.1.3 Authority cert serial number 397 ( 1.3.6.1.4.1.10126.1.5.3.13 398 NAME 'x509authorityCertSerialNumber' 399 DESC 'authorityCertSerialNumber field of the 400 authorityKeyIdentifier extension, X.509(2000) 8.2.2.1, 401 RFC3280 4.2.1.1' 402 EQUALITY integerMatch 403 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 404 SINGLE-VALUE ) 406 4.2.2 Subject key identifier extension 408 This attribute identifies the public key being certified. It enables 409 distinct keys used by the same subject to be differentiated. 411 ( 1.3.6.1.4.1.10126.1.5.3.14 412 NAME 'x509subjectKeyIdentifier' 413 DESC 'Key identifier which must be unique with respect to all 414 key identifiers for the subject, X.509(2000) 8.2.2.2, 415 RFC3280 4.2.1.2' 416 EQUALITY octetStringMatch 417 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 418 SINGLE-VALUE ) 420 4.2.3 Key usage extension 422 This attribute defines the purpose (e.g., encipherment, signature, 423 certificate signing) of the key contained in the certificate. 425 ( 1.3.6.1.4.1.10126.1.5.3.15 426 NAME 'x509keyUsage' 427 DESC 'Purpose for which the certified public key is used, 428 X.509(2000) 8.2.2.3, RFC3280 4.2.1.3' 429 EQUALITY caseIgnoreMatch 430 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 432 Values of this type are encoded according to the following BNF, so 433 that each value corresponds to the respective bit in the ASN.1 434 "KeyUsage" bitstring: 436 x509keyUsage-value ="digitalSignature" / "nonRepudiation" / 437 "keyEncipherment" / "dataEncipherment" / "keyAgreement" / 438 "keyCertSign" / "cRLSign" / "encipherOnly" / "decipherOnly" 440 4.2.4 Policy information identifier extension 442 This attribute contains OIDs which indicate the policy under which 443 the certificate has been issued and the purposes for which the 444 certificate may be used. 446 ( 1.3.6.1.4.1.10126.1.5.3.16 447 NAME 'x509policyInformationIdentifier' 448 DESC 'OID which indicates the policy under which the 449 certificate has been issued and the purposes for which 450 the certificate may be used, X.509(2000) 8.2.2.6, RFC3280 451 4.2.1.5' 452 EQUALITY objectIdentifierMatch 453 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 454 SINGLE-VALUE ) 456 4.2.5 Subject alternative name extension 458 The subject alternative name extension allows additional identities 459 to be bound to the subject of the certificate. Separate attribute 460 types are defined for all c hoices of the ASN.1 type "GeneralName" 461 except for "otherName", "x400Address" and "ediPartyName". 463 4.2.5.1 Subject RFC822 name 465 ( 1.3.6.1.4.1.10126.1.5.3.17 466 NAME 'x509subjectAltNameRfc822Name' 467 DESC 'Internet electronic mail address, X.509(2000) 8.3.2.1, 468 RFC3280 4.2.1.7' 469 EQUALITY caseIgnoreMatch 470 SUBSTR caseIgnoreSubstringsMatch 471 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 473 Values of this attribute must be encoded according to the syntax 474 given in [RFC0822]. 476 4.2.5.2 Subject DNS name 478 ( 1.3.6.1.4.1.10126.1.5.3.18 479 NAME 'x509subjectDnsName' 480 DESC 'Internet domain name, X.509(2000) 8.3.2.1, RFC3280 481 4.2.1.7' 482 EQUALITY caseIgnoreMatch 483 SUBSTR caseIgnoreSubstringsMatch 484 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 486 Values of this attribute must be encoded as Internet domain names in 487 accordance with [RFC1035]. 489 4.2.5.3 Subject directory name 491 ( 1.3.6.1.4.1.10126.1.5.3.19 492 NAME 'x509subjectDirectoryName' 493 DESC 'Distinguished name, X.509(2000) 8.3.2.1, RFC3280 494 4.2.1.7' 495 EQUALITY distinguishedNameMatch 496 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 498 Values of this attribute type must be encoded according to the syntax 499 given in [RFC2253]. 501 4.2.5.4 Subject Uniform Resource Identifier 503 ( 1.3.6.1.4.1.10126.1.5.3.20 504 NAME 'x509subjectUniformResourceIdentifier' 505 DESC 'Uniform Resource Identifier for the World-Wide Web, 506 X.509(2000) 8.3.2.1, RFC3280 4.2.1.7' 507 EQUALITY caseExactMatch 508 SUBSTR caseExactSubstringsMatch 509 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 511 Values of this attribute must be encoded according to the syntax 512 given in [RFC2396]. 514 4.2.5.5 Subject IP address 516 ( 1.3.6.1.4.1.10126.1.5.3.21 517 NAME 'x509subjectIpAddress' 518 DESC 'Internet Protocol address, X.509(2000) 8.3.2.1, RFC3280 519 4.2.1.7' 520 EQUALITY caseIgnoreMatch 521 SUBSTR caseIgnoreSubstringsMatch 522 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 524 Values of this attribute type must be stored in the syntax given in 525 Appendix B of [RFC2373]. 527 4.2.5.6 Subject registered ID 529 ( 1.3.6.1.4.1.10126.1.5.3.22 530 NAME 'x509subjectRegisteredID' 531 DESC 'OID of any registered object, X.509(2000) 8.3.2.1, 532 RFC3280 4.2.1.7' 533 EQUALITY objectIdentifierMatch 534 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 536 registeredID is an identifier of any registered object assigned in 537 accordance with ITU-T Rec. X.660. 539 4.2.6 Issuer alternative name extension 541 The issuer alternative names extension allows additional identities 542 to be bound to the issuer of the certificate or CRL. Separate attribute 543 types are defined for all choices of the ASN.1 type "GeneralName" 544 except for "otherName", "x400Address" and "ediPartyName". 546 4.2.6.1 Issuer RFC 822 name 548 ( 1.3.6.1.4.1.10126.1.5.3.23 549 NAME 'x509issuerRfc822Name' 550 DESC 'Internet electronic mail address, X.509(2000) 8.3.2.2, 551 RFC3280 4.2.1.8' 552 EQUALITY caseIgnoreMatch 553 SUBSTR caseIgnoreSubstringsMatch 554 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 556 Values of this attribute must be encoded according to the syntax 557 given in [RFC0822]. 559 4.2.6.2 Issuer DNS name 561 ( 1.3.6.1.4.1.10126.1.5.3.24 562 NAME 'x509issuerDnsName' 563 DESC 'Internet domain name, X.509(2000) 8.3.2.2, RFC3280 564 4.2.1.8' 565 EQUALITY caseIgnoreMatch 566 SUBSTR caseIgnoreSubstringsMatch 567 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 569 Values of this attribute must be encoded as Internet domain names in 570 accordance with [RFC1035]. 572 4.2.6.3 Issuer directory name 574 ( 1.3.6.1.4.1.10126.1.5.3.25 575 NAME 'x509issuerDirectoryName' 576 DESC 'Distinguished name, X.509(2000) 8.3.2.2, RFC3280 577 4.2.1.8' 578 EQUALITY distinguishedNameMatch 579 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 581 Values of this attribute type must be encoded according to the syntax 582 given in [RFC2253]. 584 4.2.6.4 Issuer Uniform Resource Identifier 586 ( 1.3.6.1.4.1.10126.1.5.3.26 587 NAME 'x509issuerUniformResourceIdentifier' 588 DESC 'Uniform Resource Identifier for the World-Wide Web, 589 X.509(2000) 8.3.2.2, RFC3280 4.2.1.8' 590 EQUALITY caseExactMatch 591 SUBSTR caseExactSubstringsMatch 592 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 594 Values of this attribute must be encoded according to the syntax 595 given in [RFC2396]. 597 4.2.6.5 Issuer IP address 599 ( 1.3.6.1.4.1.10126.1.5.3.27 600 NAME 'x509issuerIpAddress' 601 DESC 'Internet Protocol address, X.509(2000) 8.3.2.2, RFC3280 602 4.2.1.8' 603 EQUALITY caseIgnoreMatch 604 SUBSTR caseIgnoreSubstringsMatch 605 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 607 Values of this attribute type must be stored in the syntax given in 608 Appendix B of [RFC2373]. 610 4.2.6.6 Issuer registered ID 612 ( 1.3.6.1.4.1.10126.1.5.3.28 613 NAME 'x509issuerRegisteredID' 614 DESC 'OID of any registered object, X.509(2000) 8.3.2.2, 615 RFC3280 4.2.1.8' 616 EQUALITY objectIdentifierMatch 617 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 619 registeredID is an identifier of any registered object assigned in 620 accordance with ITU-T Rec. X.660. 622 4.2.7 Extended key usage extension 624 This attribute indicates one or more purposes for which the certified 625 public key may be used, in addition to or in place of the basic 626 purposes indicated in the "x509keyUsage" attribute. These purposes 627 are identified by their OID. 629 ( 1.3.6.1.4.1.10126.1.5.3.30 630 NAME 'x509extKeyUsage' 631 DESC 'Purposes for which the certified public key may be used 632 (identified by OID), X.509(2000) 8.2.2.4, RFC3280 633 4.2.1.13' 634 EQUALITY objectIdentifierMatch 635 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 637 4.2.8 CRL distribution points extension 639 This attribute identifies how CRL information for this certifacte can 640 be obtained. 642 ( 1.3.6.1.4.1.10126.1.5.3.31 643 NAME 'x509cRLDistributionPointURI' 644 DESC 'DistributionPointName of type URI, X.509(2000) 8.6.2.1, 645 RFC3280 4.2.1.14' 646 EQUALITY caseExactMatch 647 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 649 In this specification, only the "uniformResourceIdentifier" choice of 650 "distributionPoint.fullName" field is supported. If this attribute 651 exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be 652 absent from the certificate, i.e. the CRL distributed by the 653 distribution point contains revocations for all revocation reasons 654 and the CRL issuer is identical to the certificate issuer. 656 Values of this attribute must be encoded according to the URI syntax 657 given in [RFC2396]. 659 4.3 Additional attributes 661 4.3.1 Certificate location 663 This attribute contains a pointer to the directory entry of 664 a certificate. Thus it is possible to point to the certificate from 665 an, e.g., white pages entry. 667 (1.3.6.1.4.1.10126.1.5.4.74 668 NAME 'x509certLocation' 669 DESC 'Pointer to a x509certificate Entry' 670 EQUALITY distinguishedNameMatch 671 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 673 4.3.2 Certificate holder 675 This attribute contains a pointer to the directory entry of the end 676 entity to which this certificate was issued. Thus it is possible to 677 link a certificate entry in a certificate repository to, e.g., a 678 white pages entry of the subject. 680 ( 1.3.6.1.4.1.10126.1.5.4.75 681 NAME 'x509certHolder' 682 DESC 'Pointer to the directory entry of the end entity to which this 683 certificate was issued' 684 EQUALITY distinguishedNameMatch 685 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 687 4.3.3 Email addresses 689 The "mail" (0.9.2342.19200300.100.1.3) attribute from [RFC2798] is 690 used to store the subject's email address. This attribute MUST be 691 populated with the values from a subject alternative name extension 692 of type rfc822Name if such an extension is present. Legacy 693 applications conforming to [RFC2312] include an "EmailAddress" 694 (1.2.840.113549.1.9.1) attribute in the subject's distinguished name. 695 If the subject alternative name extension is absent from the 696 certificate, this value MUST be used to populate the "mail" 697 attribute. 699 4.3.4. X.509 User Certificate 700 This attribute is used to store the complete certificate. Since it has to be 701 single valued the multi valued attribute userCertificate [pkix-ldap-schema] 702 cannot be used. 704 ( 1.3.6.1.4.1.10126.1.5.4.76 705 NAME 'x509userCert' 706 DESC 'the complete x.509 user certificate' 707 EQUALITY certificateExactMatch 708 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 709 SINGLE-VALUE ) 711 4.3.4. X.509 CA Certificate 712 This attribute is used to store the complete ca certificate. Since it has 713 to be single valued the multi valued attribute caCertificate 714 [pkix-ldap-schema] cannot be used. 716 ( 1.3.6.1.4.1.10126.1.5.4.77 717 NAME 'x509caCert' 718 DESC 'the complete x.509 CA certificate' 719 EQUALITY certificateExactMatch 720 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 721 SINGLE-VALUE ) 723 4.4 x509PKC object class 725 This abstract object class contains the fields of an X.509 726 user certificate or CA certificate that are used in searches 727 as attributes. It is derived from the abstract objectclass x.509base as 728 specified in [ldap-crl-schema] and is base for the two following object 729 classes. 731 ( 1.3.6.1.4.1.10126.1.5.4.2.3 732 NAME 'x509PKC' 733 ABSTRACT 734 SUP x509base 735 MUST ( x509serialNumber $ x509validityNotBefore $ 736 x509validityNotAfter $ x509subjectPublicKeyInfoAlgorithm ) 737 MAY ( mail $ x509authorityKeyIdentifier $ 738 x509authorityCertIssuer $ x509authorityCertSerialNumber $ 739 x509subjectKeyIdentifier $ x509keyUsage $ 740 x509policyInformationIdentifier $ 741 x509subjectRfc822Name $ x509subjectDnsName $ 742 x509subjectDirectoryName $ x509subjectURI $ 743 x509subjectIpAddress $ 744 x509subjectRegisteredID $ 745 x509isssuerRfc822Name $ x509isssuerDnsName $ 746 x509isssuerDirectoryName $ x509isssuerURI $ 747 x509isssuerIpAddress $ 748 x509isssuerRegisteredID $ 749 x509extKeyUsage $ 750 x509cRLDistributionPoint $ x509certHolder) ) 752 4.4.1. X.509 user Certificate object class 754 This object class is for storing user certificates. 756 ( 1.3.6.1.4.1.10126.1.5.4.2.4 757 NAME 'x509userCertificate' 758 SUP x509PKC 759 MUST x509userCert 760 MAY x509subject ) 762 4.4.2. X.509 CA Certificate object class 764 This object class is for storing CA certificates. 766 ( 1.3.6.1.4.1.10126.1.5.4.2.5 767 NAME 'x509caCertificate' 768 SUP x509PKC 769 MUST ( x509caCert $ x509subject ) ) 771 4.5 x509certificateHolder object class 773 This auxiliary object class has an attribute that contains a pointer 774 on an entry with x509certicate objectclass. Thus it is possible to 775 link, e.g., an entry of a white pages directory to an entry in a 776 certificate store. 778 ( 1.3.6.1.4.1.10126.1.5.4.2.2 779 NAME 'x509certificateHolder' 780 AUXILIARY 781 MAY ( x509certificateLocation ) ) 783 5. DIT Structure and Naming 785 If the schema presented in this document is used to store certificate 786 information in a directory that contains entries for organizations, 787 persons, services, etc., each certificate belonging to an entity 788 SHOULD be stored as a direct subordinate to the entity's entry. In 789 this case, these entries MUST be named by a multi-valued RDN formed 790 by the certificate issuer and serial number, as this is the only way 791 to enforce unique RDN under the siblings. This is expressed in the 792 following name form: 794 --------------------------------------------------------------------- 796 ( 1.3.6.1.4.1.10126.1.5.5.3 797 NAME "x509PKCNameForm" 798 OC x509PKC 799 MUST ( x509serialNumber $ x509issuer ) ) 801 certificate name form 803 --------------------------------------------------------------------- 805 There are some LDAP implementations that don't support multi-valued RDNs 806 These can use following alternative Name Form: 808 ( 1.3.6.1.4.1.10126.1.5.5.4 809 NAME "x509PKCAltNameForm" 810 OC x509PKC 811 MUST x509issuerSerial ) 813 The attribute dewscription of x509issuerSerial can be found in [ldap-ac-schema]. 815 For public directories of CAs that, besides the data stored in the 816 certificates, do not hold any additional data about end entities the 817 folloing DIT structure might be preferable. Entries for certificates 818 are stored directly below the issuing CA's entry. In this case these 819 entries SHOULD be named by the certificate serial number. This is 820 expressed in the following name form: 822 --------------------------------------------------------------------- 824 ( 1.3.6.1.4.1.10126.1.5.5.5 825 NAME "x509PKCserialNumberNameForm" 826 OC x509PKC 827 MUST x509serialNumber ) 829 certificate serial number name form 831 --------------------------------------------------------------------- 833 Care must be taken when encoding DNs that contain an x509issuer 834 attribute. Such a value is a string representation according to 835 [RFC2253]. These strings contain RFC2253 special characters and must 836 therefore be escaped. For example, the issuer name in a certificate 837 may be: 839 x509issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\2c Inc. - 840 For authorized use only,OU=Class 1 Public Primary Certification Au 841 thority - G2,O=VeriSign\2c Inc.,C=US 843 When used in a DN, this will be appear as: 845 dn: x509serialNumber=123456+x509issuer=OU\3dVeriSign Trust Network 846 \2cOU\3d(c) 1998 VeriSign\5c\2c Inc. - For authorized use only\2cOU\3d 847 Class 1 Public Primary Certification Authority - G2\2cO\3dVeriSig 848 n\5c\2c Inc.\2cC\3dUS,cn=Joe Example,... 850 6. Security Considerations 852 Attributes of directory entries are used to provide descriptive 853 information about the real-world objects they represent which can be 854 people, organizations, or devices. Most countries have privacy laws 855 regarding the publication of information about people. 857 Without additional mechanisms such as Operation Signatures [RFC2649] 858 which allow a client to verify the origin and integrity of the data 859 contained in the attributes defined in this document, a client MUST 860 NOT treat this data as authentic. Clients MUST only use - after 861 proper validation - the data which they obtained directly from the 862 certificate. Directory administrators MAY deploy ACLs which limit 863 access to the attributes defined in this document to search filters. 865 Transfer of cleartext passwords is strongly discouraged where the 866 underlying transport service cannot guarantee confidentiality and may 867 result in disclosure of the password to unauthorized parties. 869 In order to protect the directory and its contents, strong 870 authentication MUST have been used to identify the Client when an 871 update operation is requested. 873 7. Acknowledgements 875 This document borrows from a number of IETF documents, including 876 [certinfo-schema]. 878 The authors wish to thank Michael Str�der and David Chadwick for 879 their significant contributions to this document. 881 This work is part of the DFN Project "Ausbau und Weiterbetrieb eines 882 Directory Kompetenzzentrums" funded by the German Ministry of 883 Research (BMBF). 885 This document has been written in XML according to the DTD specified 886 in RFC2629. xml2rfc has been used to generate an RFC2033 compliant 887 plain text form. The XML source and a HTML version are available on 888 request. 890 References 892 [RFC0822] Crocker, D., "Standard for the format of ARPA 893 Internet text messages", STD 11, RFC 822, August 894 1982. 896 [RFC1035] Mockapetris, P., "Domain names - implementation 897 and specification", STD 13, RFC 1035, November 898 1987. 900 [RFC2119] Bradner, S., "Key words for use in RFCs to 901 Indicate Requirement Levels", BCP 14, RFC 2119, 902 March 1997. 904 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for 905 Syntax Specifications: ABNF", RFC 2234, November 906 1997. 908 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 909 "Lightweight Directory Access Protocol (v3): 910 Attribute Syntax Definitions", RFC 2252, December 911 1997. 913 [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight 914 Directory Access Protocol (v3): UTF-8 String 915 Representation of Distinguished Names", RFC 2253, 916 December 1997. 918 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema 919 for use with LDAPv3", RFC 2256, December 1997. 921 [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B. and J. 922 Weinstein, "S/MIME Version 2 Certificate 923 Handling", RFC 2312, March 1998. 925 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 926 Addressing Architecture", RFC 2373, July 1998. 928 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, 929 "Uniform Resource Identifiers (URI): Generic 930 Syntax", RFC 2396, August 1998. 932 [RFC2649] Greenblatt, B. and P. Richard, "An LDAP Control 933 and Schema for Holding Operation Signatures", RFC 934 2649, August 1999. 936 [RFC2651] Allen, J. and M. Mealling, "The Architecture of 937 the Common Indexing Protocol (CIP)", RFC 2651, 938 August 1999. 940 [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP 941 Object Class", RFC 2798, April 2000. 943 [RFC3280] Housley, R., Polk, T., Ford, W. and D. Solo, 944 "Internet X.509 Public Key Infrastructure 945 Certificate and CRL Profile", RFC 3280, April 946 2002. 948 [RFC3377] Hodges, J. and RL. Morgan, "Lightweight Directory 949 Access Protocol (v3): Technical Specification", 950 RFC 3377, September 2002. 952 [X.509-2000] ITU, "Information Technology - Open Systems 953 Interconnection - The Directory: Public-key and 954 attribute certificate frameworks", ITU-T 955 Recommendation X.509, March 2000. 957 [certinfo-schema] Greenblatt, B., "LDAP Object Class for Holding 958 Certificate Information", Internet Draft (work in 959 progress), Februar 2000, . 963 [componentmatch] Legg, S., "LDAP & X.500 Component Matching 964 Rules", Internet Draft (work in progress), 965 October 2002, . 968 [matchedval] Chadwick, D. and S. Mullan, "Returning Matched 969 Values with LDAPv3", Internet Draft (work in 970 progress), June 2002, . 973 [pkix-ldap-schema] Chadwick, D. and S. Legg, "Internet X.509 Public 974 Key Infrastructure - LDAP Schema and Syntaxes for 975 PKIs", Internet Draft (work in progress), June 976 2002, . 978 [ldap-ac-schema] Chadwick, D. W. and M. V. Sahalayev, "Internet X.509 979 Public Key Infrastructure - LDAP Schema for X.509 980 Attribute Certificates, Internet Draft (work in 981 progress), February 2003, . 984 [ldap-crl-schema] Chadwick, D. W. and M. V. Sahalayev, "Internet X.509 985 Public Key Infrastructure - LDAP Schema for X.509 986 CRLs, Internet Draft (work in progress), February 2003, 987 . 989 Authors' Addresses 991 Peter Gietz 992 DAASI International GmbH 993 Wilhelmstr. 106 994 Tuebingen 72074 995 DE 997 Phone: +49 7071 29 70336 998 EMail: peter.gietz@daasi.de 999 URI: http://www.daasi.de/ 1001 Norbert Klasen 1002 Avinci 1003 Halskestr. 38 1004 Ratingen 40880 1005 DE 1007 EMail: norbert.klasen@daasi.de 1009 Appendix A. Sample directory entries 1011 A sample x509certificate directory entry for an intermediate CA 1012 certificate in LDIF format: 1014 dn: x509serialNumber=4903272,EMAILADDRESS=certify@pca.dfn.de,CN=DFN T 1015 oplevel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsc 1016 hes Forschungsnetz,C=DE 1017 objectclass: x509certificate 1018 x509version: 2 1019 x509serialNumber: 4903272 1020 x509issuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Toplevel Certifica 1021 tion Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsnet 1022 z,C=DE 1023 x509validityNotBefore: 20020110170112Z 1024 x509validityNotAfter: 20060110170112Z 1025 x509subject: EMAILADDRESS=ca@daasi.de,OU=DAASI CA,O=DAASI Internation 1026 al GmbH,C=DE 1027 x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 1028 x509basicConstraintsCa: TRUE 1029 x509keyUsage: keyCertSign 1030 x509keyUsage: cRLSign 1031 x509subjectKeyIdentifier:: 5nrZFpVK4RKfIglqQ4N4JXBS4Bk= 1032 x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509 1033 /g1/data/crls/root-ca-crl.crx 1034 x509cLRdistributionPointURI: http://www.dfn-pca.de/certification/x509 1035 /g1/data/crls/root-ca-crl.crl 1036 x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1 1037 mail: ca@daasi.de 1038 objectClass: pkiCa 1039 caCertificate:: MIIHTTCCBjWgAwIBAgIDStFoMA0GCSqGSIb3DQEBBQUAMI 1040 GsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MR 1041 YwFAYD VQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDE 1042 yRERk4gVG9 wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0B 1043 CQEWEmNlcnRpZnlAcGNhLmRmbi5kZTAeFw0wMjAxMTAxNzAxMTJaFw0wNjAxMTAxNzAx 1044 MTJaMF8xCzAJBgNVBAYTAkRFMSEwHwYDVQQKExhEQUFTSSBJbnRlcm5hdGlvbmFsIEdt 1045 YkgxETAPBgNVBAsTCERB QVNJIENBMRowGAYJKoZIhvcNAQkBFgtjYUBkYWFzaS5kZTC 1046 CASIwDQYJKoZIhvcNAQEBBQA DggEPADCCAQoCggEBAKmQBp+Gr28/qlEWjnJoiH3Awm 1047 hNEYMRWgXMXMMjM3S4mSmXZ8FZfTSPhi5O1zx5nyHecfl01fAO79Kpc6XkOTOl4iKBwu 1048 7+DM6my9Iizp2puhOQ6iuuchAIyJQPR0lfWAvvW+4n7Nf13Js5qFHvXBDqvgt6fud1l8 1049 XZ4nPWBSbs6OnB4EUDlRLx5fdCX2sEPQINKeu0INMtjHI6eGbspmahup0ArPA9RYZVjV 1050 q6ZHkh4205/JAhji9KtFifKCztXNTRMba7AHd2uS6GbF9+chGLPWGNZKtMhad1SvU7Zl 1051 w/ySHkFbBFZMu6x3kAVgwW8gKQa5qSFnMw/WTKATJRPekCAwEAAaOCA8IwggO+MA8GA1 1052 UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBTmetkWlUrhEp8iCWpDg3 1053 glcFLgGTCB2wYDVR0jBIHTMIHQgBQGC/q1+Eh4oyCxCz7PoNDE0X990KGBsqSBrzCBrD 1054 ELMAkGA1UEBhMCREUxITAfBgNVBAoTGERldXRzY2hlcyBGb3JzY2h1bmdzbmV0ejEWMB 1055 QGA1UECxMNREZOLUNFUlQgR21iSDEQMA4GA1UECxMHREZOLVBDQTEtMCsGA1UEAxMkRE 1056 ZOIFRvcGxldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFh 1057 JjZXJ0aWZ5QHBjYS5kZm4uZGWCAxXP/TCBpQYDVR0fBIGdMIGaMEugSaBHhkVodHRwOi 1058 8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NTA5L2cxL2RhdGEvY3Jscy9yb2 1059 90LWNhLWNybC5jcngwS6BJoEeGRWh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aWZpY2 1060 F0aW9uL3g1MDkvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDARBglghkgBhvhCAQ 1061 EEBAMCAQYwSwYJYIZIAYb4QgEIBD4WPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZXJ0aW 1062 ZpY2F0aW9uL3BvbGljaWVzL3g1MDlwb2xpY3kuaHRtbDCB+QYJYIZIAYb4QgENBIHrFo 1063 HoVGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGJ5IHRoZSBERk4tUENBLCB0aGUgVG 1064 9wCkxldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IG9mIHRoZSBHZXJtYW4gUmVzZW 1065 FyY2gKTmV0d29yayAoRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6LCBERk4pLgpUaGUga2 1066 V5IG93bmVyJ3MgaWRlbnRpdHkgd2FzIGF1dGhlbnRpY2F0ZWQgaW4KYWNjb3JkYW5jZS 1067 B3aXRoIHRoZSBERk4tUENBIHg1MDkgUG9saWN5LjA3BglghkgBhvhCAQMEKhYoaHR0cH 1068 M6Ly93d3cuZGZuLXBjYS5kZS9jZ2kvY2hlY2stcmV2LmNnaTBkBgNVHSAEXTBbMFkGCy 1069 sGAQQB2RqCLAEBMEowSAYIKwYBBQUHAgEWPGh0dHA6Ly93d3cuZGZuLXBjYS5kZS9jZX 1070 J0aWZpY2F0aW9uL3BvbGljaWVzL3g1MDlwb2xpY3kuaHRtbDANBgkqhkiG9w0BAQUFAA 1071 OCAQEAU9GmwCW6LwsyHfC241afldqj/GULv8mfSkUEpK2OtYU1JAYFzmQx69iweOKHbg 1072 XZKZA2Wox+9AydIe98MJCSCOFKYjkzgXU4fEZbEgnZBo+/1+W2BoB6gFAWy77KVHgimA 1073 7AqCcfbObeyCmyfLg1ro8/KpE01OjNr0S+EfZ3gX9sezjVkCy12HBNQknz/hT2af25UU 1074 hyFTcvUY4xvlKAQpla29qyO28sfO93Qhkum6SU2XPlsKU+3lyqF33Xy84Y2z8ScVlsMu 1075 VWbUGtmVshnpT5K91n42pu/f0rLtkZDssEDbcLnQDLWEz1aUDkLC++4CeFJxC/Dd/SOr 1076 E0yR0hNQ= 1078 A sample x509certificate directory entry for an end identity 1079 certificate in LDIF format: 1081 dn: x509serialNumber=1581631808272310054353257112721713,EMAILADDRESS= 1082 certificate@trustcenter.de,OU=TC TrustCenter Class 1 CA,O=TC TrustCe 1083 nter for Security in Data Networks GmbH,L=Hamburg,ST=Hamburg,C=DE 1084 objectclass: x509certificate 1085 x509version: 2 1086 x509serialNumber: 1581631808272310054353257112721713 1087 x509issuer: EMAILADDRESS=certificate@trustcenter.de,OU=TC TrustCente 1088 r Class 1 CA,O=TC TrustCenter for Security in Data Networks GmbH,L= 1089 Hamburg, ST=Hamburg,C=DE 1090 x509validityNotBefore: 20011030180757Z 1091 x509validityNotAfter: 20021030180757Z 1092 x509subject: EMAILADDRESS=norbert.klasen@daasi.de,CN=Norbert Klasen,C 1093 =DE 1094 x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 1095 mail: norbert.klasen@daasi.de 1096 objectClass: pkiUser 1097 userCertificate:: MIIDOTCCAqKgAwIBAgIOTfsAAAACxOstmlOu2TEwDQYJ 1098 KoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYD 1099 VQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkg 1100 aW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFz 1101 cyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAe 1102 Fw0wMTEwMzAxODA3NTdaFw0wMjEwMzAxODA3NTdaME4xCzAJBgNVBAYTAkRFMRcwFQYD 1103 VQQDEw5Ob3JiZXJ0IEtsYXNlbjEmMCQGCSqGSIb3DQEJARYXbm9yYmVydC5rbGFzZW5A 1104 ZGFhc2kuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL8+XK98p4YjD7Wq7Apm 1105 hAN/j2tfVsFCS0ufy12vGpEtG4ny1tbbBORCJI8vIlDr2/vVTESl6UjzceloVUCib5V8 1106 55mKUVmLL9Ay4qQLFd4wAoRSPAu9DkfbR+ygjzaYq+MUKMwaB61sG6911xk/e2/IIq8/ 1107 IHKrRoYQGmHkaaJpAgMBAAGjgaowgacwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cu 1108 dHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZI 1109 AYb4QgEDBFAWTmh0dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2st 1110 cmV2LmNnaS80REZCMDAwMDAwMDJDNEVCMkQ5QTUzQUVEOTMxPzANBgkqhkiG9w0BAQQF 1111 AAOBgQCrAzuZzLztupeqcHa8OUOcnRuTacMpBEeICbZMKv6mN9rMYkAxFKerj/yXbdCE 1112 8/3X3L00eGj+a8A7PumATiJSfmvYqa4EMZwHC2FFqPxYyAj+xVuSlL5AC4HGHu4SOCp/ 1113 UJu1xysoD16chOOLpj7+ZWZWLHIjA3zeXwUGl4kFvw== 1115 Appendix B. Sample searches 1117 This section details how clients should access the certstore. The 1118 searches are presented in LDAP URL format. 1120 Retrieve all certificates for an end entity from a certstore using 1121 the first DIT structure: 1123 ldap:///CN=Norbert%20Klasen,O=DAASI%20International%20GmbH,C=de? 1124 userCertificate?one?(objectClass=x509certificate) 1126 Find a certificate in a trustcenter's certstore suitable for sending 1127 an encrypted S/MIME message to "norbert.klasen@daasi.de" 1129 ldap:///O=TC%20TrustCenter%20for%20Security%20in%20Data%20Networks 1130 %20GmbH,L=Hamburg,ST=Hamburg,C=de?userCertificate?sub? 1131 (&(objectClass=x509certificate)(mail=norbert.klasen@daasi.de) 1132 (|(x509keyUsage=keyEncipherment)(x509keyUsage=keyAgreement) 1133 (x509extendedKeyUsage=1.3.6.1.5.5.7.3.4))) 1135 Find a CA certificate by its "subjectKeyIdentifier" obtained from the 1136 "keyIdentifier" field of the "autorityKeyIdentifier" extension in an 1137 end entity certificate: 1139 ldap:///?caCertificate?sub? 1140 (&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6 1141 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43% 1142 5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) 1144 Appendix C. Changes from previous Drafts 1146 C.1 Changes in Draft 01 1148 o Included new Attributes x509authorityKeyIdentifier, 1149 x509authorityCertissuer, x509authorityCertSerialNumber, 1150 x509certificateLocation, x509certificateHolder, and new 1151 objectclass x509certificateHolder 1153 o Fixed bug in definition of objectclass x509certificate 1155 o Changed references from RFC 2459 to RFC 3280 and included some 1156 respective language in 3.2. 1158 o Changed references from RFC 2251 to RFC 3377 and deleted all 1159 references to LDAPv2. 1161 o Deleted ";binary" in examples 1163 o Included new section: Comparision with component matching approach 1165 o Some changes in wording and section titles, and elimination of 1166 typos 1168 o Changed order of authors, and one author's address 1170 C.1 Changes in Draft 01 1172 o abstract object class x509PKC 1174 o aligned to [ldap-ac-schema] and [ldap-crl-schema] 1176 Full Copyright Statement 1178 Copyright (C) The Internet Society (2002). All Rights Reserved. 1180 This document and translations of it may be copied and furnished to 1181 others, and derivative works that comment on or otherwise explain it 1182 or assist in its implementation may be prepared, copied, published 1183 and distributed, in whole or in part, without restriction of any 1184 kind, provided that the above copyright notice and this paragraph are 1185 included on all such copies and derivative works. However, this 1186 document itself may not be modified in any way, such as by removing 1187 the copyright notice or references to the Internet Society or other 1188 Internet organizations, except as needed for the purpose of 1189 developing Internet standards in which case the procedures for 1190 copyrights defined in the Internet Standards process must be 1191 followed, or as required to translate it into languages other than 1192 English. 1194 The limited permissions granted above are perpetual and will not be 1195 revoked by the Internet Society or its successors or assigns. 1197 This document and the information contained herein is provided on an 1198 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1199 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1200 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1201 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1202 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1204 Acknowledgement 1206 Funding for the RFC Editor function is currently provided by the 1207 Internet Society.