idnits 2.17.1 draft-ietf-pkix-ldapv2-schema-00.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-20) 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 62 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 9 instances of too long lines in the document, the longest one being 13 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...' == (57 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 (March 1998) is 9533 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 224, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 227, 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-00.txt Tim Howes (Netscape) 4 Expires in 6 months Pat Richard (Xcert) 5 March 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-ipki- 34 ldapv2-06.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 66 relevant X.509 defined object classes mandate inclusion of attri- 67 butes which are optional for PKIX. Also, because of the mandatory 68 attribute specification, this would have required dynamic modifica- 69 tion of the object class attribute should the attributes not always 70 be present in entries. For these reasons, alternative object 71 classes are defined in this document to be used for these objects, 72 rather than the X.509 defined classes, by LDAP servers acting as 73 PKIX repositories. 75 4. PKIX Repository Objects 77 The primary PKIX objects to be represented in a repository are: 79 - End Entities 80 - Certification Authorities (CA) 82 These objects are defined in draft-ietf-pkix-ipki-part1-06.txt. 84 4.1. End Entities 86 For purposes of PKIX schema definition, the role of end entities as 87 subjects of certificates is the major aspect relevant to this 88 specification. End entities may be human users, or other types of 89 entities to which certificates may be issued. In some cases, the 90 entry for the end entity may already exist and the PKI-specific 91 information is added to the existing entry. In other cases the 92 entry may not exist prior to the issuance of a certificate, in 93 which case the entity adding the certificate may also need to 94 create the entry. Schema elements used to represent the non PKIX 95 aspects of an entry, such as the structural object class used to 96 represent organizational persons, may vary, depending on the par- 97 ticular environment and set of applications served and are outside 98 the scope of this specification. 100 The following auxiliary object class MAY be used to represent cer- 101 tificate subjects: 102 pkiUser OBJECT-CLASS ::= { 103 SUBCLASS OF { top} 104 KIND auxiliary 105 MAY CONTAIN {userCertificate} 106 --ID { iso(1) identified-organization(3) dod(6) internet(1) 107 security(5) mechanisms(5) pkix(7) t.b.s } 109 userCertificate ATTRIBUTE ::= { 110 WITH SYNTAX Certificate 111 EQUALITY MATCHING RULE certificateExactMatch 112 ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) } 114 An end entity may obtain one or more certificates from one or more 115 Certification Authorities. The userCertificate attribute MUST be 116 used to represent these certificates in the directory entry 117 representing that user. 119 5. Certification Authorities 121 As with end entities, Certification Authorities are typically 122 represented in directories as auxiliary components of entries 123 representing a more generic object, such as organizations, organi- 124 zational units etc. The non PKIX-specific schema elements for these 125 entries, such as the structural object class of the object, are 126 outside the scope of this specification. 128 The following auxiliary object class MAY be used to represent Cer- 129 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 { iso(1) identified-organization(3) dod(6) internet(1) 138 security(5) mechanisms(5) pkix(7) t.b.s. } 140 cACertificate ATTRIBUTE ::= { 141 WITH SYNTAX Certificate 142 EQUALITY MATCHING RULE certificateExactMatch 143 ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) } 145 The cACertificate attribute, held in a particular CA's directory 146 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) } 151 The certificateRevocationList attribute, if present in a particular 152 CA's entry, contains CRL(s) as defined in draft-ietf-pkix-ipki- 153 part1-06.txt. 154 authorityRevocationListATTRIBUTE::={ 155 WITH SYNTAX CertificateList 156 EQUALITY MATCHING RULE certificateListExactMatch 157 ID joint-iso-ccitt(2) ds(5) attributeType(4) authorityRevocationList(38) } 159 The authorityRevocationList attribute, if present in a particular 160 CA's entry, includes revocation information regarding certificates 161 issued to other CAs. 162 crossCertificatePairATTRIBUTE::={ 163 WITH SYNTAX CertificatePair 164 EQUALITY MATCHING RULE certificatePairExactMatch 165 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) } 167 The crossCertificatePair attribute, held in a particular CA's 168 directory entry, may be used to store certificates issued by this 169 CA to other CAs, as well as certificates issued for this CA by 170 other CAs. Values held in the forward element are certificates 171 issued for this CA by other CAs, while values in the reverse ele- 172 ment are certificates issued by this CA for other CAs. Either cer- 173 tificate, if present, may be used in building certificate paths 174 for validation and may be published in the directory entries of 175 either CA or both. 177 5.0.1. CRL distribution points 179 CRL distribution points are an optional mechanism, specified in 180 draft-ietf-pkix-ipki-part1-06.txt, which MAY be used to distribute 181 revocation information. 183 A patent statement regarding CRL distribution points can be found 184 at the end of this document (t.b.s.). 186 If a CA elects to use CRL distribution points, the following object 187 class is used to represent these. 188 cRLDistributionPoint OBJECT-CLASS::= { 189 SUBCLASS OF { top } 190 KIND structural 191 MUST CONTAIN { commonName } 192 MAY CONTAIN { certificateRevocationList | 193 authorityRevocationList | 194 deltaRevocationList } 195 ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) } 197 The certificateRevocationList and authorityRevocationList attri- 198 butes are as defined above. 200 The commonName attribute and deltaRevocationList attributes, 201 defined in X.509, are duplicated below. 202 commonName ATTRIBUTE::={ 203 SUBTYPE OF name 204 WITH SYNTAX DirectoryString 205 ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) } 207 deltaRevocationList ATTRIBUTE ::= { 208 WITH SYNTAX CertificateList 209 EQUALITY MATCHING RULE certificateListExactMatch 210 ID joint-iso-ccitt(2) ds(5) attributeType(4) deltaRevocationList(53) } 212 6. Security Considerations 214 Since the elements of information which are key to the PKI service 215 (certificates and CRLs) are both digitally signed pieces of infor- 216 mation, no additional integrity service is REQUIRED. 218 Security considerations with respect to retrieval, addition, dele- 219 tion, and modification of the information supported by this schema 220 definition are addressed in draft-ietf-pkix-ipki-ldapv2-06.txt. 222 7. References 224 [1] Lightweight Directory Access Protocol. Y. Yeong, T. Howes, S. 225 Kille, RFC 1777, March 1995. 227 [2] Key Words for use in RFCs to Indicate Requirement Levels, S. 228 Bradner, RFC 2119, March 1997. 230 8. Author's Address 232 Sharon Boeyen 233 Entrust Technologies Limited 234 750 Heron Road 235 Ottawa, Ontario 236 Canada K1V 1A7 237 sharon.boeyen@entrust.com 239 Tim Howes 240 Netscape Communications Corp. 241 501 E. Middlefield Rd. 242 Mountain View, CA 94043 243 USA 244 howes@netscape.com 246 Patrick Richard 247 Xcert Software Inc. 248 Suite 1001, 701 W. Georgia Street 249 P.O. Box 10145 250 Pacific Centre 251 Vancouver, B.C. 252 Canada V7Y 1C6 253 patr@xcert.com