idnits 2.17.1 draft-ietf-pkix-ldapv2-schema-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-pkix-LDAPv2-schema-02', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-ietf-pkix-LDAPv2-schema-02', but the file name used is 'draft-ietf-pkix-ldapv2-schema-02' == No 'Intended status' indicated for this document; assuming Proposed Standard 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 85 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...-Drafts are ...' == Line 15 has weird spacing: '...ay also distr...' == Line 19 has weird spacing: '... months and ...' == Line 20 has weird spacing: '...iate to use ...' == Line 21 has weird spacing: '...ference mater...' == (80 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1998) is 9345 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: '1' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Sharon Boeyen (Entrust) 3 draft-ietf-pkix-LDAPv2-schema-02.txt Tim Howes (Netscape) 4 Expires in 6 months Pat Richard (Xcert) 5 September 1998 7 Internet X.509 Public Key Infrastructure 8 LDAPv2 Schema 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other docu- 20 ments at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in pro- 22 gress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 2. Abstract 32 The schema defined in this document is a minimal schema to support 33 PKIX in an LDAPv2 environment, as defined in draft-ietf-pkix- 34 ipki2opp-07.txt. Only PKIX-specific components are specified here. 35 LDAP servers, acting as PKIX repositories should support the auxi- 36 liary object classes defined in this specification and integrate 37 this schema specification with the generic and other application- 38 specific schemas as appropriate, depending on the services to be 39 supplied by that server. 41 The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', 42 and 'MAY' in this document are to be interpreted as described in 43 RFC 2119. 45 Please send comments on this document to the ietf-pkix@imc.org mail 46 list. 48 3. Introduction 50 This specification is part of a multi-part standard for development 51 of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is 52 one mechanism defined for access to a PKI repository. Other mechan- 53 isms, such as http, are also defined. If an LDAP server, accessed 54 by LDAPv2 is used to provide a repository, the minimum requirement 55 is that the repository support the addition of X.509 certificates 56 to directory entries. Certificate Revocation List (CRL)is one 57 mechanism for publishing revocation information in a repository. 58 Other mechanisms, such as http, are also defined. 60 This specification defines the attributes and object classes to be 61 used by LDAP servers acting as PKIX repositories and to be under- 62 stood by LDAP clients communicating with such repositories to 63 query, add, modify and delete PKI information. Some object classes 64 and attributes defined in X.509 are duplicated here for complete- 65 ness. For end entities and Certification Authorities (CA), the ear- 66 lier X.509 defined object classes mandated inclusion of attributes 67 which are optional for PKIX. Also, because of the mandatory attri- 68 bute specification, this would have required dynamic modification 69 of the object class attribute should the attributes not always be 70 present in entries. For these reasons, alternative object classes 71 are defined in this document for use by LDAP servers acting as PKIX 72 repositories. 74 4. PKIX Repository Objects 76 The primary PKIX objects to be represented in a repository are: 78 - End Entities 79 - Certification Authorities (CA) 81 These objects are defined in draft-ietf-pkix-ipki-part1-09.txt. 83 4.1. End Entities 85 For purposes of PKIX schema definition, the role of end entities as 86 subjects of certificates is the major aspect relevant to this 87 specification. End entities may be human users, or other types of 88 entities to which certificates may be issued. In some cases, the 89 entry for the end entity may already exist and the PKI-specific 90 information is added to the existing entry. In other cases the 91 entry may not exist prior to the issuance of a certificate, in 92 which case the entity adding the certificate may also need to 93 create the entry. Schema elements used to represent the non PKIX 94 aspects of an entry, such as the structural object class used to 95 represent organizational persons, may vary, depending on the 96 particular environment and set of applications served and are out- 97 side the scope of this specification. 99 The following auxiliary object class MAY be used to represent cer- 100 tificate subjects: 102 pkiUser OBJECT-CLASS ::= { 103 SUBCLASS OF { top} 104 KIND auxiliary 105 MAY CONTAIN {userCertificate} 106 --ID { joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)} 108 userCertificate ATTRIBUTE ::= { 109 WITH SYNTAX Certificate 110 EQUALITY MATCHING RULE certificateExactMatch 111 ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) } 113 An end entity may obtain one or more certificates from one or more 114 Certification Authorities. The userCertificate attribute MUST be 115 used to represent these certificates in the directory entry 116 representing that user. 118 4.2. Certification Authorities 120 As with end entities, Certification Authorities are typically 121 represented in directories as auxiliary components of entries 122 representing a more generic object, such as organizations, organi- 123 zational units etc. The non PKIX-specific schema elements for these 124 entries, such as the structural object class of the object, are 125 outside the scope of this specification. 127 The following auxiliary object class MAY be used to represent Cer- 128 tification Authorities: 130 pkiCA OBJECT-CLASS ::= { 131 SUBCLASS OF { top} 132 KIND auxiliary 133 MAY CONTAIN {cACertificate | 134 certificateRevocationList | 135 authorityRevocationList | 136 crossCertificatePair } 137 --ID { joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)} 139 cACertificate ATTRIBUTE ::= { 140 WITH SYNTAX Certificate 141 EQUALITY MATCHING RULE certificateExactMatch 142 ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) } 144 crossCertificatePairATTRIBUTE::={ 145 WITH SYNTAX CertificatePair 146 EQUALITY MATCHING RULE certificatePairExactMatch 147 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)} 149 The cACertificate attribute of a CA's directory entry shall be used 150 to store self-issued certificates (if any) and certificates issued 151 to this CA by CAs in the same realm as this CA. 153 The forward elements of the crossCertificatePair attribute of a 154 CA's directory entry shall be used to store all, except self-issued 155 certificates issued to this CA. Optionally, the reverse elements 156 of the crossCertificatePair attribute, of a CA's directory entry 157 may contain a subset of certificates issued by this CA to other 158 CAs. When both the forward and the reverse elements are present in 159 a single attribute value, issuer name in one certificate shall 160 match the subject name in the other and vice versa, and the subject 161 public key in one certificate shall be capable of verifying the 162 digital signature on the other certificate and vice versa. 164 When a reverse element is present, the forward element value and 165 the reverse element value need not be stored in the same attribute 166 value; in other words, they can be stored in either a single attri- 167 bute value or two attribute values. 169 In the case of V3 certificates, none of the above CA certificates 170 shall include a basicConstraints extension with the cA value set to 171 FALSE. 173 The definition of realm is purely a matter of local policy. 175 certificateRevocationListATTRIBUTE::={ 176 WITH SYNTAX CertificateList 177 EQUALITY MATCHING RULE certificateListExactMatch 178 ID joint-iso-ccitt(2) ds(5) attributeType(4) certificateRevocationList(39)} 180 The certificateRevocationList attribute, if present in a particular 181 CA's entry, contains CRL(s) as defined in draft-ietf-pkix-ipki- 182 part1-08.txt. 184 authorityRevocationListATTRIBUTE::={ 185 WITH SYNTAX CertificateList 186 EQUALITY MATCHING RULE certificateListExactMatch 187 ID joint-iso-ccitt(2) ds(5) attributeType(4) authorityRevocationList(38)} 189 The authorityRevocationList attribute, if present in a particular 190 CA's entry, includes revocation information regarding certificates 191 issued to other CAs. 193 4.2.1. CRL distribution points 195 CRL distribution points are an optional mechanism, specified in 196 draft-ietf-pkix-ipki-part1-09.txt, which MAY be used to distribute 197 revocation information. 199 A patent statement regarding CRL distribution points can be found 200 at the end of this document. 202 If a CA elects to use CRL distribution points, the following object 203 class is used to represent these. 205 cRLDistributionPoint OBJECT-CLASS::= { 206 SUBCLASS OF { top } 207 KIND structural 208 MUST CONTAIN { commonName } 209 MAY CONTAIN { certificateRevocationList | 210 authorityRevocationList | 211 deltaRevocationList } 212 ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) } 214 The certificateRevocationList and authorityRevocationList attri- 215 butes are as defined above. 217 The commonName attribute and deltaRevocationList attributes, 218 defined in X.509, are duplicated below. 220 commonName ATTRIBUTE::={ 221 SUBTYPE OF name 222 WITH SYNTAX DirectoryString 223 ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) } 225 deltaRevocationList ATTRIBUTE ::= { 226 WITH SYNTAX CertificateList 227 EQUALITY MATCHING RULE certificateListExactMatch 228 ID joint-iso-ccitt(2) ds(5) attributeType(4) deltaRevocationList(53) } 230 4.2.2. Delta CRLs 232 Delta CRLs are an optional mechanism, specified in draft-ietf- 233 pkix-ipki-part1-09.txt, which MAY be used to enhance the distribu- 234 tion of revocation information. 236 If a CA elects to use delta CRLs, the following object class is 237 used to represent these. 239 deltaCRL OBJECT-CLASS::= { 240 SUBCLASS OF { top } 241 KIND auxiliary 242 MAY CONTAIN { deltaRevocationList } 243 ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) } 245 5. Security Considerations 247 Since the elements of information which are key to the PKI service 248 (certificates and CRLs) are both digitally signed pieces of infor- 249 mation, no additional integrity service is REQUIRED. 251 Security considerations with respect to retrieval, addition, dele- 252 tion, and modification of the information supported by this schema 253 definition are addressed in draft-ietf-pkix-ipki-ldapv2-08.txt. 255 6. References 257 [1] Lightweight Directory Access Protocol. Y. Yeong, T. Howes, S. 258 Kille, RFC 1777, March 1995. 260 [2] Key Words for use in RFCs to Indicate Requirement Levels, S. 261 Bradner, RFC 2119, March 1997. 263 7. Patent Statements 265 This schema includes elements to store data items associated with 266 patented technology. The Internet Standards Process as defined in 267 RFC 1310 requires a written statement from the Patent holder that a 268 license will be made available to applicants under reasonable terms 269 and conditions prior to approving a specification as a Proposed, 270 Draft or Internet Standard 272 A patent statement for CRL Distribution Points follows. This state- 273 ment has been supplied by the patent holder, not the authors of 274 this specification. 276 The Internet Society, Internet Architecture Board, Internet 277 Engineering Steering Group and the Corporation for National 278 Research Initiatives take no position on the validity or scope of 279 the following patent nor on the appropriateness of the terms of the 280 assurance. The Internet Society and other groups mentioned above 281 have not made any determination as to any other intellectual pro- 282 perty rights which may apply to the practice of this standard. Any 283 further consideration of these matters is the user's responsibil- 284 ity. 286 7.1. CRL Distribution Points 288 Entrust Technologies Incorporated has provided the following 289 statement with regard to this patent: 291 Entrust Technologies Incorporated advises the IETF that it holds 292 the Patent (as defined herein) which may relate to the ITU-T. In 293 accordance with the Intellectual Property rights procedures of the 294 ITU-T standards process, Entrust Technologies Incorporated, for 295 itself and its subsidiaries (hereinafter called "Entrust") will 296 offer licenses under its Patent on a perpetual, royalty-free, non- 297 exclusive basis and on non-discriminatory, fair and equitable terms 298 to all parties solely for their use in complying with the Standard 299 (as defined herein), but on condition that any such party offers to 300 Entrust and its corporate affiliates similar licenses under such 301 party's patents, if any, for use in complying with the Standard. 302 Any application for a license under Entrust's Patent pursuant to 303 this Patent Disclosure Statement should be made to: 305 Stephen Samson 306 Entrust Technologies Limited 307 750 Heron Road, Ottawa, Ontario, Canada, K1V 1A7 308 voice: (613) 247 3725 310 As used herein: 312 "Patent" means US Patent 5,699,431 issued on 16 December, 1997 for 313 an invention known as a "Method for Efficient Management of Certi- 314 ficate Revocation Lists and Update Information", which invention is 315 owned or controlled by Entrust and the use of which may be required 316 in conjunction with the Standard. 318 "Standard" means ITU-T Recommendation X.509 (1997 E): Information 319 Technology, Open systems interconnection - The Directory: authenti- 320 cation framework. 322 8. Author's Address 324 Sharon Boeyen 325 Entrust Technologies Limited 326 750 Heron Road 327 Ottawa, Ontario 328 Canada K1V 1A7 329 sharon.boeyen@entrust.com 331 Tim Howes 332 Netscape Communications Corp. 333 501 E. Middlefield Rd. 334 Mountain View, CA 94043 335 USA 336 howes@netscape.com 337 Patrick Richard 338 Xcert Software Inc. 339 Suite 1001, 701 W. Georgia Street 340 P.O. Box 10145 341 Pacific Centre 342 Vancouver, B.C. 343 Canada V7Y 1C6 344 patr@xcert.com