idnits 2.17.1 draft-coretta-x660-ldap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (January 1, 2021) is 1210 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 X660LDAP J. Coretta 3 Internet-Draft January 1, 2021 4 Intended status: Standards Track 5 Expires: July 5, 2021 7 Lightweight Directory Access Protocol (LDAP) 8 Procedures and Schema Definitions for the 9 Storage of X.660 Registration Information 10 draft-coretta-x660-ldap-02.txt 12 Abstract 14 This specification defines models and schema definitions facilitating 15 the storage of [X.660] registration data in a Lightweight Directory 16 Access Protocol Directory Information Tree. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 5, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction ....................................................2 53 1.1. Conventions ................................................2 54 1.2. Intended Audience ..........................................3 55 1.3. Limitations ................................................3 56 1.4. OIDs Used in this Document .................................3 57 1.5. Acronyms Used in this Document .............................3 58 2. Schema Definitions ..............................................3 59 2.1. Attribute Types ............................................4 60 2.1.1. arc ...................................................4 61 2.1.2. arcOID ................................................4 62 2.1.3. arcId .................................................4 63 2.1.4. arcSecId ..............................................4 64 2.1.5. arcAddlSecId ..........................................5 65 2.1.6. arcData ...............................................5 66 2.1.7. arcAuthority ..........................................5 67 2.1.8. arcSponsor ............................................5 68 2.1.9. arcContact ............................................6 69 2.1.10. arcTitle .............................................6 70 2.1.11. arcDescription .......................................6 71 2.2. Object Classes .............................................6 72 2.2.1. x660RootArcEntry ......................................6 73 2.2.2. x660ArcEntry ..........................................7 74 3. Directory Models ................................................7 75 3.1. Naming Context and Organization Entries ....................7 76 3.2. Two-Dimensional Model ......................................7 77 3.2.1. Requirements ........................................7 78 3.2.2. Distinguished Name Convention .......................8 79 3.3. Three-Dimensional Model ....................................8 80 3.3.1. Requirements ........................................8 81 3.3.2. Distinguished Name Convention .......................9 82 3.3.3. Root Arc Entries ...................................10 83 3.4. Arc Authority, Sponsorship and Contact Info ...............10 84 4. References .....................................................11 85 4.1. Normative References ......................................11 86 5. IANA Considerations ............................................11 87 6. Security Considerations ........................................12 88 Author's Address ..................................................12 90 1. Introduction 92 This specification describes a means for storing [X.660] registration 93 and contextual within an LDAP [RFC4510] implementation. 95 1.1. Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 99 and "OPTIONAL" in this document are to be interpreted as described 100 in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 101 all capitals, as shown here. 103 1.2. Intended Audience 105 This specification is intended for use by any entity or individual in 106 need of a means for storing and serving [X.660] data, in whole or in 107 part. 109 1.3. Limitations 111 Some design decisions set forth in this document tend to favor a more 112 generalized implementation as opposed to a strict adherence to all of 113 the precepts defined in [X.660]. 115 One obvious example of this relates to the lack of enforcement of the 116 use (or non-use) of Unicode values during attribute value assignment. 117 While Unicode values are supported where expected, this specification 118 provides no such enforcement. 120 1.4. OIDs Used in this Document 122 This specification provides a registered OID for LDAP schema elements 123 as defined in Section 2. 125 - 1.3.6.1.4.1.56521 (author root) 127 - 1.3.6.1.4.1.56521.101 (specification OID) 129 - 1.3.6.1.4.1.56521.101.1 (schema OID) 131 - 1.3.6.1.4.1.56521.101.1.1 (attribute types OID) 133 - 1.3.6.1.4.1.56521.101.1.2 (object classes OID) 135 1.5. Acronyms Used in this Document 137 DN Distinguished Name 138 RDN Relative Distinguished Name 139 DUA Directory User Agent (an LDAP client) 140 DIT Directory Information Tree 141 OID (ASN.1) Object Identifier 142 LDAP Lightweight Directory Access Protocol 143 ASN.1 Abstract Syntax Notation v1 145 2. Schema Definitions 147 This section discusses the particulars of the LDAP schema definitions 148 made available through this specification. 150 These schema definitions described in this section are provided using 151 LDAP description formats [RFC4512]. These elements are line-wrapped 152 and indented for readability. 154 2.1. Attribute Types 156 The following subsections detail LDAP attribute types created for use 157 within implementations of this specification. 159 2.1.1. arc 161 The arc attribute type allows the storage of an unsigned integer that 162 is meant to represent the primary identifier for an arc registration. 164 ( 1.3.6.1.4.1.56521.101.1.1.1 165 NAME 'arc' 166 DESC 'A single unsigned integer value assigned to an X.660 arc 167 to represent its primary integer identifier' 168 EQUALITY integerMatch 169 SINGLE-VALUE 170 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 172 2.1.2. arcOID 174 The arcOID attribute type allows the storage of an arc's ASN.1 Object 175 Identifier value [X.680] in dot-delimited form. 177 ( 1.3.6.1.4.1.56521.101.1.1.2 178 NAME 'arcOID' 179 DESC 'Dotted ASN.1 Object Identifier for non-root X.660 arcs' 180 EQUALITY objectIdentifierMatch 181 SINGLE-VALUE 182 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 184 2.1.3. arcId 186 The arcId attribute type allows the storage of the primary identifier 187 Unicode value (non-numeric) [X.660] in an arc registration entry. 189 ( 1.3.6.1.4.1.56521.101.1.1.3 190 NAME 'arcId' 191 DESC 'The primary non-numeric Unicode identifier for 192 an X.660 arc' 193 EQUALITY caseIgnoreMatch 194 SINGLE-VALUE 195 SUP name ) 197 2.1.4. arcSecId 199 The arcSecId attribute type allows the storage of an arc registration 200 entry's non-Unicode, non-numeric secondary identifier [X.660]. 202 ( 1.3.6.1.4.1.56521.101.1.1.4 203 NAME 'arcSecId' 204 DESC 'The non-Unicode secondary identifier for an 205 X.660 arc' 206 EQUALITY caseIgnoreMatch 207 SINGLE-VALUE 208 SUP name ) 210 2.1.5. arcAddlSecId 212 The arcAddlSecId attribute type allows the OPTIONAL storage of one or 213 more additional secondary identifiers [X.660] in an arc registration 214 entry. 216 ( 1.3.6.1.4.1.56521.101.1.1.5 217 NAME 'arcAddlSecId' 218 DESC 'The non-Unicode additional secondary identifier for an 219 X.660 arc' 220 EQUALITY caseIgnoreMatch 221 SUP name ) 223 2.1.6. arcData 225 The arcData attribute type allows the OPTIONAL storage of octet-based 226 values intended meant for extended documentation or notes in an arc 227 registration entry. 229 ( 1.3.6.1.4.1.56521.101.1.1.6 230 NAME 'arcData' 231 DESC 'Extended information for an X.660 arc' 232 EQUALITY octetStringMatch 233 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 235 2.1.7. arcAuthority 237 The arcAuthority attribute type allows a DN value that references an 238 entry containing arc registration authority information. 240 ( 1.3.6.1.4.1.56521.101.1.1.7 241 NAME 'arcAuthority' 242 DESC 'LDAP Distinguished Name of an entry bearing authoritative 243 information for an X.660 arc' 244 EQUALITY distinguishedNameMatch 245 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 247 2.1.8. arcSponsor 249 The arcSponsor attribute type allows a DN value that references an 250 entry containing arc registration sponsorship information. 252 ( 1.3.6.1.4.1.56521.101.1.1.8 253 NAME 'arcSponsor' 254 DESC 'LDAP Distinguished Name of an entry bearing sponsorship 255 information for an X.660 arc' 256 EQUALITY distinguishedNameMatch 257 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 259 2.1.9. arcContact 261 The arcContact attribute type allows a DN value that references an 262 entry containing arc registration contact information. 264 ( 1.3.6.1.4.1.56521.101.1.1.9 265 NAME 'arcContact' 266 DESC 'LDAP Distinguished Name of an entry bearing generalized 267 contact information for an X.660 arc' 268 EQUALITY distinguishedNameMatch 269 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 271 2.1.10. arcTitle 273 The arcTitle attribute type allows for an official title to be set 274 for an arc registration entry. 276 ( 1.3.6.1.4.1.56521.101.1.1.10 277 NAME 'arcTitle' 278 DESC 'Title assigned to an X.660 arc' 279 SUP title ) 281 2.1.11. arcDescription 283 The arcDescription attribute type allows for a short description of 284 an arc registration entry. 286 ( 1.3.6.1.4.1.56521.101.1.1.11 287 NAME 'arcDescription' 288 DESC 'Short description of an X.660 arc' 289 SUP description ) 291 2.2. Object Classes 293 The following subsections describes LDAP object classes made 294 available by this specification. 296 2.2.1. x660RootArcEntry 298 The x660RootArcEntry class is meant to define a maximum of three (3) 299 root arcs within a directory model. 301 ( 1.3.6.1.4.1.56521.101.1.2.1 302 NAME 'x660RootArcEntry' 303 DESC 'Top-level class for entries meant to represent ITU-T, ISO 304 or Joint-ISO-ITU-T root arcs as defined in Section A.2 of 305 the X.660 specification' 306 SUP top 307 STRUCTURAL 308 MUST ( arc $ arcId ) 309 MAY ( arcData $ arcAuthority $ arcSponsor $ arcContact $ 310 arcSecId $ labeledURI $ arcDescription $ arcTitle $ 311 arcAddlSecId ) ) 313 2.2.2. x660ArcEntry 315 The x660ArcEntry object class makes a collection of attribute types 316 available for use when crafting non-root arc entries within a DIT. 318 ( 1.3.6.1.4.1.56521.101.1.2.2 319 NAME 'x660ArcEntry' 320 DESC 'A generalized class meant to represent subordinate arcs 321 beneath any root, as defined in X.660 Sections A.3-A.5' 322 SUP top 323 STRUCTURAL 324 MUST ( arc ) 325 MAY ( arcAddlSecId $ arcData $ arcOID $ arcSecId $ arcId $ 326 arcAuthority $ arcSponsor $ arcContact $ labeledURI $ 327 arcDescription $ arcTitle ) ) 329 3. Directory Models 331 This specification offers two (2) distinct models by which directory 332 architects and application developers SHOULD be guided during their 333 efforts for implementation. 335 3.1. Naming Context and Organization Entries 337 In these examples, a naming context of "dc=example, dc=com" is used 338 as the fictional "suffix". Within this suffix are two (2) entries: 340 - "ou=X660, dc=example, dc=com" - Storage of all arc registration 341 entries. 343 - "ou=Registrants, dc=example, dc=com" - Storage of all arc 344 contact, authority and sponsorship entries. 346 Directory architects MAY choose to use models of their own design, so 347 long as noted requirements in the following sections are satisfied. 349 3.2. Two-Dimensional Model 351 This model suggests that arc registration entries reside as siblings 352 within an LDAP DIT in singular, non-hierarchical locations. 354 3.2.1. Requirements 356 One requirement of this model is strict use of the arcOID attribute 357 type, covered in Section 2.1.2. This attribute MUST be used on all 358 non-root arc registration entries. 360 Root arc registration entries SHALL NOT bear an arcOID value, as the 361 syntax for OIDs (see Section 3.3.26 of [RFC4517]) requires at least 362 two (2) nodes in a given value. 364 Uniqueness of arcOID values within a directory structure MUST always 365 be enforced to ensure unambiguous results. The simplest way to meet 366 this requirement would be to adopt arcOID-based DN structure as shown 367 in the next section. 369 3.2.2. Distinguished Name Convention 371 Because all LDAP search requests can be conducted using a "one-level 372 scope" below the circumscribing directory branch, a hierarchical DN 373 structure is unnecessary. While the three-dimensional model (shown 374 in Section 3.3) uses the integer-based arc attribute type (defined in 375 Section 2.1.1) to form the effective LDAP RDN of an entry, it is not 376 practical in this model. 378 The most sensible convention for DN involves use of the arcOID 379 attribute as shown: 381 dn: arcOID=1.3,ou=X660,dc=example,dc=com 382 objectClass: top 383 objectClass: x660ArcEntry 384 arc: 3 385 arcId: Identified-Organization 386 arcOID: 1.3 388 Subsequent entries, regardless of hierarchical superiority, manifest 389 as sibling entries. For example, the addition of deeper arcs would 390 be procedurally identical: 392 dn: arcOID=1.3.6.1,ou=X660,dc=example,dc=com 393 objectClass: top 394 objectClass: x660ArcEntry 395 arc: 1 396 arcId: internet 397 arcOID: 1.3.6.1 399 3.3. Three-Dimensional Model 401 This model is hierarchical by nature, providing a means for storing 402 arc registration entries in "nested" fashion, thereby reflecting the 403 hierarchy of the [X.660] specification itself. 405 3.3.1. Requirements 407 In this model, interim arc registrations MUST exist even if they are 408 otherwise unnecessary. 410 For example, in order to add the well-known arc "internet" (OID: 411 1.3.6.1, [RFC1155]), directory administrators MUST ensure these 412 registrations exist beforehand: 414 dn: arc=1,ou=X660,dc=example,dc=com 415 objectClass: top 416 objectClass: x660RootArcEntry 417 arc: 1 418 arcId: ISO 420 dn: arc=3,arc=1,ou=X660,dc=example,dc=com 421 objectClass: top 422 objectClass: x660ArcEntry 423 arc: 3 424 arcId: Identified-Organization 426 dn: arc=6,arc=3,arc=1,ou=X660,dc=example,dc=com 427 objectClass: top 428 objectClass: x660ArcEntry 429 arc: 6 430 arcId: dod 432 Only once this requirement is satisfied would the administrators be 433 able to create the desired registration, such as a registration 434 entry for the "internet" OID, as shown in [RFC1155]: 436 dn: arc=1,arc=6,arc=3,arc=1,ou=X660,dc=example,dc=com 437 objectClass: top 438 objectClass: x660ArcEntry 439 arc: 1 440 arcId: internet 442 3.3.2. Distinguished Name Convention 444 Under a strict interpretation of this model, its implementation will 445 provide a means for bidirectional resolution of registered arc OIDs. 446 LDAP DNs can be deduced from OIDs, and vice versa. 448 This is achieved by using the arc attribute type (as discussed in 449 Section 2.1.1) as components in the effective LDAP DN, but in reverse 450 order to reflect the directory hierarchy. 452 For example: the "internet" arc (OID: 1.3.6.1) would exist as an 453 entry with a DN as depicted below: 455 dn: arc=1, arc=6, arc=3, arc=1, ou=X660, dc=example, dc=com 456 | | | | 457 ---------------------- 458 1.3.6.1 460 3.3.3. Root Arc Entries 462 A maximum of three (3) root arcs SHOULD exist within the directory 463 landscape. If one or more are created, they MUST be identifiable 464 as follows: 466 - ITU-T (0) 468 - ISO (1) 470 - Joint-ISO-ITU-T (2) 472 As sibling entries, these root arcs MUST use the x660RootArcEntry 473 class, as shown in Section 2.2.1: 475 dn: arc=0,ou=X660,dc=example,dc=com 476 objectClass: top 477 objectClass: x660RootArcEntry 478 arc: 0 479 arcId: ITU-T 481 dn: arc=1,ou=X660,dc=example,dc=com 482 objectClass: top 483 objectClass: x660RootArcEntry 484 arc: 1 485 arcId: ISO 487 dn: arc=2,ou=X660,dc=example,dc=com 488 objectClass: top 489 objectClass: x660RootArcEntry 490 arc: 2 491 arcId: Joint-ISO-ITU-T 493 Depending on the breadth and scope of an implementation, creation and 494 use of root arc registration entries is RECOMMENDED, but not required 495 in all situations. 497 3.4. Arc Authority, Sponsorship and Contact Info 499 Directory architects MAY choose to store authoritative, sponsorship 500 or generalized contact information in one of two main ways: 502 - Use of an AUXILIARY object class [RFC4512] to facilitate the 503 addition of any desired supplemental attribute types directly 504 to a given instance of x660RootArcEntry or x660ArcEntry, or ... 506 - Use of independent arc registration contact entries, which are 507 referenced via LDAP DN through one or more of: arcAuthority, 508 arcContact and/or arcSponsor attribute types assigned directly 509 to a given instance of x660RootArcEntry or x660ArcEntry 511 For compatibility reasons, it is RECOMMENDED that only [RFC4519] 512 attribute types be used to detail contact, authority or sponsorship 513 information. 515 4. References 517 4.1. Normative References 519 [RFC1155] Rose, M., "Structure and Identification of Management 520 Information for TCP/IP-based Internets", RFC 1155, 521 May 1990. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 527 (LDAP): Technical Specification Road Map", RFC 4510, June 528 2006. 530 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 531 (LDAP): Directory Information Models", RFC 4512, June 532 2006. 534 [RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol 535 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 536 2006. 538 [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol 539 (LDAP): Schema for User Applications", RFC 4519, June 540 2006. 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 543 2119 Key Words", RFC 8174, May 2017. 545 [X.660] International Telecommunication Union - Telecommunication 546 Standardization Sector, "General procedures and top arcs 547 of the international object identifier tree", X.660, July 548 2011. 550 [X.680] International Telecommunication Union - Telecommunication 551 Standardization Sector, "Abstract Syntax Notation One 552 (ASN.1): Specification of basic notation", X.680, July 553 2002. 555 5. IANA Considerations 557 There are no requests to IANA in this document. 559 6. Security Considerations 561 This document focuses on providing flexible directory models and LDAP 562 schema elements in order to serve arc registration data, and to allow 563 an LDAP-based means for OID resolution, either within an organization 564 or within the context of personal use. If some or all of the data in 565 the directory is sensitive in nature, directory architects MUST take 566 appropriate steps to secure this information. This concept is out of 567 scope for this document. 569 Beyond this, there are no specific concerns in the area of security. 571 Author's Address 573 Jesse Coretta 574 Palm Springs, CA 92262 576 Email: jesse.coretta@icloud.com