idnits 2.17.1 draft-ietf-pkix-ldap-pkc-schema-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1381. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1397), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 23) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 19 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 == Line 284 has weird spacing: '...ificate x509...' -- 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 (October 25, 2004) is 7116 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 1034, but no explicit reference was found in the text == Unused Reference: 'RFC2798' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC2312' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'RFC3687' is defined on line 1096, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PRIVATE' ** 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) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** 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) -- Obsolete informational reference (is this intentional?): RFC 2829 (Obsoleted by RFC 4510, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 3039 (Obsoleted by RFC 3739) Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 10 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: April 25, 2005 N. Klasen 5 Avinci - The Know-How Company 6 October 25, 2004 8 Internet X.509 Public Key Infrastructure Lightweight Directory Access 9 Protocol Schema for X.509 Certificates 10 draft-ietf-pkix-ldap-pkc-schema-01 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document describes a Lightweight Directory Access Protocol 44 schema which can be used to implement a certificate store for X.509 45 certificates. Specifically, two structural object classes for X.509 46 user and CA certificates are defined. Key fields of a certificate 47 are stored in LDAP attributes so that applications can easily 48 retrieve the certificates needed by using basic LDAP search filters. 49 Multiple certificates for a single entity can be stored and 50 retrieved. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 The following syntax specifications use the augmented Backus-Naur 59 Form (ABNF) as described in [RFC2234]. 61 Schema definitions are provided using LDAPv3 description formats 62 [RFC2252]. Definitions provided here are formatted (line wrapped) 63 for readability. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Comparison with Values Return Filter Control . . . . . . . . . 5 69 3. Comparison with Component Matching approach . . . . . . . . . 6 70 4. X.509 certificate object classes . . . . . . . . . . . . . . . 7 71 4.1 X.509 base object class . . . . . . . . . . . . . . . . . 7 72 4.2 X.509 PKC object class . . . . . . . . . . . . . . . . . . 7 73 4.3 X.509 user certificate object class . . . . . . . . . . . 8 74 4.4 X.509 CA certificate object class . . . . . . . . . . . . 8 75 4.5 X.509 PKC extensions auxiliary object class . . . . . . . 9 76 4.6 X.509 certificate holder object class . . . . . . . . . . 9 77 5. The attribute types of the X.509 certificate object classes . 9 78 5.1 Attributes for mandatory fields of an X.509 certificate . 10 79 5.1.1 X.509 version . . . . . . . . . . . . . . . . . . . . 10 80 5.1.2 Serial number . . . . . . . . . . . . . . . . . . . . 10 81 5.1.3 Signature algorithm . . . . . . . . . . . . . . . . . 10 82 5.1.4 Issuer . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.1.5 Validity . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.1.6 Subject . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.1.7 Subject public key info algorithm . . . . . . . . . . 12 86 5.2 Attributes for selected extensions . . . . . . . . . . . . 12 87 5.2.1 Authority key identifier extension . . . . . . . . . . 13 88 5.2.2 Subject key identifier extension . . . . . . . . . . . 14 89 5.2.3 Key usage extension . . . . . . . . . . . . . . . . . 14 90 5.2.4 Policy information identifier extension . . . . . . . 14 91 5.2.5 Subject alternative name extension . . . . . . . . . . 15 92 5.2.6 Issuer alternative name extension . . . . . . . . . . 16 93 5.2.7 Basic constraints extension . . . . . . . . . . . . . 18 94 5.2.8 Extended key usage extension . . . . . . . . . . . . . 19 95 5.2.9 CRL distribution points extension . . . . . . . . . . 19 96 5.3 Additional attributes . . . . . . . . . . . . . . . . . . 20 97 5.3.1 Certificate location . . . . . . . . . . . . . . . . . 20 98 5.3.2 Certificate holder . . . . . . . . . . . . . . . . . . 20 99 6. DIT structure and naming . . . . . . . . . . . . . . . . . . . 20 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 23 105 10.2 Non-normative references . . . . . . . . . . . . . . . . . . 24 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 107 A. Sample directory entries . . . . . . . . . . . . . . . . . . . 25 108 B. Sample searches . . . . . . . . . . . . . . . . . . . . . . . 28 109 C. Changes from previous Drafts . . . . . . . . . . . . . . . . . 29 110 C.1 Changes in draft-klasen-ldap-x509certificate-schema-01 . . 29 111 C.2 Changes in draft-klasen-ldap-x509certificate-schema-02 . . 29 112 C.3 Changes in draft-klasen-ldap-x509certificate-schema-03 . . 29 113 C.4 Changes in draft-ietf-pkix-ldap-pkc-schema-00 . . . . . . 30 114 C.5 Changes in draft-ietf-pkix-ldap-pkc-schema-01 . . . . . . 31 115 Intellectual Property and Copyright Statements . . . . . . . . 32 117 1. Introduction 119 A key component in the wide-spread adoption of a Public Key 120 Infrastructure is the general availability of public keys and their 121 certificates. Today, certificates are often published in an X.500 122 compliant directory service. These directories are accessed by 123 applications using the LDAP v3 [RFC3377] protocol. An LDAPv3 schema 124 for PKI repository objects is specified in [pkix-ldap-schema], where 125 a set of object classes, attribute types, syntaxes, and extended 126 matching rules are defined. For storing certificates, the 127 "userCertificate" and "cACertificate" attribute types are used. All 128 certificates of an entity are stored as values in these multi-valued 129 attributes. This solution has a serious drawback. In LDAP, the 130 smallest granularity of data access is the attribute. The directory 131 server will therefore always return the full list of certificates of 132 an entry to clients dealing with certificates. If the number of 133 certificates for an entity is large this will result in considerable 134 overhead and burden to the client. 136 This document proposes to solve this problem by the use of the 137 structural object classes x509userCertificate and x509caCertificate 138 for storing certificates. Each certificate will be stored in a 139 separate entry in the directory. Having each certificate stored in a 140 separate entry provides flexibility in structuring the Directory 141 Information Tree. The certificate entries can be stored either below 142 a person entry or below a CA entry as a certificate only repository, 143 as shown in figure 1. 145 1.) below Person entry: 147 person 148 / | \ 149 / | \ 150 cert1 cert2 cert3 152 2.) below CA cert repository: 154 CA 155 | 156 | 157 certificate repository 158 / | \ 159 / | \ 160 cert1 cert2 ... cert1008 162 Figure 1: examples of possible DIT-structures 163 Fields of certificates which are needed to identify a certificate and 164 those which are often used in searching for an appropriate 165 certificate, are extracted from the certificate and stored as 166 attributes of the entry. Applications can thus search for specific 167 certificates with simple LDAP filters. This approach could be named 168 a "metadata" approach, since data (attributes) about data 169 (certificate) are stored. 171 The use of simple attributes also makes a large scale widely 172 distributed certificate repository service possible by using an 173 indexing service based on The Common Indexing Protocol (CIP) 174 [RFC2651], which defines a protocol between index servers for 175 exchanging index objects in order to facilitate query routing. The 176 Tagged Index Object format as specified in [RFC2654] was specified to 177 carry directory server information, by collecting the single 178 attribute types and values. By using the schema proposed in this 179 document, index objects can include certificate information in 180 attributes. 182 If certificates are stored redundantly in person entries and in 183 certificate entries below the person entries, maintainers of 184 repositories MUST make sure that the same certificates are stored in 185 the person entry and the respective certificate entries and keep this 186 consistency. Alternatively, they MUST leave out any certificates in 187 the person entry. 189 This document is part of a set following this metadata approach 190 comprising: 191 1. the LDAP schema for X.509 public key certificates (this document) 192 2. the LDAP schema for X.509 attribute certificates [ldap-ac-schema] 193 3. the LDAP schema for X.509 CRLs [ldap-crl-schema] 195 Future documents may be written that use the same method for 196 Qualified certificates as described in [RFC3039] or any other 197 evolving pkix certificate standard. An auxiliary object class for 198 including additional metadata that is not included in the certificate 199 is outside the scope of this document. 201 Two alternative approaches are discussed in the next two sections. 203 2. Comparison with Values Return Filter Control 205 In [matchedval] a control has been defined that allows for only a 206 subset of values of a specified attribute to be returned from a 207 matching entry, by defining a filter for the returned values. In 208 this section, this approach is compared with the one proposed in this 209 document. 211 The major benefit of the Values Return Filter Control is that it does 212 not require any changes to the DIT. 214 While it is a simple matter to modify the DIT in such a way that all 215 certificate information is removed from the entries and placed in the 216 container directly beneath the entries according to the definitions 217 of this specification, it is less simple to simultaneously modify all 218 of the applications that depend on certificates being stored in the 219 entry. Thus, it may be desirable to duplicate the certificate 220 information, by having it appear in the entry, as well as in the 221 container beneath the entry for a short period of time, in order to 222 allow for migration of the applications to the new LDAP schema. As 223 in any situation in which information is duplicated, great care must 224 be taken in order to ensure the integrity and consistency of the 225 information. 227 There are several advantages in using the x509certificate object 228 class. No special matching rules are needed to retrieve a specific 229 certificate. Any field in the certificate can be used in the search 230 filter. Even information that doesn't appear in the certificate can 231 be used in a search filter. It is easier to remove certificates from 232 the DIT, since the entire certificate BER/DER encoding does not have 233 to be supplied in the modify operation. Searches that don't need 234 extensible matching rules and Values Return Filter Control will 235 perform faster. 237 Another advantage of the solution proposed here is that it will not 238 be necessary to modify existing server implementations to support 239 this schema. The extended matching rules proposed in 240 [pkix-ldap-schema] would require substantial changes in the servers' 241 indexing mechanisms. In contrast, servers implementing the 242 x509certificate schema can easily leverage their indexing support for 243 standard LDAPv3 syntaxes. 245 A CIP-based indexing system for a wide scale distributed certificate 246 repository will rather be possible by using the solution proposed 247 here due to its dependency on attribute values. 249 3. Comparison with Component Matching approach 251 [RFC3687]Component matching defines a mechanism for matching against 252 complex syntaxes, by defining generic matching rules that can match 253 against any user selected component parts in an attribute value of 254 any arbitrarily complex attribute syntax. This might prove to be the 255 proper way to solve LDAP search problems in the longer term, but it 256 will take a long time until such ASN.1 based mechanisms are 257 implemented in all LDAP servers and clients. Even when this has 258 happened the mechanism proposed in this document will still be useful 259 to some applications such as CIP. 261 A simple and easy to implement mechanism is needed today to search 262 for X.509 attributes. 264 4. X.509 certificate object classes 266 The object classes have been designed to form a logical set and be 267 extensible in an orderly way as new PKC/CRL/AC extensions are 268 defined. The methodology is as follows. Every X.509 entry (for a 269 PKC, CRL or AC) is of the x509base abstract object class. There is 270 then an additional abstract object class for each, derived from 271 x509base, which holds the attributes extracted from the basic PKC/AC/ 272 CRL ASN.1 structure (excluding all extensions). The PKC object class 273 is then instantiated by two structural object classes for user 274 certificates and for CA certificates. The extensions are added by an 275 additional auxiliary object class. 277 Thus the inheritance chains for PKCs are: 279 x509base top 280 | | 281 x509PKC x509PKCext 282 / \ 283 / \ 284 x509caCertificate x509userCertificate 286 4.1 X.509 base object class 288 The x509base object class is the abstract object class that is the 289 superior of all of the x.509 entry object classes 291 ( 1.3.6.1.4.1.10126.1.5.4.2.1 292 NAME 'x509base' 293 ABSTRACT 294 MAY x509version ) 296 4.2 X.509 PKC object class 298 This abstract object class contains the fields of an X.509 user 299 certificate or CA certificate that are used in searches as attributes 300 and in name forms. It is derived from the abstract object class 301 x.509base as specified in [ldap-crl-schema] and is base for the two 302 following object classes. 304 ( 1.3.6.1.4.1.10126.1.5.4.2.3 305 NAME 'x509PKC' 306 SUP x509base 307 ABSTRACT 308 MUST ( x509serialNumber $ x509signatureAlgorithm $ x509issuer $ 309 x509validityNotBefore $ x509validityNotAfter $ 310 x509subjectPublicKeyInfoAlgorithm ) 311 MAY ( x509certHolder $ x509issuerSerial ) ) 313 The attribute description of x509issuerSerial can be found in 314 [ldap-ac-schema] 316 4.3 X.509 user certificate object class 318 This object class is for storing user certificates. 320 ( 1.3.6.1.4.1.10126.1.5.4.2.4 321 NAME 'x509userCertificate' 322 SUP x509PKC 323 STRUCTURAL 324 MUST userCertificate 325 MAY x509subject ) 327 The attribute description of userCertificate can be found in 328 [pkix-ldap-schema]. Although this attribute type is specified as 329 multi-valued it MUST NOT contain more than one certificate if used 330 with this object class. 332 The attribute type x509subject is specified here as a MAY attribute. 333 Nevertheless if this attribute is not used at least one of the 334 following attributes MUST be filled in: x509subjectRfc822Name, 335 x509subjectDnsName, x509subjectDirectoryName, x509subjectURI, 336 x509subjectIpAddress, or x509subjectRegisteredID. 338 4.4 X.509 CA certificate object class 340 This object class is for storing CA certificates. 342 ( 1.3.6.1.4.1.10126.1.5.4.2.5 343 NAME 'x509caCertificate' 344 SUP x509PKC 345 STRUCTURAL 346 MUST ( caCertificate $ x509subject ) ) 348 The attribute description of caCertificate can be found in 349 [pkix-ldap-schema]. Although this attribute type is specified as 350 multi-valued it MUST NOT contain more than one certificate if used 351 with this object class. 353 4.5 X.509 PKC extensions auxiliary object class 355 The x509PKCext auxiliary object class is used to hold the attributes 356 extracted from the PKC extensions defined in [X.509-2000] and 357 profiled in [RFC3280]. 359 Note. If a PKC holds additional extensions to these, then another 360 auxiliary object class and supporting attributes will need to be 361 defined. 363 ( 1.3.6.1.4.1.10126.1.5.4.2.6 364 NAME 'x509PKCext' 365 SUP top 366 AUXILIARY 367 MAY ( x509authorityKeyIdentifier $ 368 x509authorityCertIssuer $ 369 x509authorityCertSerialNumber $ 370 x509subjectKeyIdentifier $ x509keyUsage $ 371 x509policyInformationIdentifier $ 372 x509subjectRfc822Name $ x509subjectDnsName $ 373 x509subjectDirectoryName $ x509subjectURI $ 374 x509subjectIpAddress $ x509subjectRegisteredID $ 375 x509issuerRfc822Name $ x509issuerDnsName $ 376 x509issuerDirectoryName $ x509issuerURI $ 377 x509issuerIpAddress $ x509issuerRegisteredID $ 378 x509basicConstraintsCa $ x509basicConstraintsPathLen $ 379 x509extKeyUsage $ x509fullCRLDistributionPointURI ) ) 381 4.6 X.509 certificate holder object class 383 This auxiliary object class has an attribute that contains a pointer 384 to an entry with x509certicate objectclass. Thus it is possible to 385 link, e.g., an entry of a white pages directory to an entry in a 386 certificate store. Such a link points to the opposite direction of 387 the link stored in the attribute type x509certHolder. 389 ( 1.3.6.1.4.1.10126.1.5.4.2.2 390 NAME 'x509certificateHolder' 391 AUXILIARY 392 MAY ( x509certLocation ) ) 394 5. The attribute types of the X.509 certificate object classes 396 The description of all attributes with relevance to fields and 397 extensions of an X.509 certificate include a respective reference to 398 [X.509-2000] and to [RFC3280]. 400 5.1 Attributes for mandatory fields of an X.509 certificate 402 5.1.1 X.509 version 404 X.509 Version of the encoded certificate (See X.509(2000) 7, RFC3280 405 4.1.2.1.) or of the CRL. 407 ( 1.3.6.1.4.1.10126.1.5.3.1 408 NAME 'x509version' 409 DESC 'X.509 Version of the certificate, or of the CRL' 410 EQUALITY integerMatch 411 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 412 SINGLE-VALUE ) 414 Values of this attribute may either be 0, 1, 2 or 3 corresponding to 415 X.509 v1, v2, v3, or v4. 417 5.1.2 Serial number 419 The serial number is an integer assigned by the CA to each 420 certificate. It is unique for each certificate issued by a given CA 421 (i.e., the issuer name and serial number uniquely identify a 422 certificate). See X.509(2000) 7, RFC3280 4.1.2.2 424 ( 1.3.6.1.4.1.10126.1.5.3.2 425 NAME 'x509serialNumber' 426 DESC 'Unique integer for each certificate issued by a 427 particular CA' 428 EQUALITY integerMatch 429 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 431 5.1.3 Signature algorithm 433 OID identifying the algorithm used by the CA in signing the 434 certificate (see X.509(2000) 7, RFC3280 4.1.2.3) or the CRL. 436 ( 1.3.6.1.4.1.10126.1.5.3.3 437 NAME 'x509signatureAlgorithm' 438 DESC 'OID of the algorithm used by the CA in 439 signing the CRL or the certificate' 440 EQUALITY objectIdentifierMatch 441 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 442 SINGLE-VALUE ) 444 5.1.4 Issuer 446 String representation of the certificate or CRL issuer's 447 distinguished name (see X.509(2000) 7, RFC3280 4.1.2.4) 449 ( 1.3.6.1.4.1.10126.1.5.3.4 450 NAME 'x509issuer' 451 DESC 'Distinguished name of the entity who has signed and 452 issued the certificate' 453 EQUALITY distinguishedNameMatch 454 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 455 SINGLE-VALUE ) 457 Values of this attribute type must be encoded according to the syntax 458 given in [RFC2253]. 460 5.1.5 Validity 462 The "validity" attribute in an X.509 certificate (see X.509(2000) 7, 463 RFC3280 4.1.2.5) consists of an ASN.1 sequence of two timestamps 464 which define the begin and end of the certificate's validity period. 465 This sequence has been split up into two separate attributes 466 "x509validityNotBefore" and "x509validityNotAfter". The times are 467 represented in string form as defined in [RFC2252]. 469 ( 1.3.6.1.4.1.10126.1.5.3.5 470 NAME 'x509validityNotBefore' 471 DESC 'Date on which the certificate validity period begins' 472 EQUALITY generalizedTimeMatch 473 ORDERING generalizedTimeOrderingMatch 474 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 475 SINGLE-VALUE ) 477 ( 1.3.6.1.4.1.10126.1.5.3.6 478 NAME 'x509validityNotAfter' 479 DESC 'Date on which the certificate validity period ends' 480 EQUALITY generalizedTimeMatch 481 ORDERING generalizedTimeOrderingMatch 482 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 483 SINGLE-VALUE ) 485 Note that the field in the certificate may be in UTC or 486 GeneralizedTime format. If in UTC format, it MUST be converted into 487 GeneralisedTime format when creating the attribute value. 489 5.1.6 Subject 491 String representation of the subject's distinguished name (see 492 X.509(2000) 7, RFC3280 4.1.2.6). 494 ( 1.3.6.1.4.1.10126.1.5.3.7 495 NAME 'x509subject' 496 DESC 'Distinguished name of the entity associated with this 497 public-key' 498 EQUALITY distinguishedNameMatch 499 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 500 SINGLE-VALUE ) 502 Values of this attribute type must be encoded according to the syntax 503 given in [RFC2253]. 505 5.1.7 Subject public key info algorithm 507 OID identifying the algorithm associated with the certified public 508 key (see X.509(2000) 7, RFC3280 4.1.2.7). 510 ( 1.3.6.1.4.1.10126.1.5.3.8 511 NAME 'x509subjectPublicKeyInfoAlgorithm' 512 DESC 'OID identifying the algorithm associated with the 513 certified public key' 514 EQUALITY objectIdentifierMatch 515 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 516 SINGLE-VALUE ) 518 5.2 Attributes for selected extensions 520 As this specification intends to facilitate applications in finding 521 certificates, only those extensions have to be defined that might be 522 searched for. Thus extensions described in [RFC3280] like the 523 following are not dealt with here: 524 o private key usage period extension 525 o policy mappings extension 526 o subject directory attributes extension 527 o basic constraints extension 528 o name constraints extensions 529 o policy constraints extensions 530 o inhibit any policy extension 531 o freshest CRL extension 532 o authority information access extension 533 o subject information access extension 535 5.2.1 Authority key identifier extension 537 This attribute identifies the public key to be used to verify the 538 signature on this certificate or CRL (see X.509(2000) 8.2.2.1, 539 RFC3280 4.2.1.1). The key may be identified by an explicit key 540 identifier in the keyIdentifier component, by identification of a 541 certificate for the key (giving certificate issuer in the 542 authorityCertIssuer component and certificate serial number in the 543 authorityCertSerialNumber component), or by both explicit key 544 identifier and identification of a certificate for the key. 546 5.2.1.1 Authority key identifier 548 ( 1.3.6.1.4.1.10126.1.5.3.11 549 NAME 'x509authorityKeyIdentifier' 550 DESC 'Key Identifier field of the Authority Key 551 Identifier extension' 552 EQUALITY octetStringMatch 553 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 554 SINGLE-VALUE ) 556 5.2.1.2 Authority cert issuer 558 ( 1.3.6.1.4.1.10126.1.5.3.12 559 NAME 'x509authorityCertIssuer' 560 DESC 'Authority Cert Issuer field of the Authority Key 561 Identifier extension' 562 EQUALITY distinguishedNameMatch 563 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 564 SINGLE-VALUE ) 566 In this specification, only the "Name" choice, encoded according to 567 [RFC2253], of the "GeneralName" type may be used. 569 5.2.1.3 Authority cert serial number 571 ( 1.3.6.1.4.1.10126.1.5.3.13 572 NAME 'x509authorityCertSerialNumber' 573 DESC 'Authority Cert Serial Number field of the 574 Authority Key Identifier extension' 575 EQUALITY integerMatch 576 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 577 SINGLE-VALUE ) 579 5.2.2 Subject key identifier extension 581 This attribute identifies the public key being certified (see 582 X.509(2000) 8.2.2.2, RFC3280 4.2.1.2). It enables distinct keys used 583 by the same subject to be differentiated. 585 ( 1.3.6.1.4.1.10126.1.5.3.14 586 NAME 'x509subjectKeyIdentifier' 587 DESC 'Key identifier which must be unique with respect to all 588 key identifiers for the subject' 589 EQUALITY octetStringMatch 590 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 591 SINGLE-VALUE ) 593 5.2.3 Key usage extension 595 This attribute defines the purpose (e.g., encipherment, signature, 596 certificate signing) of the key contained in the certificate (see 597 X.509(2000) 8.2.2.3, RFC3280 4.2.1.3). 599 ( 1.3.6.1.4.1.10126.1.5.3.15 600 NAME 'x509keyUsage' 601 DESC 'Purpose for which the certified public key is used' 602 EQUALITY caseIgnoreIA5Match 603 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 605 Values of this type are encoded according to the following BNF, so 606 that each value corresponds to the respective bit in the ASN.1 607 "KeyUsage" bitstring: 609 x509keyUsage-value ="digitalSignature" / "nonRepudiation" / 610 "keyEncipherment" / "dataEncipherment" / "keyAgreement" / 611 "keyCertSign" / "cRLSign" / "encipherOnly" / "decipherOnly" 613 5.2.4 Policy information identifier extension 615 This attribute contains OIDs which indicate the policy under which 616 the certificate has been issued and the purposes for which the 617 certificate may be used (see X.509(2000) 8.2.2.6, RFC3280 4.2.1.5). 619 ( 1.3.6.1.4.1.10126.1.5.3.16 620 NAME 'x509policyInformationIdentifier' 621 DESC 'OID which indicates the policy under which the 622 certificate has been issued and the purposes for which 623 the certificate may be used' 624 EQUALITY objectIdentifierMatch 625 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 627 5.2.5 Subject alternative name extension 629 The subject alternative name extension allows additional identities 630 to be bound to the subject of the certificate (see X.509(2000) 631 8.3.2.1, RFC3280 4.2.1.7). Separate attribute types are defined for 632 all choices of the ASN.1 type "GeneralName" except for "otherName", 633 "x400Address" and "ediPartyName". 635 5.2.5.1 Subject RFC822 name 637 ( 1.3.6.1.4.1.10126.1.5.3.17 638 NAME 'x509subjectRfc822Name' 639 DESC 'Internet electronic mail address of the entity 640 associated with this public-key' 641 EQUALITY caseIgnoreIA5Match 642 SUBSTR caseIgnoreIA5SubstringsMatch 643 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 645 Values of this attribute must be encoded according to the syntax 646 given in [RFC0822]. 648 5.2.5.2 Subject DNS name 650 ( 1.3.6.1.4.1.10126.1.5.3.18 651 NAME 'x509subjectDnsName' 652 DESC 'Internet domain name of the entity 653 associated with this public-key' 654 EQUALITY caseIgnoreIA5Match 655 SUBSTR caseIgnoreIA5SubstringsMatch 656 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 658 Values of this attribute must be encoded as Internet domain names in 659 accordance with [RFC1035]. 661 5.2.5.3 Subject directory name 663 ( 1.3.6.1.4.1.10126.1.5.3.19 664 NAME 'x509subjectDirectoryName' 665 DESC 'Distinguished name of the entity 666 associated with this public-key' 667 EQUALITY distinguishedNameMatch 668 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 670 Values of this attribute type must be encoded according to the syntax 671 given in [RFC2253]. 673 5.2.5.4 Subject Uniform Resource Identifier 675 ( 1.3.6.1.4.1.10126.1.5.3.20 676 NAME 'x509subjectURI' 677 DESC 'Uniform Resource Identifier for the World-Wide Web 678 of the entity associated with this public-key' 679 EQUALITY caseExactIA5Match 680 SUBSTR caseExactIA5SubstringsMatch 681 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 683 Values of this attribute must be encoded according to the syntax 684 given in [RFC2396]. 686 5.2.5.5 Subject IP address 688 ( 1.3.6.1.4.1.10126.1.5.3.21 689 NAME 'x509subjectIpAddress' 690 DESC 'Internet Protocol address of the entity 691 associated with this public-key' 692 EQUALITY caseIgnoreIA5Match 693 SUBSTR caseIgnoreIA5SubstringsMatch 694 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 696 Values of this attribute type must be stored in the syntax given for 697 IPv4address or IPv6address in Appendix B of [RFC2373]. 699 5.2.5.6 Subject registered ID 701 ( 1.3.6.1.4.1.10126.1.5.3.22 702 NAME 'x509subjectRegisteredID' 703 DESC 'OID of any registered object identifying the entity 704 associated with this public-key' 705 EQUALITY objectIdentifierMatch 706 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 708 registeredID is an identifier of any registered object assigned in 709 accordance with ITU-T Rec. X.660. 711 5.2.6 Issuer alternative name extension 713 The issuer alternative names extension allows additional identities 714 to be bound to the subject of the certificate or CRL (see X.509(2000) 715 8.3.2.2, RFC3280 4.2.1.8). Separate attribute types are defined for 716 all choices of the ASN.1 type "GeneralName" except for "otherName", 717 "x400Address" and "ediPartyName". 719 5.2.6.1 Issuer RFC 822 name 721 ( 1.3.6.1.4.1.10126.1.5.3.23 722 NAME 'x509issuerRfc822Name' 723 DESC 'Internet electronic mail address of the entity who has 724 signed and issued the certificate' 725 EQUALITY caseIgnoreIA5Match 726 SUBSTR caseIgnoreIA5SubstringsMatch 727 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 729 Values of this attribute must be encoded according to the syntax 730 given in [RFC0822]. 732 5.2.6.2 Issuer DNS name 734 ( 1.3.6.1.4.1.10126.1.5.3.24 735 NAME 'x509issuerDnsName' 736 DESC 'Internet domain name of the entity who has 737 signed and issued the certificate' 738 EQUALITY caseIgnoreIA5Match 739 SUBSTR caseIgnoreIA5SubstringsMatch 740 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 742 Values of this attribute must be encoded as Internet domain names in 743 accordance with [RFC1035]. 745 5.2.6.3 Issuer directory name 747 ( 1.3.6.1.4.1.10126.1.5.3.25 748 NAME 'x509issuerDirectoryName' 749 DESC 'Distinguished name of the entity who has 750 signed and issued the certificate' 751 EQUALITY distinguishedNameMatch 752 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 754 Values of this attribute type must be encoded according to the syntax 755 given in [RFC2253]. 757 5.2.6.4 Issuer Uniform Resource Identifier 759 ( 1.3.6.1.4.1.10126.1.5.3.26 760 NAME 'x509issuerURI' 761 DESC 'Uniform Resource Identifier for the World-Wide Web 762 of the entity who has signed and issued the certificate' 763 EQUALITY caseExactIA5Match 764 SUBSTR caseExactIA5SubstringsMatch 765 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 767 Values of this attribute must be encoded according to the syntax 768 given in [RFC2396]. 770 5.2.6.5 Issuer IP address 772 ( 1.3.6.1.4.1.10126.1.5.3.27 773 NAME 'x509issuerIpAddress' 774 DESC 'Internet Protocol address of the entity who has 775 signed and issued the certificate' 776 EQUALITY caseIgnoreIA5Match 777 SUBSTR caseIgnoreIA5SubstringsMatch 778 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 780 Values of this attribute type must be stored in the syntax given in 781 Appendix B of [RFC2373]. 783 5.2.6.6 Issuer registered ID 785 ( 1.3.6.1.4.1.10126.1.5.3.28 786 NAME 'x509issuerRegisteredID' 787 DESC 'OID of any registered object identifying the entity who 788 has signed and issued the certificate' 789 EQUALITY objectIdentifierMatch 790 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 792 registeredID is an identifier of any registered object assigned in 793 accordance with ITU-T Rec. X.660. 795 5.2.7 Basic constraints extension 797 The basic constraints extension (see X.509(2000) 8.4.2.1, RFC3280 798 4.2.1.10) identifies whether the subject of the certificate is a CA 799 and the maximum depth of valid certification paths that include this 800 certificate. This can be stored in the following two LDAP 801 attributes: 803 The attribute x509basicConstraintsCa indicates whether the subject of 804 the certificate is a CA. If the value of this attribute is "TRUE", 805 the certificate MUST be stored in the "caCertificate" attribute. 807 ( 1.3.6.1.4.1.10126.1.5.3.29 808 NAME 'x509basicConstraintsCa' 809 DESC 'Identifies whether the subject of the certificate is a 810 CA' 811 EQUALITY booleanMatch 812 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 813 SINGLE-VALUE ) 815 The attribute x509basicConstraintsPathlen contains the maximum number 816 of non-self-issued intermediate certificates that may follow this 817 certificate in a valid certification path. It is only meaningfull, 818 if x509basicConstraintsCa is set to "TRUE". 820 ( 1.3.6.1.4.1.10126.1.5.3.33 821 NAME 'x509basicConstraintsPathLen' 822 DESC 'maximum number of non-self-issued 823 intermediate certificates that may follow this 824 certificate in a valid certification path.' 825 EQUALITY integerMatch 826 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 827 SINGLE-VALUE ) 829 5.2.8 Extended key usage extension 831 This attribute indicates one or more purposes for which the certified 832 public key may be used, in addition to or in place of the basic 833 purposes indicated in the "x509keyUsage" attribute (see X.509(2000) 834 8.2.2.4, RFC3280 4.2.1.13). These purposes are identified by their 835 OID. 837 ( 1.3.6.1.4.1.10126.1.5.3.30 838 NAME 'x509extKeyUsage' 839 DESC 'Purposes for which the certified public key may be used, 840 identified by an OID' 841 EQUALITY objectIdentifierMatch 842 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 844 5.2.9 CRL distribution points extension 846 This attribute identifies how the full CRL information for this 847 certifacte can be obtained (see X.509(2000) 8.6.2.1, RFC3280 848 4.2.1.14). 850 ( 1.3.6.1.4.1.10126.1.5.3.32 851 NAME 'x509fullCRLDistributionPointURI' 852 DESC 'URI type of DistributionPointName for the full CRL' 853 EQUALITY caseExactIA5Match 854 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 856 In this specification, only the "uniformResourceIdentifier" choice of 857 "distributionPoint.fullName" field is supported. If this attribute 858 exists in an entry, both the "reasons" and "cRLIssuer" fields MUST be 859 absent from the certificate, i.e. the CRL distributed by the 860 distribution point contains revocations for all revocation reasons 861 and the CRL issuer is identical to the certificate issuer. 863 Values of this attribute must be encoded according to the URI syntax 864 given in [RFC2396]. 866 5.3 Additional attributes 868 5.3.1 Certificate location 870 This attribute contains a pointer to the directory entry of a 871 certificate. Thus it is possible to point to the certificate from 872 an, e.g., white pages entry. 874 ( 1.3.6.1.4.1.10126.1.5.4.74 875 NAME 'x509certLocation' 876 DESC 'Pointer to a x509certificate Entry' 877 EQUALITY distinguishedNameMatch 878 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 880 5.3.2 Certificate holder 882 This attribute contains a pointer to the directory entry of the end 883 entity to which this certificate was issued. Thus it is possible to 884 link a certificate entry in a certificate repository to, e.g., a 885 white pages entry of the subject. 887 ( 1.3.6.1.4.1.10126.1.5.4.75 888 NAME 'x509certHolder' 889 DESC 'Pointer to the directory entry of the end entity to which 890 this certificate was issued' 891 EQUALITY distinguishedNameMatch 892 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 894 6. DIT structure and naming 896 If the schema presented in this document is used to store certificate 897 information in a directory that contains entries for organizations, 898 persons, services, etc., each certificate belonging to an entity 899 SHOULD be stored as a direct subordinate to the entity's entry. In 900 this case, these entries SHOULD be named by a multi-valued RDN formed 901 by the certificate issuer and serial number, as this is the only way 902 to enforce unique RDN under the siblings. This is expressed in the 903 following two name forms: 905 ( 1.3.6.1.4.1.10126.1.5.5.6 906 NAME 'x509userCertificateNameform' 907 OC x509userCeriticate 908 MUST ( x509serialNumber $ x509issuer ) ) 910 ( 1.3.6.1.4.1.10126.1.5.5.7 911 NAME 'x509caCertificateNameform' 912 OC x509caCertificate 913 MUST ( x509serialNumber $ x509issuer ) ) 915 There are some LDAP implementations that don't support multi-valued 916 RDNs. These can use following alternative two name forms: 918 ( 1.3.6.1.4.1.10126.1.5.5.8 919 NAME 'x509PKCAltNameForm' 920 OC x509PKC 921 MUST x509issuerSerial ) 923 For public directories of CAs that, besides the data stored in the 924 certificates, do not hold any additional data about end entities the 925 following DIT structure might be preferable. Entries for 926 certificates are stored directly below the issuing CA's entry. In 927 this case these entries SHOULD be named by the certificate serial 928 number. This is expressed in the following two name forms: 930 ( 1.3.6.1.4.1.10126.1.5.5.10 931 NAME 'x509PKCSerialNumberNameForm' 932 OC x509PKC 933 MUST x509serialNumber ) 935 Care must be taken when encoding DNs that contain an x509issuer 936 attribute. Such a value is a string representation according to 937 [RFC2253]. These strings contain RFC2253 special characters and must 938 therefore be escaped. For example, the issuer name in a certificate 939 may be: 941 x509issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\2c Inc. - 942 For authorized use only,OU=Class 1 Public Primary Certification Au 943 thority - G2,O=VeriSign\2c Inc.,C=US 945 When used in a DN, this will be appear as: 947 dn: x509serialNumber=123456+x509issuer=OU\3dVeriSign Trust Network 948 \2cOU\3d(c) 1998 VeriSign\5c\2c Inc. - For authorized use only\2c 949 OU\3d Class 1 Public Primary Certification Authority - G2\2cO\3d 950 VeriSign\5c\2c Inc.\2cC\3dUS,cn=Joe Example,... 952 7. Security Considerations 954 Attributes of directory entries are used to provide descriptive 955 information about the real-world objects they represent which can be 956 people, organizations, or devices. Most countries have privacy laws 957 regarding the publication of information about people. 959 Without additional mechanisms such as Operation Signatures [RFC2649] 960 which allow a client to verify the origin and integrity of the data 961 contained in the attributes defined in this document, a client MUST 962 NOT treat this data as authentic. Clients MUST only use - after 963 proper validation - the data which they obtained directly from the 964 certificate. Directory administrators MAY deploy ACLs which limit 965 access to the attributes defined in this document to search filters. 967 Transfer of cleartext passwords is strongly discouraged where the 968 underlying transport service cannot guarantee confidentiality and may 969 result in disclosure of the password to unauthorized parties. 971 In order to protect the directory and its contents, secure 972 authentication MUST have been used to identify the Client when an 973 update operation is requested. 975 See [RFC2829] for additional information on how to protect sensitive 976 LDAP data. 978 8. IANA Considerations 980 This document uses the OIDs below 1.3.6.1.4.1.10126.1.5 to identify 981 the LDAP schema elements described here. This OID was assigned by 982 DAASI International, under its IANA-assigned private enterprise 983 allocation [PRIVATE], for use in this specification. 985 9. Acknowledgments 987 This document borrows from a number of IETF documents, including 988 [certinfo-schema]. 990 The authors wish to thank David Chadwick, Russ Housley, Mikhail 991 Sahalayev, Michael Stroeder, and Kurt Zeilenga for their 992 contributions to this document. 994 This work is part of the DFN Project "Ausbau und Weiterbetrieb eines 995 Directory Kompetenzzentrums" funded by the German Ministry of 996 Research (BMBF). 998 The last versions of this work were made in the frame of the project 999 "PKI/LDAP" funded by the Ministry of Science, Research and The Arts 1000 of Baden-Wuerttemberg, Germany. 1002 This document has been written in XML according to the DTD specified 1003 in RFC2629. xml2rfc has been used to generate an RFC2033 compliant 1004 plain text form. The XML source and a HTML version are available on 1005 request. 1007 10. References 1009 10.1 Normative references 1011 [PRIVATE] IANA, "Private Enterprise Numbers", 1012 . 1014 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1015 text messages", STD 11, RFC 822, August 1982. 1017 [RFC1035] Mockapetris, P., "Domain names - implementation and 1018 specification", STD 13, RFC 1035, November 1987. 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, March 1997. 1023 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1024 Specifications: ABNF", RFC 2234, November 1997. 1026 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 1027 "Lightweight Directory Access Protocol (v3): Attribute 1028 Syntax Definitions", RFC 2252, December 1997. 1030 [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 1031 Access Protocol (v3): UTF-8 String Representation of 1032 Distinguished Names", RFC 2253, December 1997. 1034 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 1035 with LDAPv3", RFC 2256, December 1997. 1037 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1038 Architecture", RFC 2373, July 1998. 1040 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1041 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1042 August 1998. 1044 [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object 1045 Class", RFC 2798, April 2000. 1047 [RFC3280] Housley, R., Polk, T., Ford, W. and D. Solo, "Internet 1048 X.509 Public Key Infrastructure Certificate and CRL 1049 Profile", RFC 3280, April 2002. 1051 [RFC3377] Hodges, J. and RL. Morgan, "Lightweight Directory Access 1052 Protocol (v3): Technical Specification", RFC 3377, 1053 September 2002. 1055 [ldap-ac-schema] 1056 Chadwick, D. and M. Sahalayev, "Internet X.509 Public Key 1057 Infrastructure - LDAP Schema for X.509 Attribute 1058 Certificates", Internet Draft (work in progress), June 1059 2004, . 1061 [ldap-crl-schema] 1062 Chadwick, D. and M. Sahalayev, "Internet X.509 Public Key 1063 Infrastructure - LDAP Schema for X.509 CRLs", Internet 1064 Draft (work in progress), June 2004, 1065 . 1067 [pkix-ldap-schema] 1068 Chadwick, D. and S. Legg, "Internet X.509 Public Key 1069 Infrastructure - LDAP Schema and Syntaxes for PKIs", 1070 Internet Draft (work in progress), June 2002, 1071 . 1073 10.2 Non-normative references 1075 [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/ 1076 MIME Version 2 Certificate Handling", RFC 2312, March 1077 1998. 1079 [RFC2649] Greenblatt, B. and P. Richard, "An LDAP Control and Schema 1080 for Holding Operation Signatures", RFC 2649, August 1999. 1082 [RFC2651] Allen, J. and M. Mealling, "The Architecture of the Common 1083 Indexing Protocol (CIP)", RFC 2651, August 1999. 1085 [RFC2654] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A 1086 Tagged Index Object for use in the Common Indexing 1087 Protocol", RFC 2654, August 1999. 1089 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and RL. Morgan, 1090 "Authentication Methods for LDAP", RFC 2829, May 2000. 1092 [RFC3039] Santesson, S., Polk, T., Barzin, P. and M. Nystrom, 1093 "Internet X.509 Public Key Infrastructure Qualified 1094 Certificate Profile", RFC 3039, January 2001. 1096 [RFC3687] Legg, S., "Lightweight Directory Access Protocol and X.500 1097 Component Matching Rules", RFC 3687, February 2004. 1099 [X.509-2000] 1100 ITU, "Information Technology - Open Systems 1101 Interconnection - The Directory: Public-key and 1102 attribute certificate frameworks", ITU-T Recommendation 1103 X.509, March 2000. 1105 [certinfo-schema] 1106 Greenblatt, B., "LDAP Object Class for Holding Certificate 1107 Information", Internet Draft (expired), Februar 2000, 1108 . 1110 [matchedval] 1111 Chadwick, D. and S. Mullan, "Returning Matched Values with 1112 LDAPv3", Internet Draft (work in progress), September 1113 2002, . 1115 Authors' Addresses 1117 Peter Gietz 1118 DAASI International GmbH 1119 Wilhelmstr. 106 1120 Tuebingen 72074 1121 DE 1123 Phone: +49 7071 29 70336 1124 EMail: peter.gietz@daasi.de 1125 URI: http://www.daasi.de/ 1127 Norbert Klasen 1128 Avinci - The Know-How Company 1129 Halskestr. 38 1130 Ratingen 40880 1131 DE 1133 EMail: norbert.klasen@avinci.de 1135 Appendix A. Sample directory entries 1137 A sample x509certificate directory entry for an intermediate CA 1138 certificate in LDIF format: 1140 dn: x509serialNumber=1429501,EMAILADDRESS=certify@pca.dfn.de,CN=DFN T 1141 oplevel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsc 1142 hes Forschungsnetz,C=DE 1143 objectclass: x509base 1144 objectclass: x509PKC 1145 objectclass: x509caCertficate 1146 objectclass: x509PKCext 1147 x509version: 2 1148 x509serialNumber: 1429501 1149 x509issuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Toplevel Certifica 1150 tion Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsnet 1151 z,C=DE 1152 x509validityNotBefore: 20011201121116Z 1153 x509validityNotAfter: 20100131121116Z 1154 x509subject: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Toplevel Certific 1155 ation Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches Forschungsne 1156 tz,C=DE 1157 x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 1158 x509signatureAlgorithm: 1.2.840.113549.1.1.5 1159 x509basicConstraintsCa: TRUE 1160 x509subjectKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA= 1161 x509authorityCertIssuer: EMAILADDRESS=certify@pca.dfn.de,CN=DFN Tople 1162 vel Certification Authority,OU=DFN-PCA,OU=DFN-CERT GmbH,O=Deutsches 1163 Forschungsnetz,C=DE 1164 x509authorityCertSerialNumber: 1429501 1165 x509authorityKeyIdentifier:: Bgv6tfhIeKMgsQs+z6DQxNF/fdA= 1166 x509keyUsage: keyCertSign 1167 x509keyUsage: cRLSign 1168 x509policyInformationIdentifier: 1.3.6.1.4.1.11418.300.1.1 1169 caCertificate;binary:: MIIG2jCCBcKgAwIBAgIDFc/9MA0GCSqGSIb3DQEBBQUAMI 1170 GsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZXR6MR 1171 YwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQQDEy 1172 RERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQ 1173 EWEmNlcnRpZnlAcGNhLmRmbi5kZTAeFw0wMTEyMDExMjExMTZaFw0xMDAxMzExMjExMT 1174 ZaMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaHVuZ3NuZX 1175 R6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS0wKwYDVQ 1176 QDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w 1177 0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQ 1178 oCggEBAMF5rhMt6zmhxK5oWPwT2FG7Up7T5DovHSD/YKPIRxsvDWmC4dTzByIBLnOmEf 1179 lk+5KAqAYao6eY1qF0hR4WiS4DjCsn7l3zNo/4i2eF4EmGEksBygb4tRlTThcO7heFX+ 1180 Du5qFoks+ONqa70RlwOr2l53KVwjMXBCtCLFSKRLVuxeh5+Smkm+FuOmwEugndM2n74D 1181 jjyf9DCOaHGZrHwVDh+Vpy5Ny4bKCSboujRxd5NxsStUshDVbTeS3B8TuzAJbywYWEE7 1182 erox+7WTfQr8ivSCBhrNJ36VRjAb8hiV9Iuy2TmJYo2oPyC8a3eM3xj9Ku2IW3tS2zpf 1183 iIzt9xvFMCAwEAAaOCAwEwggL9MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAYL+r 1184 X4SHijILELPs+g0MTRf33QMIHbBgNVHSMEgdMwgdCAFAYL+rX4SHijILELPs+g0MTRf3 1185 3QoYGypIGvMIGsMQswCQYDVQQGEwJERTEhMB8GA1UEChMYRGV1dHNjaGVzIEZvcnNjaH 1186 VuZ3NuZXR6MRYwFAYDVQQLEw1ERk4tQ0VSVCBHbWJIMRAwDgYDVQQLEwdERk4tUENBMS 1187 0wKwYDVQQDEyRERk4gVG9wbGV2ZWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBg 1188 kqhkiG9w0BCQEWEmNlcnRpZnlAcGNhLmRmbi5kZYIDFc/9MAsGA1UdDwQEAwIBBjARBg 1189 lghkgBhvhCAQEEBAMCAAcwgaUGA1UdHwSBnTCBmjBLoEmgR4ZFaHR0cDovL3d3dy5kZm 1190 4tcGNhLmRlL2NlcnRpZmljYXRpb24veDUwOS9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcm 1191 wuY3J4MEugSaBHhkVodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi94NT 1192 A5L2cxL2RhdGEvY3Jscy9yb290LWNhLWNybC5jcmwwOAYJYIZIAYb4QgEDBCsWKWh0dH 1193 BzOi8vd3d3LmRmbi1wY2EuZGUvY2dpL2NoZWNrLXJldi5jZ2k/MEsGCWCGSAGG+EIBCA 1194 Q+FjxodHRwOi8vd3d3LmRmbi1wY2EuZGUvY2VydGlmaWNhdGlvbi9wb2xpY2llcy94NT 1195 A5cG9saWN5Lmh0bWwwOAYJYIZIAYb4QgENBCsWKVRoZSBERk4gVG9wLUxldmVsIENlcn 1196 RpZmljYXRpb24gQXV0aG9yaXR5MGQGA1UdIARdMFswWQYLKwYBBAHZGoIsAQEwSjBIBg 1197 grBgEFBQcCARY8aHR0cDovL3d3dy5kZm4tcGNhLmRlL2NlcnRpZmljYXRpb24vcG9saW 1198 NpZXMveDUwOXBvbGljeS5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQAmbai6JMt7nkuavy 1199 vxKzLGn04Gyt0zKrp8zmERp4inktvY7p+vkaomYu2QYC7cHq0tlrPXQQhhetjiXGb+36 1200 aJtHDkEA0NwrJzYnHgPsvx7z0wysENP4wxf97KsSWm07RY+f6/gIQF7Je7CW30Rzq7N6 1201 R0NMBs32mJgdn3ntqlFNw3Nbs050FEjPNq54RdawlJo85x+w+QJd7uQM4yZjHpRhvwgt 1202 e9Ge1UqCUdpMsLHzeMKJ0B9GhwIIqOJCMiPgKjcUBrn6ehSX70POvXvjjE2+FzhPGTyT 1203 kS474d2UCAnL9qhPrdWXzBjOumOjhJutT1aecm9eljlshmh1cNen00 1205 A sample x509certificate directory entry for an end identity 1206 certificate in LDIF format: 1208 dn: x509serialNumber=2,ou=DAASI CA,o=DAASI International GmbH,c=DE 1209 objectClass: x509base 1210 objectClass: x509PKC 1211 objectClass: x509userCertificate 1212 objectClass: x509PKCext 1213 x509version: 2 1214 x509serialNumber: 2 1215 x509issuer: email=ca@daasi.de,ou=DAASI CA,o=DAASI International GmbH, 1216 c=DE 1217 x509validityNotBefore: 20040712095656Z 1218 x509validityNotAfter: 20050713095656Z 1219 x509subject: email=peter@daasi.de,cn=Peter Gietz,ou=People,o=DAASI In 1220 ternational GmbH,l=Tuebingen,st=Some-State,c=DE 1221 x509subjectPublicKeyInfoAlgorithm: 1.2.840.113549.1.1.1 1222 x509signatureAlgorithm: 1.2.840.113549.1.1.5 1223 x509keyUsage: digitalSignature 1224 x509keyUsage: nonRepudiation 1225 x509keyUsage: keyEncipherment 1226 x509extKeyUsage: 1.3.6.1.5.5.7.3.4 1227 x509extKeyUsage: 1.3.6.1.5.5.7.3.2 1228 userCertificate;binary:: MIIDXzCCAkegAwIBAgIBAjANBgkqhkiG9w0BAQUFADBf 1229 MQswCQYDVQQGEwJERTEhMB8GA1UEChMYREFBU0kgSW50ZXJuYXRpb25hbCBHbWJIMREw 1230 DwYDVQQLEwhEQUFTSSBDQTEaMBgGCSqGSIb3DQEJARYLY2FAZGFhc2kuZGUwHhcNMDQw 1231 NzEyMDk1NjU2WhcNMDUwNzEzMDk1NjU2WjCBnzELMAkGA1UEBhMCREUxEzARBgNVBAgT 1232 ClNvbWUtU3RhdGUxEjAQBgNVBAcTCVR1ZWJp bmdlbjEhMB8GA1UEChMYREFBU0kgSW5 1233 0ZXJuYXRpb25hbCBHbWJIMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1BldGVyIEd 1234 pZXR6MR0wGwYJKoZIhvcNAQkBFg5wZXRlckBkYWFzaS5kZTCBnzANBgkqhkiG9w0BAQE 1235 FAAOBjQAwgYkCgYEAsnuapogKMPEkVFL7WaATMJPFGkijIOgATa9uTdAzwoPS+Pxuk8y 1236 CK8amM5MfX0O7nkj9Lq36RTUm08hxRGV2gTqRiKuycxulmHU1YXayr4tWrblKwFy69JR 1237 7TiQvWnCCA83YxEkdmZMjw9qxq5IRtqFHkLmCe+1Uz1jpBvfbr2cCAwEAAaNpMGcwCwY 1238 DVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAmBglghkgBhvh 1239 CAQ0EGRYXQW5vbnltb3VzIE1haWwgKFRlc3RDQSkwEQYJYIZIAYb4QgEBBAQDAgUgMA0 1240 GCSqGSIb3DQEBBQUAA4IBAQB5FDS+GDqEjD69zXUSWNun59JWvVvq5bj7rWzhSgzcAeT 1241 FQxmErhwSSQcAiIXmARoJfNdF118Lrv9Tuqq3yus7zFUwWKCXhTY9wrtnp3M4dc0ocMP 1242 bDXE56GFuJOroTgoAOOZV4gp0em49d1wr5tDIJgiL28wzSOLiRT+j2FcfEsu0fSc4UIq 1243 msU3Jg16dOKCwtexCtz8uii7WhwYCCu7NJK0dBZ0Cas9sQwRzZg5T0+LZiRXpXKJ3Jr6 1244 5YYjS8iUzbpEDisVgEKVSLuFSNxfQICACZHtwDLOuTcQAWnf0Pps8mVZlQOoRCgd2Nr7 1245 ChMFx8esGaTFXlOwUitWkDqTa 1247 Appendix B. Sample searches 1249 This section details how clients should access the certstore. The 1250 searches are presented in LDAP URL format. 1252 Retrieve all certificates for an end entity from a certstore using 1253 the first DIT structure: 1255 ldap:///CN=Peter%20Gietz,O=DAASI%20International%20GmbH,C=de? 1256 userCertificate?one?(objectClass=x509userCertificate) 1258 Find a certificate in a trustcenter's certstore suitable for sending 1259 an encrypted S/MIME message to "peter@daasi.de" 1261 ldap:///ou=DAASI%20CA,o=DAASI%20International%20GmbH,c=DE? 1262 userCertificate?sub? 1263 (&(&(objectClass=x509userCertificate) 1264 (x509subjectRfc822Name=peter@daasi.de) 1265 (|(x509keyUsage=keyEncipherment) 1266 (x509extKeyUsage=1.3.6.1.5.5.7.3.4))) 1268 Find a CA certificate by its "subjectKeyIdentifier" obtained from the 1269 "keyIdentifier" field of the "autorityKeyIdentifier" extension in an 1270 end entity certificate: 1272 ldap:///?caCertificate?sub? 1273 (&(objectClass=x509caCertificate)(x509subjectKeyIdentifier= 1274 %5CE6%5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A 1275 %5C43%5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) 1277 Appendix C. Changes from previous Drafts 1279 C.1 Changes in draft-klasen-ldap-x509certificate-schema-01 1280 o Included new Attributes x509authorityKeyIdentifier, 1281 x509authorityCertissuer, x509authorityCertSerialNumber, 1282 x509certificateLocation, x509certificateHolder, and new 1283 objectclass x509certificateHolder 1284 o Fixed bug in definition of objectclass x509certificate 1285 o Changed references from RFC 2459 to RFC 3280 and included some 1286 respective language in 3.2. 1287 o Changed references from RFC 2251 to RFC 3377 and deleted all 1288 references to LDAPv2. 1289 o Deleted ";binary" in examples 1290 o Included new section: Comparision with component matching approach 1291 o Some changes in wording and section titles, and elimination of 1292 typos 1293 o Changed order of authors, and one author's address 1295 C.2 Changes in draft-klasen-ldap-x509certificate-schema-02 1296 o abstract object class x509PKC 1297 o aligned to [ldap-ac-schema] and [ldap-crl-schema] 1299 C.3 Changes in draft-klasen-ldap-x509certificate-schema-03 1300 o Changed Matching Rules from caseIgnoreMatch to caseIgnoreIA5Match 1301 etc. 1303 o moved the references to RFC 3280 from the DESC part of the 1304 attribute definition to the text 1305 o added some additional text about CIP in Introduction 1306 o reworded text for x509subjectPublicKeyInfoAlgorithm 1307 o changed x509userCert and x509caCert to be inherited from 1308 userCertificate and caCertificate respectively 1309 o added clarification about x509subject and subject alternative 1310 names 1311 o added attribute type x509issuerSerial to x509PKC object class 1312 o added attribute type x509basicConstraintsCa to x509PKC object 1313 class 1314 o renamed attribute type x509cRLDistributionPointURI to 1315 x509FullcRLDistributionPointURI 1316 o devided references in normative and non normative 1317 o deleted attribute type mail from x509PKC objectclass 1318 o created separate Name Forms for x509userCertificate and 1319 x509caCertificate object classes. 1320 o changed attribute type x509SerialNumber to MULTI-VALUE 1321 o adjusted examples to new schema 1322 o Fixed more typos 1324 C.4 Changes in draft-ietf-pkix-ldap-pkc-schema-00 1325 o renamed the title and file name 1326 o deleted attribute types x509userCert and x509caCert and replaced 1327 them with the standard userCertificate and caCertificate attribute 1328 types. 1329 o included the description of x509base object class assigning a new 1330 OID to it. 1331 o separated the extensions attributes from the object class x509PKC 1332 and included them into the new auxiliary object class x509PKCext 1333 o renamed x509issuerUniforResourceIdentifier and 1334 x509subjectUniforResourceIdentifier to x509issuerURI and 1335 x509subjectURI respectivly. 1336 o replaced separate Name Forms for x509userCertificate and 1337 x509caCertificate object classes by a single x509PKCNameForm. 1338 o included a super section x509 Schema Object Classes with 1339 introductory remarks (inspired by [ldap-ac-schema]) 1340 o added some additional wording and some ASCII art in the 1341 introduction 1342 o added some additional wording and some ASCII art in the 1343 introduction to the object classes 1344 o changed the MUST for using multi-valued RDNs into a SHOULD in 1345 section on DIT Structure and Naming 1346 o re-ordered the text so that the section on object classes precedes 1347 the section on attribute types 1348 o included a refernce to RFC 2829 into the security considerations 1349 o updated references 1350 o added an IANA considerations section 1351 o added another acknowledgement 1353 C.5 Changes in draft-ietf-pkix-ldap-pkc-schema-01 1354 o changed attribute type x509policyInformationIdentifier to 1355 MULTI-VALUE 1356 o added new attribute for stroring the basic contraints path length 1357 and included it into the x509PKCext object class. 1359 Intellectual Property Statement 1361 The IETF takes no position regarding the validity or scope of any 1362 Intellectual Property Rights or other rights that might be claimed to 1363 pertain to the implementation or use of the technology described in 1364 this document or the extent to which any license under such rights 1365 might or might not be available; nor does it represent that it has 1366 made any independent effort to identify any such rights. Information 1367 on the procedures with respect to rights in RFC documents can be 1368 found in BCP 78 and BCP 79. 1370 Copies of IPR disclosures made to the IETF Secretariat and any 1371 assurances of licenses to be made available, or the result of an 1372 attempt made to obtain a general license or permission for the use of 1373 such proprietary rights by implementers or users of this 1374 specification can be obtained from the IETF on-line IPR repository at 1375 http://www.ietf.org/ipr. 1377 The IETF invites any interested party to bring to its attention any 1378 copyrights, patents or patent applications, or other proprietary 1379 rights that may cover technology that may be required to implement 1380 this standard. Please address the information to the IETF at 1381 ietf-ipr@ietf.org. 1383 Disclaimer of Validity 1385 This document and the information contained herein are provided on an 1386 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1387 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1388 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1389 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1390 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1393 Copyright Statement 1395 Copyright (C) The Internet Society (2004). This document is subject 1396 to the rights, licenses and restrictions contained in BCP 78, and 1397 except as set forth therein, the authors retain all their rights. 1399 Acknowledgment 1401 Funding for the RFC Editor function is currently provided by the 1402 Internet Society.