idnits 2.17.1 draft-ietf-pkix-ldapv2-schema-01.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-23) 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. == 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 82 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...' == (77 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). -- 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 (August 1998) is 9383 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 229, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 232, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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-01.txt Tim Howes (Netscape) 4 Expires in 6 months Pat Richard (Xcert) 5 August 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), ds.internic.net (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", "REQUIRED", "SHOULD", "RECOMMENDED", and 42 "MAY" in this document are to be interpreted as described in RFC 43 2119. 45 Please send comments on this document to the ietf-pkix@tandem.com 46 mail 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 5. 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 The cACertificate attribute, held in a particular CA's directory 145 entry, may be used to store self-signed certificates. 147 certificateRevocationListATTRIBUTE::={ 148 WITH SYNTAX CertificateList 149 EQUALITY MATCHING RULE certificateListExactMatch 150 ID joint-iso-ccitt(2) ds(5) attributeType(4) certificateRevocationList(39)} 152 The certificateRevocationList attribute, if present in a particular 153 CA's entry, contains CRL(s) as defined in draft-ietf-pkix-ipki- 154 part1-08.txt. 156 authorityRevocationListATTRIBUTE::={ 157 WITH SYNTAX CertificateList 158 EQUALITY MATCHING RULE certificateListExactMatch 159 ID joint-iso-ccitt(2) ds(5) attributeType(4) authorityRevocationList(38)} 161 The authorityRevocationList attribute, if present in a particular 162 CA's entry, includes revocation information regarding certificates 163 issued to other CAs. 165 crossCertificatePairATTRIBUTE::={ 166 WITH SYNTAX CertificatePair 167 EQUALITY MATCHING RULE certificatePairExactMatch 168 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)} 170 The crossCertificatePair attribute, held in a particular CA's 171 directory entry, may be used to store certificates issued by this 172 CA to other CAs, as well as certificates issued for this CA by 173 other CAs. Values held in the forward element are certificates 174 issued for this CA by other CAs, while values in the reverse ele- 175 ment are certificates issued by this CA for other CAs. Either cer- 176 tificate, if present, may be used in building certificate paths 177 for validation and may be published in the directory entries of 178 either CA or both. 180 5.0.1. CRL distribution points 182 CRL distribution points are an optional mechanism, specified in 183 draft-ietf-pkix-ipki-part1-08.txt, which MAY be used to distribute 184 revocation information. 186 A patent statement regarding CRL distribution points can be found 187 at the end of this document. 189 If a CA elects to use CRL distribution points, the following object 190 class is used to represent these. 192 cRLDistributionPoint OBJECT-CLASS::= { 193 SUBCLASS OF { top } 194 KIND structural 195 MUST CONTAIN { commonName } 196 MAY CONTAIN { certificateRevocationList | 197 authorityRevocationList | 198 deltaRevocationList } 199 ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) } 201 The certificateRevocationList and authorityRevocationList attri- 202 butes are as defined above. 204 The commonName attribute and deltaRevocationList attributes, 205 defined in X.509, are duplicated below. 207 commonName ATTRIBUTE::={ 208 SUBTYPE OF name 209 WITH SYNTAX DirectoryString 210 ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) } 212 deltaRevocationList ATTRIBUTE ::= { 213 WITH SYNTAX CertificateList 214 EQUALITY MATCHING RULE certificateListExactMatch 215 ID joint-iso-ccitt(2) ds(5) attributeType(4) deltaRevocationList(53) } 217 6. Security Considerations 219 Since the elements of information which are key to the PKI service 220 (certificates and CRLs) are both digitally signed pieces of infor- 221 mation, no additional integrity service is REQUIRED. 223 Security considerations with respect to retrieval, addition, dele- 224 tion, and modification of the information supported by this schema 225 definition are addressed in draft-ietf-pkix-ipki-ldapv2-08.txt. 227 7. References 229 [1] Lightweight Directory Access Protocol. Y. Yeong, T. Howes, S. 230 Kille, RFC 1777, March 1995. 232 [2] Key Words for use in RFCs to Indicate Requirement Levels, S. 233 Bradner, RFC 2119, March 1997. 235 8. Patent Statements 237 This schema includes elements to store data items associated with 238 patented technology. The Internet Standards Process as defined in 239 RFC 1310 requires a written statement from the Patent holder that a 240 license will be made available to applicants under reasonable terms 241 and conditions prior to approving a specification as a Proposed, 242 Draft or Internet Standard 244 A patent statement for CRL Distribution Points follows. This state- 245 ment has been supplied by the patent holder, not the authors of 246 this specification. 248 The Internet Society, Internet Architecture Board, Internet 249 Engineering Steering Group and the Corporation for National 250 Research Initiatives take no position on the validity or scope of 251 the following patent nor on the appropriateness of the terms of the 252 assurance. The Internet Society and other groups mentioned above 253 have not made any determination as to any other intellectual pro- 254 perty rights which may apply to the practice of this standard. Any 255 further consideration of these matters is the user's responsibil- 256 ity. 258 8.1. CRL Distribution Points 260 Entrust Technologies Incorporated has provided the following state- 261 ment with regard to this patent: 263 Entrust Technologies Incorporated advises the IETF that it holds 264 the Patent (as defined herein) which may relate to the ITU-T. In 265 accordance with the Intellectual Property rights procedures of the 266 ITU-T standards process, Entrust Technologies Incorporated, for 267 itself and its subsidiaries (hereinafter called "Entrust") will 268 offer licenses under its Patent on a perpetual, royalty-free, non- 269 exclusive basis and on non-discriminatory, fair and equitable terms 270 to all parties solely for their use in complying with the Standard 271 (as defined herein), but on condition that any such party offers to 272 Entrust and its corporate affiliates similar licenses under such 273 party's patents, if any, for use in complying with the Standard. 274 Any application for a license under Entrust's Patent pursuant to 275 this Patent Disclosure Statement should be made to: 277 Stephen Samson 278 Entrust Technologies Limited 279 750 Heron Road, Ottawa, Ontario, Canada, K1V 1A7 280 voice: (613) 247 3725 282 As used herein: 284 "Patent" means US Patent 5,699,431 issued on 16 December, 1997 for 285 an invention known as a "Method for Efficient Management of Certi- 286 ficate Revocation Lists and Update Information", which invention is 287 owned or controlled by Entrust and the use of which may be required 288 in conjunction with the Standard. 290 "Standard" means ITU-T Recommendation X.509 (1997 E): Information 291 Technology, Open systems interconnection - The Directory: authenti- 292 cation framework. 294 9. Author's Address 296 Sharon Boeyen 297 Entrust Technologies Limited 298 750 Heron Road 299 Ottawa, Ontario 300 Canada K1V 1A7 301 sharon.boeyen@entrust.com 303 Tim Howes 304 Netscape Communications Corp. 305 501 E. Middlefield Rd. 306 Mountain View, CA 94043 307 USA 308 howes@netscape.com 310 Patrick Richard 311 Xcert Software Inc. 312 Suite 1001, 701 W. Georgia Street 313 P.O. Box 10145 314 Pacific Centre 315 Vancouver, B.C. 316 Canada V7Y 1C6 317 patr@xcert.com