idnits 2.17.1 draft-coretta-x660-ldap-08.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 5 instances of lines with control characters in the document. == 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 == Line 2057 has weird spacing: '...sorship data ...' -- The document date (January 23, 2022) is 824 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) == Missing Reference: 'RFC4511' is mentioned on line 3150, but not defined == Missing Reference: 'RFC 4511' is mentioned on line 2169, but not defined == Unused Reference: 'RFC3296' is defined on line 3203, but no explicit reference was found in the text == Unused Reference: 'PRIVATE' is defined on line 3223, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 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 23, 2022 4 Intended status: Standards Track 5 Expires: July 23, 2022 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-08.txt 12 Abstract 14 This specification defines models, procedures and schema definitions 15 meant to facilitate the storage of [X.660] registration data within 16 a Lightweight Directory 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 23, 2022. 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 ....................................................4 53 1.1. Conventions ................................................5 54 1.2. Acronyms Used ..............................................5 55 1.3. Intended Audience ..........................................5 56 1.4. OIDs Allocated .............................................5 57 1.5. Well-Known OIDs ............................................6 58 2. Schema Definitions ..............................................6 59 2.1. Attribute Types ............................................6 60 2.1.1. 'n' ...................................................7 61 2.1.2. 'dotNotation' .........................................7 62 2.1.3. 'iRI' .................................................7 63 2.1.4. 'asn1Notation' ........................................8 64 2.1.5. 'unicodeValue' ........................................8 65 2.1.6. 'identifier' ..........................................9 66 2.1.7. 'additionalIdentifier' ................................9 67 2.1.8. 'registrationInformation' .............................9 68 2.1.9. 'registrationURI' .....................................9 69 2.1.10. 'registrationCreated' ...............................10 70 2.1.11. 'registrationModified' ..............................10 71 2.1.12. 'registrationRange' .................................10 72 2.1.13. 'registrationStatus' ................................11 73 2.1.14. 'isLeafNode' ........................................12 74 2.1.15. 'isFrozen' ..........................................12 75 2.1.16. 'stdNameForm' .......................................13 76 2.1.17. 'nameAndNumberForm' .................................13 77 2.1.18. 'longArc' ...........................................13 78 2.1.19. 'supArc' ............................................14 79 2.1.20. 'topArc' ............................................14 80 2.1.21. 'subArc' ............................................15 81 2.1.22. 'leftArc' ...........................................15 82 2.1.23. 'firstArc' ..........................................16 83 2.1.24. 'rightArc' ..........................................16 84 2.1.25. 'finalArc' ..........................................17 85 2.1.26. 'discloseTo' ........................................17 86 2.1.27. 'registrantID .......................................18 87 2.1.28. 'currentAuthority' ..................................18 88 2.1.29. 'currentAuthorityStartTimestamp' ....................19 89 2.1.30. 'currentAuthorityCommonName' ........................19 90 2.1.31. 'currentAuthorityCountryCode' .......................19 91 2.1.32. 'currentAuthorityCountryName' .......................20 92 2.1.33. 'currentAuthorityEmail' .............................20 93 2.1.34. 'currentAuthorityFax' ...............................20 94 2.1.35. 'currentAuthorityLocality' ..........................21 95 2.1.36. 'currentAuthorityMobile' ............................21 96 2.1.37. 'currentAuthorityOrg' ...............................21 97 2.1.38. 'currentAuthorityPOBox' .............................22 98 2.1.39. 'currentAuthorityPostalAddress' .....................22 99 2.1.40. 'currentAuthorityPostalCode' ........................22 100 2.1.41. 'currentAuthorityState' .............................23 101 2.1.42. 'currentAuthorityStreet' ............................23 102 2.1.43. 'currentAuthorityTelephone' .........................23 103 2.1.44. 'currentAuthorityTitle' .............................24 104 2.1.45. 'currentAuthorityURI' ...............................24 105 2.1.46. 'firstAuthority' ....................................24 106 2.1.47. 'firstAuthorityStartTimestamp' ......................25 107 2.1.48. 'firstAuthorityEndTimestamp' ........................25 108 2.1.49. 'firstAuthorityCommonName' ..........................25 109 2.1.50. 'firstAuthorityCountryCode' .........................26 110 2.1.51. 'firstAuthorityCountryName' .........................26 111 2.1.52. 'firstAuthorityEmail' ...............................26 112 2.1.53. 'firstAuthorityFax' .................................27 113 2.1.54. 'firstAuthorityLocality' ............................27 114 2.1.55. 'firstAuthorityMobile' ..............................27 115 2.1.56. 'firstAuthorityOrg' .................................28 116 2.1.57. 'firstAuthorityPOBox' ...............................28 117 2.1.58. 'firstAuthorityPostalAddress' .......................29 118 2.1.59. 'firstAuthorityPostalCode' ..........................29 119 2.1.60. 'firstAuthorityState' ...............................29 120 2.1.61. 'firstAuthorityStreet' ..............................30 121 2.1.62. 'firstAuthorityTelephone' ...........................30 122 2.1.63. 'firstAuthorityTitle' ...............................30 123 2.1.64. 'firstAuthorityURI' .................................31 124 2.1.65. 'sponsor' ...........................................31 125 2.1.66. 'sponsorStartTimestamp ..............................32 126 2.1.67. 'sponsorEndTimestamp ................................32 127 2.1.68. 'sponsorCommonName' .................................32 128 2.1.69. 'sponsorCountryCode' ................................32 129 2.1.70. 'sponsorCountryName' ................................33 130 2.1.71. 'sponsorEmail' ......................................33 131 2.1.72. 'sponsorFax' ........................................33 132 2.1.73. 'sponsorLocality' ...................................34 133 2.1.74. 'sponsorMobile' .....................................34 134 2.1.75. 'sponsorOrg' ........................................34 135 2.1.76. 'sponsorPOBox' ......................................35 136 2.1.77. 'sponsorPostalAddress' ..............................35 137 2.1.78. 'sponsorPostalCode' .................................35 138 2.1.79. 'sponsorState' ......................................36 139 2.1.80. 'sponsorStreet' .....................................36 140 2.1.81. 'sponsorTelephone' ..................................36 141 2.1.82. 'sponsorTitle' ......................................37 142 2.1.83. 'sponsorURI' ........................................37 143 2.1.84. 'rARegistrationBase' ................................37 144 2.1.85. 'rARegistrantBase' ..................................38 145 2.1.86. 'rADirectoryModel' ..................................38 146 2.1.87. 'rAServiceMail' .....................................39 147 2.1.88. 'rAServiceURI' ......................................39 148 2.2. Object Classes ............................................40 149 2.2.1. 'x660RootArc' ........................................40 150 2.2.2. 'x660SubArc' .........................................40 151 2.2.3. 'x660Registrant' .....................................41 152 2.2.4. 'x660DUAConfig' ......................................41 153 3. Directory Models and Procedures ................................42 154 3.1. Naming Context and Organization Entries ...................42 155 3.2. Two-Dimensional Model .....................................42 156 3.2.1. Requirements .........................................42 157 3.2.2. Distinguished Name Convention ........................43 158 3.2.3. Root Arc Entries .....................................43 159 3.3. Three-Dimensional Model ...................................44 160 3.3.1. Requirements .........................................44 161 3.3.2. Distinguished Name Convention ........................45 162 3.3.3. Root Arc Entries .....................................46 163 3.3.3.1. Lack of Root Arc Entries ........................46 164 3.4. Registrant Information ....................................48 165 3.4.1. Use of Collective or Virtual Attributes ..............48 166 3.4.2. Examples .............................................49 167 3.4.2.1. Combined Registration and Registrant 168 Entries .........................................49 169 3.4.2.2. Dedicated Registrant Entries ....................49 170 3.5. DUA Configuration .........................................51 171 3.5.1. Manual Configuration .................................51 172 3.5.2. Automatic Configuration ..............................51 173 3.5.2.1. Examples ........................................52 174 3.6. Spatial Orientation and Navigation ........................53 175 3.6.1. Client Capabilities ..................................53 176 3.6.1.1. Locating Individual Registrations ...............54 177 3.6.1.2. Traversing Adjacent or Ancestral 178 Registrations ...................................54 179 3.6.1.2.1. Use of the 'supArc' and 'topArc' 180 Attribute Types ............................55 181 3.6.1.2.2. Use of the 'subArc' Attribute Type .........56 182 3.6.1.2.2.1. Awareness of Subordinate 183 Registration Constraints ..............57 184 3.6.1.2.3. Use of Sibling Adjacency Attribute 185 Types ......................................57 186 3.7. DSA Resource Utilization and Administrative Costs .........59 187 3.7.1. Literal vs. Composite Values .........................59 188 3.7.2. Subtree Search Operations ............................60 189 4. IANA Considerations ............................................61 190 5. Security Considerations ........................................61 191 5.1. Modification Identity Obfuscation .........................62 192 5.2. Registrant Privacy ........................................62 193 6. References .....................................................62 194 6.1. Normative References ......................................62 195 6.2. Informative References ....................................63 196 Author's Address ..................................................64 198 1. Introduction 200 This specification describes a means for storing [X.660] registration 201 and OPTIONAL registrant data within an LDAP [RFC4510] implementation. 203 Some additional concepts and strategies are introduced that are not 204 explicitly defined in either [X.660] or [X.680]. These concepts are 205 meant to facilitate ease-of-implementation and sensible consumption. 207 1.1. Conventions 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 211 and "OPTIONAL" in this document are to be interpreted as described 212 in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 213 all capitals, as shown here. 215 1.2. Acronyms Used 217 This specification makes reference to several acronyms, each of which 218 are defined below. 220 DN Distinguished Name 221 RA Registration Authority 222 DIT Directory Information Tree 223 DSA Directory System Agent 224 DSI Directory Service Interface 225 DUA Directory User Agent (an LDAP client) 226 GUI Graphical User Interface 227 IRI Internationalized Resource Identifier 228 OID ASN.1 Object Identifier 229 PEN IANA Private Enterprise Number 230 RDN Relative Distinguished Name 231 TUI Textual User Interface 232 URI Uniform Resource Identifier 233 LDAP Lightweight Directory Access Protocol 234 ASN.1 Abstract Syntax Notation one 236 1.3. Intended Audience 238 This specification is intended for use by any entity or individual in 239 need of a means for storing and serving [X.660] data, in whole or in 240 part. The most likely candidates for use are RAs, whether internal to 241 an organization or public. 243 1.4. OIDs Allocated 245 This specification provides a dedicated registered OID branch for all 246 LDAP schema elements as defined in Section 2, as well as OIDs for two 247 (2) directory models defined in Section 3. 249 - 1.3.6.1.4.1.56521 (author root) 250 - 1.3.6.1.4.1.56521.101 (this specification) 251 - 1.3.6.1.4.1.56521.101.2 (schema) 252 - 1.3.6.1.4.1.56521.101.2.1 (attribute types) 253 - 1.3.6.1.4.1.56521.101.2.2 (object classes) 254 - 1.3.6.1.4.1.56521.101.3 (models) 255 - 1.3.6.1.4.1.56521.101.3.2 (twoDimensional) 256 - 1.3.6.1.4.1.56521.101.3.3 (threeDimensional) 258 1.5. Well-Known OIDs 260 This specification makes use of well-known OIDs defined by other 261 parties or institutions. These OIDs are mentioned for example 262 purposes and schema configuration only. 264 - 1.3 (Identified-Organization, per Section A.4.2 of [X.660]) 266 - 1.3.6 (dod, per Section 3.1 of [RFC1155]) 268 - 1.3.6.1 (Internet OID, per Section 3.1 of [RFC1155]) 270 - 1.3.6.1.4.1.1466.115.121.1.12 (Distinguished Name syntax and 271 matching rule, per Section 4.2.15 of [RFC4517]) 273 - 1.3.6.1.4.1.1466.115.121.1.24 (Generalized Time syntax, per 274 Section 3.3.13 of [RFC4517]) 276 - 1.3.6.1.4.1.1466.115.121.1.27 (Integer syntax, per Section 3.3.16 277 of [RFC4517]) 279 - 1.3.6.1.4.1.1466.115.121.1.38 (OID syntax, per Section 3.3.26 of 280 [RFC4517]) 282 - 1.3.6.1.4.1.1466.115.121.1.40 (Octet String syntax, per Section 283 3.3.25 of [RFC4517]) 285 2. Schema Definitions 287 This section discusses the particulars of the LDAP schema definitions 288 made available through this specification. 290 These schema definitions described in this section are provided using 291 LDAP description formats [RFC4512]. These elements are line-wrapped 292 and indented for readability. 294 2.1. Attribute Types 296 The following subsections detail LDAP attribute types created for use 297 within implementations of this specification. 299 Please note that a great many of these attribute type definitions 300 are sub types of attribute types defined in the following Standards 301 Documents, and as such are dependencies: 303 - [RFC2079] for URI support 304 - [RFC4519] for so-called "core" schema elements 305 - [RFC4524] for Cosine schema elements 307 If the nature of a particular directory implementation precludes the 308 use of subtyped attributes, this specification may not be practical 309 for adoption. 311 If a directory architect opts to extend certain definitions in this 312 Section for the purpose of Collective Attribute [RFC3671] support, 313 they are advised to adhere to the prescribed attribute type naming 314 prefix ("c-"), per Section 3 of [RFC3671]. 316 Very few attribute types are actually REQUIRED for registrations and 317 not all types will necessarily apply to every situation. Directory 318 architects are advised to carefully identify what types are needed, 319 and make interactive procedures and "best practices" available and 320 well-documented for all relevant consuming entities. 322 2.1.1. 'n' 324 The 'n' attribute type allows the assignment of an unsigned integer, 325 meant to represent the primary identifier, or NumberForm [X.680], of 326 the entry. 328 This attribute type plays a crucial role with regards to DN syntax 329 used in the three-dimensional directory model described in Section 330 3.3. 332 ( 1.3.6.1.4.1.56521.101.2.1.1 333 NAME ( 'n' 'numberForm' ) 334 DESC 'A single unsigned integer value assigned to 335 a registration to represent its primary integer 336 identifier' 337 EQUALITY integerMatch 338 SINGLE-VALUE 339 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 341 Examples: "56521", "0" 343 2.1.2. 'dotNotation' 345 The 'dotNotation' attribute type allows the assignment of an OID 346 value [X.680] in dot-delimited form to a registration entry. 348 ( 1.3.6.1.4.1.56521.101.2.1.2 349 NAME 'dotNotation' 350 DESC 'Dotted ASN.1 Object Identifier for a sub arc' 351 EQUALITY objectIdentifierMatch 352 SINGLE-VALUE 353 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 355 Examples: "1.3.6.1", "2.999" 357 2.1.3. 'iRI' 359 The 'iRI' attribute type allows the assignment of one or more IRI 360 values to an registration entry. 362 ( 1.3.6.1.4.1.56521.101.2.1.3 363 NAME 'iRI' 364 DESC 'Internationalized Resource Identifiers 365 for a registration entry' 366 EQUALITY octetStringMatch 367 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 369 Examples: "/ITU-T", "/ISO/Identified-Organization", "/ASN.1" 371 2.1.4. 'asn1Notation' 373 The 'asn1Notation' attribute type allows the assignment of an OID 374 in ASN.1 notation to a registration entry. 376 ( 1.3.6.1.4.1.56521.101.2.1.4 377 NAME 'asn1Notation' 378 DESC 'An ordered sequence of NameAndNumberForm 379 or NumberForm values, enclosed within curly 380 braces, that identify an OID' 381 SINGLE-VALUE 382 EQUALITY caseIgnoreMatch 383 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 385 Examples: "{itu-t(0)}", "{iso(1) identified-organization(3)}" 387 2.1.5. 'unicodeValue' 389 The 'unicodeValue' attribute type allows the assignment of one or 390 more Unicode-based primary identifiers (non-numeric) [X.660] to a 391 registration entry. 393 Although multi-value support is positive, cases in which any given 394 registration has multiple 'unicodeValue' values is extremely rare. 396 ( 1.3.6.1.4.1.56521.101.2.1.5 397 NAME 'unicodeValue' 398 DESC 'Primary non-numeric Unicode identifiers 399 for a registration' 400 EQUALITY octetStringMatch 401 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 403 Examples: "ITU-T", "Identified-Organization" 405 2.1.6. 'identifier' 407 The 'identifier' attribute type allows the assignment of a single 408 non-Unicode, non-numeric identifier [X.660], or NameForm [X.680], 409 to a registration entry. 411 The first character MUST be a lowercase letter and MUST NOT include 412 any white space. 414 The same value can be applied to the 'nameAndNumberForm' attribute 415 as a partial value. See Section 2.1.17 for more information on this 416 attribute type. 418 The attribute type 'name', as defined in Section 2.18 of [RFC4519], 419 is a super type of this attribute type. 421 ( 1.3.6.1.4.1.56521.101.2.1.6 422 NAME ( 'identifier' 'nameForm' ) 423 DESC 'The non-Unicode secondary identifier 424 for a registration' 425 SINGLE-VALUE 426 SUP name ) 428 Examples: "itu-t", "iso" 430 2.1.7. 'additionalIdentifier' 432 The 'additionalIdentifier' attribute type allows the assignment of 433 of one or more additional identifiers [X.660] in a registration. 435 The attribute type 'name', as defined in Section 2.18 of [RFC4519], 436 is a super type of this attribute type. 438 ( 1.3.6.1.4.1.56521.101.2.1.7 439 NAME 'additionalIdentifier' 440 DESC 'The non-Unicode additional identifiers 441 or nameForms for a registration' 442 SUP name ) 444 Examples: "enterprises", "ccitt" 446 2.1.8. 'registrationInformation' 448 The 'registrationInformation' attribute type allows the OPTIONAL 449 assignment of octet based values intended for extended information 450 relating to the registration in question. 452 ( 1.3.6.1.4.1.56521.101.2.1.8 453 NAME 'registrationInformation' 454 DESC 'Extended octet-based data for 455 a registration' 456 EQUALITY octetStringMatch 457 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{4096} ) 459 2.1.9. 'registrationURI' 461 The 'registrationURI' attribute type allows for the assignment of 462 one or more URI values, with optional labels, to a registration. 464 The attribute type 'labeledURI', as defined in [RFC2079], is a super 465 type of this attribute type. 467 ( 1.3.6.1.4.1.56521.101.2.1.9 468 NAME 'registrationURI' 469 DESC 'URI, with an optional label, leading to 470 further related subject matter information' 471 SUP labeledURI ) 473 Examples: "http://example.com Example", "http://example.com" 475 2.1.10. 'registrationCreated' 477 The 'registrationCreated' attribute type allows for the assignment 478 of a generalized timestamp indicating the date and time at which a 479 registration was, or will be, created or officiated. 481 ( 1.3.6.1.4.1.56521.101.2.1.10 482 NAME 'registrationCreated' 483 DESC 'Generalized timestamp for a 484 registration creation' 485 SINGLE-VALUE 486 EQUALITY generalizedTimeMatch 487 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 489 Examples: "19951231115959Z", "20130109033116Z" 491 2.1.11. 'registrationModified' 493 The 'registrationModified' attribute type allows for the assignment 494 of one or more generalized timestamp values indicating the dates 495 and times of all applied updates to a registration. 497 Whether multiple dates, or only most recent date, are stored is 498 entirely up to the directory architect(s) involved. 500 ( 1.3.6.1.4.1.56521.101.2.1.11 501 NAME 'registrationModified' 502 DESC 'Generalized timestamps for 503 registration modifications' 504 EQUALITY generalizedTimeMatch 505 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 507 Examples: "19951231115959Z", "20130109033116Z" 509 2.1.12. 'registrationRange' 511 The 'registrationRange' attribute type allows for the expression of 512 an OID allocation range, such as "100" to indicate 'up to 100', as 513 well as "-1" to indicate 'to infinity'. 515 The implied start of a range is the 'n' value of the registration 516 entry that bears this attribute type, and would not need to be set 517 explicitly. 519 The value of this attribute MUST always be greater-than and NOT equal 520 to the value of 'n' EXCEPT when "-1" is used. 522 For example, if a 'registrationRange' attribute value of '999' were 523 set for the OID '2.999.44', it MUST be interpreted as an entire range 524 of OIDs starting at '2.999.44' up to and including '2.999.999'. 526 Similarly, keeping with the same example above, if a value of "-1" 527 were used instead, this MUST be interpreted as an all-encompassing 528 OID range starting at '2.999.44' with absolutely no upper limit. 530 DUAs used to manage and allocate registration entries MUST always 531 perform preemptive searches for occurrences of this attribute type 532 prior to allocating any sibling registrations, so as to avoid illegal 533 overlaps. 535 ( 1.3.6.1.4.1.56521.101.2.1.12 536 NAME 'registrationRange' 537 DESC 'Numerical registration range expression' 538 EQUALITY integerMatch 539 SINGLE-VALUE 540 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 542 Examples: "-1", "1999", "1000000" 544 2.1.13. 'registrationStatus' 546 The 'registrationStatus' attribute type allows for the assignment 547 of status information, indicative of the current state of the 548 registration. Multiple values can be provided, however not all 549 combinations are meaningful. 551 In most cases, this is used to mark a registration as "obsolete", 552 "reserved", "private" or "deallocated", however values of "active" 553 or "in-force" are also applicable in some cases. 555 Absence of this attribute type within a given entry SHOULD be viewed 556 as an implied declaration of "active" or "in-force". 558 A value of "private" MAY be used a component in any access control 559 mechanics defined by the directory architect(s), but at the risk of 560 possible performance costs depending on implementation. In addition, 561 it is possible to leverage the 'discloseTo' attribute type defined 562 in Section 2.1.26. See Section 5 for more information. 564 Other possible values not listed here MAY be used, however they would 565 be wholly proprietary in nature. 567 ( 1.3.6.1.4.1.56521.101.2.1.13 568 NAME 'registrationStatus' 569 DESC 'Current status of a registration' 570 SINGLE-VALUE 571 SUP description ) 573 Examples: "obsolete", "deallocated", "reserved" 575 2.1.14. 'isLeafNode' 577 The 'isLeafNode' attribute type allows for the assignment of a single 578 Boolean value indicative of whether a registration can be a parent to 579 any subordinate registrations. 581 Absence of this attribute type SHOULD be interpreted as an implicit 582 FALSE value. 584 A value of FALSE indicates there are no restrictions regarding the 585 allocation or enumeration of any child entries. 587 A value of TRUE forbids the enumeration of all existing subordinate 588 registrations, as well as the creation of new registrations. 590 When TRUE, this attribute type implies a TRUE value for 'isFrozen', 591 per Section 2.1.15. See Section 3.6.1.2.2.1 for considerations on 592 various combinations of these attribute types. 594 This attribute type is NOT meant to serve in a security capacity. If 595 it is desirable to limit the enumeration of subordinate registrations 596 with privacy or security in mind, the attribute types 'discloseTo' 597 (Section 2.1.26) and/or 'registrationStatus' (Section 2.1.13) would 598 be more appropriate. 600 ( 1.3.6.1.4.1.56521.101.2.1.14 601 NAME 'isLeafNode' 602 DESC 'Whether a registration may allocate, 603 or allow the enumeration of, subordinate 604 registrations' 605 EQUALITY booleanMatch 606 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 608 Example: "TRUE", "FALSE", or UNDEFINED (implies "FALSE") 610 2.1.15. 'isFrozen' 612 The 'isFrozen' attribute type allows for the assignment of a single 613 Boolean value indicative of whether a registration can be a parent 614 to any further subordinate registrations beyond those that already 615 exist at present. 617 A value of TRUE indicates that the given registration MUST NOT have 618 any further children allocated, but that any entries that are already 619 allocated SHALL be enumerated. 621 A value of FALSE indicates there are no restrictions regarding the 622 allocation of any subsequent child entries, UNLESS a value of TRUE 623 is defined for the 'isLeafNode' attribute type, per Section 2.1.14. 624 Such a value supersedes any state of this attribute type. Please 625 see Section 3.6.1.2.2.1 for considerations on various combinations 626 of these attribute types. 628 ( 1.3.6.1.4.1.56521.101.2.1.15 629 NAME 'isFrozen' 630 DESC 'Whether a registration may allocate 631 any additional subordinate registrations' 632 EQUALITY booleanMatch 633 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 635 Example: "TRUE", "FALSE", or UNDEFINED (implies "FALSE") 637 2.1.16. 'stdNameForm' 639 The 'stdNameForm' attribute type allows for the assignment of one 640 or more Standardized NameForm values, per [X.660] and [X.680], to 641 a registration. 643 ( 1.3.6.1.4.1.56521.101.2.1.16 644 NAME 'stdNameForm' 645 DESC 'Standardized NameForm per X.680' 646 EQUALITY caseExactMatch 647 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 649 Example: "{itu-t}", "{0 0 d}" 651 2.1.17. 'nameAndNumberForm' 653 The 'nameAndNumberForm' attribute type allows for the assignment of 654 an [X.680] NameAndNumberForm value to a registration. 656 The value assigned to this attribute MUST manifest as a combination 657 of values of 'identifier' and/or (at a minimum) 'n'. 659 ( 1.3.6.1.4.1.56521.101.2.1.17 660 NAME 'nameAndNumberForm' 661 DESC 'NameAndNumberForm value, per X.680' 662 EQUALITY caseExactMatch 663 SINGLE-VALUE 664 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 666 Example: "private(4)", "itu-t(0)", "56521" 668 2.1.18. 'longArc' 670 The 'longArc' attribute type allows the assignment of one or more 671 so-called "Long Arc" well-known identifiers to a registration. 673 Per [X.660], entries that bear values of this attribute type MUST 674 reside below the root joint-iso-itu-t(2) registration. 676 ( 1.3.6.1.4.1.56521.101.2.1.18 677 NAME 'longArc' 678 DESC 'The well-known Long Arc names associated with, 679 and registered to, a Joint-ISO-ITU-T subordinate 680 registration' 681 EQUALITY octetStringMatch 682 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 684 Examples: "/Example", "/Ejemplo" 686 2.1.19. 'supArc' 688 The 'supArc' attribute type allows for the assignment of an LDAP DN 689 value to a registration, thereby identifying the DN of the immediate 690 superior (parent) registration entry. 692 For example, the OID registration for 2.1.4 (ecn) would possess a DN 693 value for this attribute type identifying its superior registration 694 entry as 2.1 (asn1). 696 This OPTIONAL attribute type is among the seven (7) spatial types 697 discussed in more detail in Section 3.6. 699 The attribute type 'distinguishedName', as defined in Section 2.7 of 700 [RFC4519], is a super type of this attribute type. This sub type is 701 MULTI-VALUED so as to support Collective Attribute extensibility 702 [RFC3671], but is intended only for the storage of a single DN value 703 per registration. 705 ( 1.3.6.1.4.1.56521.101.2.1.19 706 NAME 'supArc' 707 DESC 'LDAP Distinguished Name of the logically 708 superior immediate registration' 709 SUP distinguishedName ) 711 Example: "n=1,n=2,ou=OID,ou=X660,dc=example,dc=com" 713 2.1.20. 'topArc' 715 The 'topArc' attribute type allows for the assignment of an LDAP DN 716 value to a registration identifying the superior root registration. 718 For example, the OID registration for 2.1.4 (ecn) would possess a DN 719 value for this attribute type identifying its root registration entry 720 as 2 (Joint-ISO-ITU-T). 722 This OPTIONAL attribute type is among the seven (7) spatial types 723 discussed in more detail in Section 3.6. 725 The attribute type 'distinguishedName', as defined in Section 2.7 of 726 [RFC4519], is a super type of this attribute type. This sub type is 727 MULTI-VALUED so as to support Collective Attribute extensibility 728 [RFC3671], but is intended only for the storage of a single DN value 729 per registration. 731 ( 1.3.6.1.4.1.56521.101.2.1.20 732 NAME 'topArc' 733 DESC 'LDAP Distinguished Name of the absolute 734 superior root registration' 735 SUP distinguishedName ) 737 Example: "n=2,ou=OID,ou=X660,dc=example,dc=com" 739 2.1.21. 'subArc' 741 The 'subArc' attribute type allows for the assignment of one or 742 more LDAP DN values to a registration as a manifest of subordinate 743 registrations residing exactly one (1) logical level below. 745 This OPTIONAL attribute type is among the seven (7) spatial types 746 discussed in more detail in Section 3.6. 748 The attribute type 'distinguishedName', as defined in Section 2.7 of 749 [RFC4519], is a super type of this attribute type. 751 ( 1.3.6.1.4.1.56521.101.2.1.21 752 NAME 'subArc' 753 DESC 'LDAP Distinguished Name of a subordinate 754 registration residing below a given entry' 755 SUP distinguishedName ) 757 Example: "n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com" 759 2.1.22. 'leftArc' 761 The 'leftArc' attribute type allows for the assignment of an LDAP 762 DN value to a registration. The value SHOULD reference the nearest 763 lexically-antecedent (left-hand) sibling registration. 765 As an example, given a registration for the OID 2.6 (mhs), the DN 766 referencing the OID 2.5 (ds) is the lexically-nearest antecedent 767 sibling registration. 769 This OPTIONAL attribute type is among the seven (7) spatial types 770 discussed in more detail in Section 3.6. 772 The attribute type 'distinguishedName', as defined in Section 2.7 of 773 [RFC4519], is a super type of this attribute type. 775 ( 1.3.6.1.4.1.56521.101.2.1.22 776 NAME 'leftArc' 777 DESC 'LDAP Distinguished Name of the nearest 778 lexically antecedent sibling registration' 779 SINGLE-VALUE 780 SUP distinguishedName ) 782 Example: "n=5,n=2,ou=OID,ou=X660,dc=example,dc=com" 784 2.1.23. 'firstArc' 786 The 'firstArc' attribute type allows for the assignment of an LDAP 787 DN value to a registration. The value SHOULD reference the absolute 788 farthest antecedent sibling registration. 790 As an example, given a registration for the OID 2.6 (mhs), while 791 the DN referencing 2.0 (presentation) is the lexically-farthest 792 antecedent sibling registration. 794 This OPTIONAL attribute type is among the seven (7) spatial types 795 discussed in more detail in Section 3.6. 797 The attribute type 'distinguishedName', as defined in Section 2.7 of 798 [RFC4519], is a super type of this attribute type. This sub type is 799 MULTI-VALUED so as to support Collective Attribute extensibility 800 [RFC3671], but is intended only for the storage of a single DN value 801 per registration. 803 ( 1.3.6.1.4.1.56521.101.2.1.23 804 NAME 'firstArc' 805 DESC 'LDAP Distinguished Name of the farthest 806 lexically antecedent sibling registration' 807 SUP distinguishedName ) 809 Example: "n=0,n=2,ou=OID,ou=X660,dc=example,dc=com" 811 2.1.24. 'rightArc' 813 The 'rightArc' attribute type allows for the assignment of an LDAP 814 DN value to a registration. The value SHOULD reference the nearest 815 subsequent sibling registration. 817 As an example, given a registration for the OID 2.1 (asn1), the DN 818 referencing OID 2.2 (association-control) is the lexically-nearest 819 subsequent sibling registration. 821 This OPTIONAL attribute type is among the seven (7) spatial types 822 discussed in more detail in Section 3.6. 824 The attribute type 'distinguishedName', as defined in Section 2.7 of 825 [RFC4519], is a super type of this attribute type. 827 ( 1.3.6.1.4.1.56521.101.2.1.24 828 NAME 'rightArc' 829 DESC 'LDAP Distinguished Name of the nearest 830 lexically subsequent sibling registration' 831 SINGLE-VALUE 832 SUP distinguishedName ) 834 Example: "n=2,n=2,ou=OID,ou=X660,dc=example,dc=com" 836 2.1.25. 'finalArc' 838 The 'finalArc' attribute type allows for the assignment of an LDAP 839 DN value to a registration. The value SHOULD reference the absolute 840 farthest subsequent sibling registration. 842 As an example, given a registration for the OID 2.1 (asn1), the DN 843 referencing OID 2.999 (example) is lexically-farthest subsequent 844 sibling registration. 846 This OPTIONAL attribute type is among the seven (7) spatial types 847 discussed in more detail in Section 3.6. 849 The attribute type 'distinguishedName', as defined in Section 2.7 of 850 [RFC4519], is a super type of this attribute type. This sub type is 851 MULTI-VALUED so as to support Collective Attribute extensibility 852 [RFC3671], but is intended only for the storage of a single DN value 853 per registration. 855 ( 1.3.6.1.4.1.56521.101.2.1.25 856 NAME 'finalArc' 857 DESC 'LDAP Distinguished Name of the farthest 858 lexically subsequent sibling registration' 859 SUP distinguishedName ) 861 Example: "n=999,n=2,ou=OID,ou=X660,dc=example,dc=com" 863 2.1.26. 'discloseTo' 865 The 'discloseTo' attribute type allows for the assignment of one or 866 more LDAP DN values to a registration, each of which reference an 867 identity that is authorized to access the entry's information in 868 read-only fashion. This MAY cover any depth of subordinate entry 869 disclosures as seen fit by the directory architect(s). 871 Identities referenced through use of this attribute type MAY be 872 single user entries, a 'groupOfNames'-based entry, per Section 873 3.5 of [RFC4519] or a current authority or sponsorship registrant. 875 Write-based access SHOULD NOT be governed by this attribute type, as 876 that is an intended function of the current registration authority. 878 The attribute type 'distinguishedName', as defined in Section 2.7 of 879 [RFC4519], is a super type of this attribute type. 881 ( 1.3.6.1.4.1.56521.101.2.1.26 882 NAME 'discloseTo' 883 DESC 'LDAP Distinguished Names of entries which 884 are granted access to a given registration 885 and its immediate children' 886 SUP distinguishedName ) 888 Example: "cn=ClearanceLevel4,ou=Groups,dc=example,dc=com" 890 2.1.27. 'registrantID' 892 The 'registrantID' attribute type is intended to allow for singular 893 assignment of a UUID, GUID or some other auto-generated value to a 894 registrant entry. When used, this value would act as an absolute 895 identifier for registration entries that may change in the future. 897 In larger, more complete implementations of this specification, it 898 is RECOMMENDED that this attribute type be the primary identifier 899 (or, RDN) for registrant entries. This allows for an absolute and 900 unambiguous reference to any registration entry by DN in terms of 901 authority and/or sponsorship. 903 ( 1.3.6.1.4.1.56521.101.2.1.27 904 NAME 'registrantID' 905 DESC 'GUID or UUID assigned to a past 906 or present registration authority 907 or sponsor entry' 908 SINGLE-VALUE 909 EQUALITY octetStringMatch 910 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 912 Examples: "rfc4519", "69118e61-cc02-4c50-bde7-5bdaf4e973e4" 914 2.1.28. 'currentAuthority' 916 The 'currentAuthority' attribute type allows for the assignment 917 of one or more DN values to a registration. 919 The value(s) of this attribute type are meant to refer to distinct 920 entries that contain current registrant authority information for 921 the registration to which it is linked. 923 This attribute type is only required if registrant information is 924 not stored within a given registration directly. 926 The attribute type 'distinguishedName', as defined in Section 2.7 of 927 [RFC4519], is a super type of this attribute type. 929 ( 1.3.6.1.4.1.56521.101.2.1.28 930 NAME 'currentAuthority' 931 DESC 'LDAP Distinguished Name of an entry 932 bearing current registration authority 933 information' 934 SUP distinguishedName ) 936 Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com" 938 2.1.29. 'currentAuthorityStartTimestamp' 940 The 'currentAuthorityStartTimestamp' attribute type allows for the 941 assignment of a generalized timestamp value to a current registration 942 authority, indicative of the date and time at which the current 943 registration authority was, or will be, officiated. 945 ( 1.3.6.1.4.1.56521.101.2.1.29 946 NAME 'currentAuthorityStartTimestamp' 947 DESC 'Generalized time stamp indicating the date 948 and time at which current authority commenced' 949 EQUALITY generalizedTimeMatch 950 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 952 Example: "19951231115959Z" 954 2.1.30. 'currentAuthorityCommonName' 956 The 'currentAuthorityCommonName' attribute type allows for the 957 assignment of a common name to a current authority entry. 959 The attribute type 'cn', as defined in Section 2.3 of [RFC4519], 960 is a super type of this attribute type. 962 ( 1.3.6.1.4.1.56521.101.2.1.30 963 NAME 'currentAuthorityCommonName' 964 DESC 'Common Name assigned to a current 965 registration authority entry' 966 SINGLE-VALUE 967 SUP cn ) 969 Example: "Jesse Coretta", "Jane Smith" 971 2.1.31. 'currentAuthorityCountryCode' 973 The 'currentAuthorityCountryCode' attribute type allows for the 974 assignment of a country code to a current authority entry. 976 The attribute type 'c', as defined in Section 2.2 of [RFC4519], is 977 a super type of this attribute type. 979 ( 1.3.6.1.4.1.56521.101.2.1.31 980 NAME 'currentAuthorityCountryCode' 981 DESC 'Country Code assigned to a current 982 registration authority entry' 983 SINGLE-VALUE 984 SUP c ) 986 Examples: "US", "CA" 988 2.1.32. 'currentAuthorityCountryName' 990 The 'currentAuthorityCountryName' attribute type allows for the 991 assignment of a country name to a current authority entry. 993 The attribute type 'co', as defined in Section 2.4 of [RFC4519], 994 is a super type of this attribute type. 996 ( 1.3.6.1.4.1.56521.101.2.1.32 997 NAME 'currentAuthorityCountryName' 998 DESC 'Country name assigned to a current 999 registration authority entry' 1000 SINGLE-VALUE 1001 SUP co ) 1003 Examples: "United States", "Canada" 1005 2.1.33. 'currentAuthorityEmail' 1007 The 'currentAuthorityEmail' attribute type allows for the assignment 1008 of an email address to the current registration authority entry. 1010 The attribute type 'mail', as defined in Section 2.16 of [RFC4524], 1011 is a super type of this attribute type. 1013 ( 1.3.6.1.4.1.56521.101.2.1.33 1014 NAME 'currentAuthorityEmail' 1015 DESC 'Email address assigned to a current 1016 registration authority entry' 1017 SINGLE-VALUE 1018 SUP mail ) 1020 Example: "jesse.coretta@icloud.com" 1022 2.1.34. 'currentAuthorityFax' 1024 The 'currentAuthorityFax' attribute type allows for the assignment 1025 of a facsimile telephone number to a current authority entry. 1027 The attribute type 'facsimileTelephoneNumber', as defined in Section 1028 2.10 of [RFC4519], is a super type of this attribute type. 1030 ( 1.3.6.1.4.1.56521.101.2.1.34 1031 NAME 'currentAuthorityFax' 1032 DESC 'Facsimile telephone number assigned to 1033 a current registration authority entry' 1034 SINGLE-VALUE 1035 SUP facsimileTelephoneNumber ) 1037 Example: "+11234567890" 1039 2.1.35. 'currentAuthorityLocality' 1041 The 'currentAuthorityLocality' attribute type allows for the 1042 assignment of a locality name to a current authority entry. 1044 The attribute type 'l', as defined in Section 2.16 of [RFC4519], 1045 is a super type of this attribute type. 1047 ( 1.3.6.1.4.1.56521.101.2.1.35 1048 NAME 'currentAuthorityLocality' 1049 DESC 'Locality name assigned to a current 1050 registration authority entry' 1051 SINGLE-VALUE 1052 SUP l ) 1054 Example: "Palm Springs", "Anna Maria Island" 1056 2.1.36. 'currentAuthorityMobile' 1058 The 'currentAuthorityMobile' attribute type allows for the 1059 assignment of a mobile telephone number to a current registration 1060 authoritative entry. 1062 The attribute type 'mobile', as defined in Section 2.18 of [RFC4524], 1063 is a super type of this attribute type. 1065 ( 1.3.6.1.4.1.56521.101.2.1.36 1066 NAME 'currentAuthorityMobile' 1067 DESC 'Mobile telephone number assigned to a 1068 current registration authority entry' 1069 SINGLE-VALUE 1070 SUP mobile ) 1072 Example: "+11234567890" 1074 2.1.37. 'currentAuthorityOrg' 1076 The 'currentAuthorityOrg' attribute type allows for the assignment 1077 of an organization name to a current authority entry. 1079 The attribute type 'o', as defined in Section 2.19 of [RFC4519], is 1080 a super type of this attribute type. 1082 ( 1.3.6.1.4.1.56521.101.2.1.37 1083 NAME 'currentAuthorityOrg' 1084 DESC 'Organization name assigned to a current 1085 registration authority entry' 1086 SINGLE-VALUE 1087 SUP o ) 1089 Example: "Acme, Co." 1091 2.1.38. 'currentAuthorityPOBox' 1093 The 'currentAuthorityPOBox' attribute type allows for the 1094 assignment of a post office box number to a current registration 1095 authority entry. 1097 The attribute type 'postOfficeBox', as defined in Section 2.25 of 1098 [RFC4519], is a super type of this attribute type. 1100 ( 1.3.6.1.4.1.56521.101.2.1.38 1101 NAME 'currentAuthorityPOBox' 1102 DESC 'Post office box number assigned to a 1103 current registration authority entry' 1104 SINGLE-VALUE 1105 SUP postOfficeBox ) 1107 Examples: "555", "475" 1109 2.1.39. 'currentAuthorityPostalAddress' 1111 The 'currentAuthorityPostalAddress' attribute type allows for the 1112 assignment of a complete postal address to a current registration 1113 authority entry. This single attribute may be used instead of other 1114 individual address component attribute types, but will require field 1115 parsing on the client side. 1117 The attribute type 'postalAddress', as defined in Section 2.23 of 1118 [RFC4519], is a super type of this attribute type. 1120 ( 1.3.6.1.4.1.56521.101.2.1.39 1121 NAME 'currentAuthorityPostalAddress' 1122 DESC 'Full postal address assigned to a current 1123 registration authority entry' 1124 SINGLE-VALUE 1125 SUP postalAddress ) 1127 Example: "1 Fake St$Anytown$CA$12345$US" 1129 2.1.40. 'currentAuthorityPostalCode' 1131 The 'currentAuthorityPostalCode' attribute type allows for the 1132 assignment of a postal code to a current authority entry. 1134 The attribute type 'postalCode', as defined in Section 2.23 of 1135 [RFC4519], is a super type of this attribute type. 1137 ( 1.3.6.1.4.1.56521.101.2.1.40 1138 NAME 'currentAuthorityPostalCode' 1139 DESC 'Postal code assigned to a current 1140 registration authority entry' 1141 SINGLE-VALUE 1142 SUP postalCode ) 1144 Examples: "92262", "34216" 1146 2.1.41. 'currentAuthorityState' 1148 The 'currentAuthorityState' attribute type allows for the 1149 assignment of a state or province name to a current registration 1150 authority entry. 1152 The attribute type 'st', as defined in Section 2.33 of [RFC4519], 1153 is a super type of this attribute type. 1155 ( 1.3.6.1.4.1.56521.101.2.1.41 1156 NAME 'currentAuthorityState' 1157 DESC 'State or province name assigned to a current 1158 registration authority entry' 1159 SINGLE-VALUE 1160 SUP st ) 1162 Examples: "California", "North Dakota" 1164 2.1.42. 'currentAuthorityStreet' 1166 The 'currentAuthorityStreet' attribute type allows for the 1167 assignment of a street name and number to a current registration 1168 authority entry. 1170 The attribute type 'street', as defined in Section 2.34 of [RFC4519], 1171 is a super type of this attribute type. 1173 ( 1.3.6.1.4.1.56521.101.2.1.42 1174 NAME 'currentAuthorityStreet' 1175 DESC 'Street name and number assigned to a current 1176 registration authority entry' 1177 SINGLE-VALUE 1178 SUP street ) 1180 Example: "1 Fake Street" 1182 2.1.43. 'currentAuthorityTelephone' 1184 The 'currentAuthorityTelephone' attribute type allows for the 1185 assignment of a telephone number to a current authority entry. 1187 The attribute type 'telephoneNumber', as defined in Section 2.35 of 1188 [RFC4519], is a super type of this attribute type. 1190 ( 1.3.6.1.4.1.56521.101.2.1.43 1191 NAME 'currentAuthorityTelephone' 1192 DESC 'Telephone number assigned to a current 1193 registration authority entry' 1194 SINGLE-VALUE 1195 SUP telephoneNumber ) 1197 Example: "+11234567890" 1199 2.1.44. 'currentAuthorityTitle' 1201 The 'currentAuthorityTitle' attribute type allows for the 1202 assignment of an official or professional title to a current 1203 authority entry. 1205 The attribute type 'title', as defined in Section 2.38 of 1206 [RFC4519], is a super type of this attribute type. 1208 ( 1.3.6.1.4.1.56521.101.2.1.44 1209 NAME 'currentAuthorityTitle' 1210 DESC 'Title assigned to a current 1211 registration authority entry' 1212 SINGLE-VALUE 1213 SUP title ) 1215 Example: "Chief Engineer" 1217 2.1.45. 'currentAuthorityURI' 1219 The 'currentAuthorityURI' attribute type allows for the 1220 assignment of one or more URI values, with optional labels, 1221 to a current authority entry. 1223 The attribute type 'labeledURI', as defined in [RFC2079], is 1224 a super type of this attribute type. 1226 ( 1.3.6.1.4.1.56521.101.2.1.45 1227 NAME 'currentAuthorityURI' 1228 DESC 'URI, with an optional label, leading 1229 to a resource related to a current 1230 registration authority' 1231 SUP labeledURI ) 1233 Example: "http://example.com Example", "http://example.com" 1235 2.1.46. 'firstAuthority' 1237 The 'firstAuthority' attribute type allows for the assignment 1238 of one or more DN values to an registration entry. 1240 The value(s) of this attribute type are meant to refer to distinct 1241 entries that contain previous authority information. 1243 This attribute type is only required if registrant information is 1244 not stored within a given registration directly. 1246 The attribute type 'distinguishedName', as defined in Section 2.7 of 1247 [RFC4519], is a super type of this attribute type. 1249 ( 1.3.6.1.4.1.56521.101.2.1.46 1250 NAME 'firstAuthority' 1251 DESC 'LDAP Distinguished Name of an entry 1252 bearing previous registration authority 1253 information' 1254 SUP distinguishedName ) 1256 Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com" 1258 2.1.47. 'firstAuthorityStartTimestamp' 1260 The 'firstAuthorityStartTimestamp' attribute type allows for 1261 the assignment of a generalized timestamp value to a previous 1262 registration authority, indicative of the date and time at which 1263 the previous registration authority was, or will be, officiated. 1265 ( 1.3.6.1.4.1.56521.101.2.1.47 1266 NAME 'firstAuthorityStartTimestamp' 1267 DESC 'Generalized timestamp indicating the date and 1268 time at which a previous registration authority 1269 commenced' 1270 EQUALITY generalizedTimeMatch 1271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1273 Example: "20130105135904Z" 1275 2.1.48. 'firstAuthorityEndTimestamp' 1277 The 'firstAuthorityEndTimestamp' attribute type allows for 1278 the assignment of a generalized timestamp value to a previous 1279 registration authority, indicative of the date and time at which 1280 an entity's authoritative role was, or will be, terminated. 1282 ( 1.3.6.1.4.1.56521.101.2.1.48 1283 NAME 'firstAuthorityEndTimestamp' 1284 DESC 'Generalized timestamp indicating the date and 1285 time at which a previous registration authority 1286 terminated' 1287 EQUALITY generalizedTimeMatch 1288 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1290 Example: "20170528110555Z" 1292 2.1.49. 'firstAuthorityCommonName' 1294 The 'firstAuthorityCommonName' attribute type allows for the 1295 assignment of a common name to a previous registration authority 1296 entry. 1298 The attribute type 'cn', as defined in Section 2.3 of [RFC4519], 1299 is a super type of this attribute type. 1301 ( 1.3.6.1.4.1.56521.101.2.1.49 1302 NAME 'firstAuthorityCommonName' 1303 DESC 'Common Name assigned to a previous 1304 registration authority entry' 1305 SINGLE-VALUE 1306 SUP cn ) 1308 Examples: "Jesse Coretta", "Jane Smith" 1310 2.1.50. 'firstAuthorityCountryCode' 1312 The 'firstAuthorityCountryCode' attribute type allows for the 1313 assignment of a country code to a previous registration authority 1314 entry. 1316 The attribute type 'c', as defined in Section 2.2 of [RFC4519], 1317 is a super type of this attribute type. 1319 ( 1.3.6.1.4.1.56521.101.2.1.50 1320 NAME 'firstAuthorityCountryCode' 1321 DESC 'Country Code assigned to a previous 1322 registration authority entry' 1323 SINGLE-VALUE 1324 SUP c ) 1326 Examples: "US", "CA" 1328 2.1.51. 'firstAuthorityCountryName' 1330 The 'firstAuthorityCountryName' attribute type allows for the 1331 assignment of a country name to a previous registration authority 1332 entry. 1334 The attribute type 'co', as defined in Section 2.4 of [RFC4519], 1335 is a super type of this attribute type. 1337 ( 1.3.6.1.4.1.56521.101.2.1.51 1338 NAME 'firstAuthorityCountryName' 1339 DESC 'Country name assigned to a previous 1340 registration authority entry' 1341 SINGLE-VALUE 1342 SUP co ) 1344 Examples: "United States", "Canada" 1346 2.1.52. 'firstAuthorityEmail' 1348 The 'firstAuthorityEmail' attribute type allows for the assignment 1349 of an email address to a previous registration authority entry. 1351 The attribute type 'mail', as defined in Section 2.16 of [RFC4524], 1352 is a super type of this attribute type. 1354 ( 1.3.6.1.4.1.56521.101.2.1.52 1355 NAME 'firstAuthorityEmail' 1356 DESC 'Email address assigned to a previous 1357 registration authority entry' 1358 SINGLE-VALUE 1359 SUP mail ) 1361 Example: "jesse.coretta@icloud.com" 1363 2.1.53. 'firstAuthorityFax' 1365 The 'firstAuthorityFax' attribute type allows for the assignment of 1366 a facsimile telephone number to a previous registration authority 1367 entry. 1369 The attribute type 'facsimileTelephoneNumber', as defined in Section 1370 2.10 of [RFC4519], is a super type of this attribute type. 1372 ( 1.3.6.1.4.1.56521.101.2.1.53 1373 NAME 'firstAuthorityFax' 1374 DESC 'Facsimile telephone number assigned to 1375 a previous registration authority entry' 1376 SINGLE-VALUE 1377 SUP facsimileTelephoneNumber ) 1379 Example: "+11234567890" 1381 2.1.54. 'firstAuthorityLocality' 1383 The 'firstAuthorityLocality' attribute type allows for the 1384 assignment of a locality name to a previous registration authority 1385 entry. 1387 The attribute type 'l', as defined in Section 2.16 of [RFC4519], 1388 is a super type of this attribute type. 1390 ( 1.3.6.1.4.1.56521.101.2.1.54 1391 NAME 'firstAuthorityLocality' 1392 DESC 'Locality name assigned to a previous 1393 registration authority entry' 1394 SINGLE-VALUE 1395 SUP l ) 1397 Examples: "Palm Springs", "Anna Maria Island" 1399 2.1.55. 'firstAuthorityMobile' 1401 The 'firstAuthorityMobile' attribute type allows for the assignment 1402 of a mobile telephone number to a previous registration authoritative 1403 entry. 1405 The attribute type 'mobile', as defined in Section 2.18 of [RFC4524], 1406 is a super type of this attribute type. 1408 ( 1.3.6.1.4.1.56521.101.2.1.55 1409 NAME 'firstAuthorityMobile' 1410 DESC 'Mobile telephone number assigned to a 1411 previous registration authority entry' 1412 SINGLE-VALUE 1413 SUP mobile ) 1415 Example: "+11234567890" 1417 2.1.56. 'firstAuthorityOrg' 1419 The 'firstAuthorityOrg' attribute type allows for the assignment 1420 of an organization name to a previous registration authority entry. 1422 The attribute type 'o', as defined in Section 2.19 of [RFC4519], is 1423 a super type of this attribute type. 1425 ( 1.3.6.1.4.1.56521.101.2.1.56 1426 NAME 'firstAuthorityOrg' 1427 DESC 'Organization name assigned to a previous 1428 registration authority entry' 1429 SINGLE-VALUE 1430 SUP o ) 1432 Example: "Acme, Co." 1434 2.1.57. 'firstAuthorityPOBox' 1436 The 'firstAuthorityPOBox' attribute type allows for the assignment 1437 of a post office box number to a previous registration authority 1438 entry. 1440 The attribute type 'postOfficeBox', as defined in Section 2.25 of 1441 [RFC4519], is a super type of this attribute type. 1443 ( 1.3.6.1.4.1.56521.101.2.1.57 1444 NAME 'firstAuthorityPOBox' 1445 DESC 'Post office box number assigned to a 1446 previous registration authority entry' 1447 SINGLE-VALUE 1448 SUP postOfficeBox ) 1450 Examples: "555", "475" 1452 2.1.58. 'firstAuthorityPostalAddress' 1454 The 'firstAuthorityPostalAddress' attribute type allows for the 1455 assignment of a complete postal address to a previous registration 1456 authority entry. This single attribute may be used instead of other 1457 individual address component attribute types, but will require field 1458 parsing on the client side. 1460 The attribute type 'postalAddress', as defined in Section 2.23 of 1461 [RFC4519], is a super type of this attribute type. 1463 ( 1.3.6.1.4.1.56521.101.2.1.58 1464 NAME 'firstAuthorityPostalAddress' 1465 DESC 'Full postal address assigned to a previous 1466 registration authority entry' 1467 SINGLE-VALUE 1468 SUP postalAddress ) 1470 Example: "1 Fake St$Anytown$CA$12345$US" 1472 2.1.59. 'firstAuthorityPostalCode' 1474 The 'firstAuthorityPostalCode' attribute type allows for the 1475 assignment of a postal code to a previous registration authority 1476 entry. 1478 The attribute type 'postalCode', as defined in Section 2.23 of 1479 [RFC4519], is a super type of this attribute type. 1481 ( 1.3.6.1.4.1.56521.101.2.1.59 1482 NAME 'firstAuthorityPostalCode' 1483 DESC 'Postal code assigned to a previous 1484 registration authority entry' 1485 SINGLE-VALUE 1486 SUP postalCode ) 1488 Examples: "92262", "34216" 1490 2.1.60. 'firstAuthorityState' 1492 The 'firstAuthorityState' attribute type allows for the assignment 1493 of a state or province name to a previous registration authority 1494 entry. 1496 The attribute type 'st', as defined in Section 2.33 of [RFC4519], is 1497 a super type of this attribute type. 1499 ( 1.3.6.1.4.1.56521.101.2.1.60 1500 NAME 'firstAuthorityState' 1501 DESC 'State or province name assigned to a previous 1502 registration authority entry' 1503 SINGLE-VALUE 1504 SUP st ) 1506 Examples: "California", "North Dakota" 1508 2.1.61. 'firstAuthorityStreet' 1510 The 'firstAuthorityStreet' attribute type allows for the 1511 assignment of a street name and number to a previous registration 1512 authority entry. 1514 The attribute type 'street', as defined in Section 2.34 of [RFC4519], 1515 is a super type of this attribute type. 1517 ( 1.3.6.1.4.1.56521.101.2.1.61 1518 NAME 'firstAuthorityStreet' 1519 DESC 'Street name and number assigned to a previous 1520 registration authority entry' 1521 SINGLE-VALUE 1522 SUP street ) 1524 Example: "1 Fake Street" 1526 2.1.62. 'firstAuthorityTelephone' 1528 The 'firstAuthorityTelephone' attribute type allows for the 1529 assignment of a telephone number to a previous registration 1530 authority entry. 1532 The attribute type 'telephoneNumber', as defined in Section 2.35 of 1533 [RFC4519], is a super type of this attribute type. 1535 ( 1.3.6.1.4.1.56521.101.2.1.62 1536 NAME 'firstAuthorityTelephone' 1537 DESC 'Telephone number assigned to a previous 1538 registration authority entry' 1539 SINGLE-VALUE 1540 SUP telephoneNumber ) 1542 Example: "+11234567890" 1544 2.1.63. 'firstAuthorityTitle' 1546 The 'firstAuthorityTitle' attribute type allows for the assignment 1547 of an official or professional title to a previous registration 1548 authority entry. 1550 The attribute type 'title', as defined in Section 2.38 of [RFC4519], 1551 is a super type of this attribute type. 1553 ( 1.3.6.1.4.1.56521.101.2.1.63 1554 NAME 'firstAuthorityTitle' 1555 DESC 'Title assigned to a previous 1556 registration authority entry' 1557 SINGLE-VALUE 1558 SUP title ) 1560 Example: "Chief Engineer" 1562 2.1.64. 'firstAuthorityURI' 1564 The 'firstAuthorityURI' attribute type allows for the assignment 1565 of one or more URI values, with optional labels, to a previous 1566 registration authority entry. 1568 The attribute type 'labeledURI', as defined in [RFC2079], is a super 1569 type of this attribute type. 1571 ( 1.3.6.1.4.1.56521.101.2.1.64 1572 NAME 'firstAuthorityURI' 1573 DESC 'URI, with an optional label, leading 1574 to a resource related to a previous 1575 registration authority' 1576 SUP labeledURI ) 1578 Examples: "http://example.com Example", "http://example.com" 1580 2.1.65. 'sponsor' 1582 The 'sponsor' attribute type allows for the assignment of one or 1583 more DN values to a registration. 1585 The value(s) of this attribute type are meant to refer to distinct 1586 entries that contains sponsorship-related information for a given 1587 registration. 1589 This attribute type is only required if such information is not 1590 stored within a given registration directly. 1592 The attribute type 'distinguishedName', as defined in Section 2.7 of 1593 [RFC4519], is a super type of this attribute type. 1595 ( 1.3.6.1.4.1.56521.101.2.1.65 1596 NAME 'sponsor' 1597 DESC 'LDAP Distinguished Name of an entry 1598 bearing sponsorship information' 1599 SUP distinguishedName ) 1601 Example: "registrantID=XYZ,ou=Registrants,ou=X660,dc=example,dc=com" 1603 2.1.66. 'sponsorStartTimestamp' 1605 The 'sponsorStartTimestamp' attribute type allows for the assignment 1606 of a generalized timestamp value to a sponsor entry, indicative of 1607 the date and time at which sponsorship was, or will be, officiated. 1609 ( 1.3.6.1.4.1.56521.101.2.1.66 1610 NAME 'sponsorStartTimestamp' 1611 DESC 'Generalized timestamp indicating the date 1612 and time sponsorship commenced' 1613 EQUALITY generalizedTimeMatch 1614 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1616 Example: "20130105135904Z" 1618 2.1.67. 'sponsorEndTimestamp' 1620 The 'sponsorEndTimestamp' attribute type allows for the assignment 1621 of a generalized timestamp value to a sponsor entry, indicative of 1622 the date and time at which sponsorship was, or will be, terminated. 1624 ( 1.3.6.1.4.1.56521.101.2.1.67 1625 NAME 'sponsorEndTimestamp' 1626 DESC 'Generalized timestamp indicating the date 1627 and time sponsorship terminated' 1628 EQUALITY generalizedTimeMatch 1629 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1631 Example: "20170528110555Z" 1633 2.1.68. 'sponsorCommonName' 1635 The 'sponsorCommonName' attribute type allows for the assignment 1636 of a common name to a sponsor entry. 1638 The attribute type 'cn', as defined in Section 2.3 of [RFC4519], 1639 is a super type of this attribute type. 1641 ( 1.3.6.1.4.1.56521.101.2.1.68 1642 NAME 'sponsorCommonName' 1643 DESC 'Common Name of a sponsor entry' 1644 SINGLE-VALUE 1645 SUP cn ) 1647 Example: "Jane Sponsor" 1649 2.1.69. 'sponsorCountryCode' 1651 The 'sponsorCountryCode' attribute type allows for the assignment of 1652 a two-letter country code to a sponsor entry. 1654 The attribute type 'c', as defined in Section 2.2 of [RFC4519], is a 1655 super type of this attribute type. 1657 ( 1.3.6.1.4.1.56521.101.2.1.69 1658 NAME 'sponsorCountryCode' 1659 DESC 'Country code for a sponsor entry' 1660 SINGLE-VALUE 1661 SUP c ) 1663 Examples: "US", "CA" 1665 2.1.70. 'sponsorCountryName' 1667 The 'sponsorCountryName' attribute type allows the assignment of a 1668 country name to a sponsor entry. 1670 The attribute type 'co', as defined in Section 2.4 of [RFC4524], is a 1671 super type of this attribute type. 1673 ( 1.3.6.1.4.1.56521.101.2.1.70 1674 NAME 'sponsorCountryName' 1675 DESC 'Country name for a sponsor entry' 1676 SINGLE-VALUE 1677 SUP co ) 1679 Examples: "United States", "Canada" 1681 2.1.71. 'sponsorEmail' 1683 The 'sponsorEmail' attribute type allows for the assignment of an 1684 email address to a sponsor entry. 1686 The attribute type 'mail', as defined in Section 2.16 of [RFC4524], 1687 is a super type of this attribute type. 1689 ( 1.3.6.1.4.1.56521.101.2.1.71 1690 NAME 'sponsorEmail' 1691 DESC 'Email address for a sponsor entry' 1692 SINGLE-VALUE 1693 SUP mail ) 1695 Example: "sponsor@example.com" 1697 2.1.72. 'sponsorFax' 1699 The 'sponsorFax' attribute type allows for the assignment of a 1700 facsimile telephone number to a sponsor entry. 1702 The attribute type 'facsimileTelephoneNumber', as defined in Section 1703 2.10 of [RFC4519], is a super type of this attribute type. 1705 ( 1.3.6.1.4.1.56521.101.2.1.72 1706 NAME 'sponsorFax' 1707 DESC 'Facsimile telephone number for a sponsor entry' 1708 SINGLE-VALUE 1709 SUP facsimileTelephoneNumber ) 1711 Example: "+11234567890" 1713 2.1.73. 'sponsorLocality' 1715 The 'sponsorLocality' attribute type allows for the assignment 1716 of a locality name to a sponsor entry. 1718 The attribute type 'l', as defined in Section 2.16 of [RFC4519], is 1719 a super type of this attribute type. 1721 ( 1.3.6.1.4.1.56521.101.2.1.73 1722 NAME 'sponsorLocality' 1723 DESC 'Locality name for a sponsor entry' 1724 SINGLE-VALUE 1725 SUP l ) 1727 Examples: "Palm Springs", "Anna Maria Island" 1729 2.1.74. 'sponsorMobile' 1731 The 'sponsorMobile' attribute type allows for the assignment of 1732 a mobile telephone number to a sponsor entry. 1734 The attribute type 'mobile', as defined in Section 2.18 of 1735 [RFC4524], is a super type of this attribute type. 1737 ( 1.3.6.1.4.1.56521.101.2.1.74 1738 NAME 'sponsorMobile' 1739 DESC 'Mobile telephone number for a sponsor entry' 1740 SINGLE-VALUE 1741 SUP mobile ) 1743 Example: "+11234567890" 1745 2.1.75. 'sponsorOrg' 1747 The 'sponsorOrg' attribute type allows for the assignment of an 1748 organization name to a sponsor entry. 1750 The attribute type 'o', as defined in Section 2.19 of [RFC4519], 1751 is a super type of this attribute type. 1753 ( 1.3.6.1.4.1.56521.101.2.1.75 1754 NAME 'sponsorOrg' 1755 DESC 'Organization name for a sponsor entry' 1756 SINGLE-VALUE 1757 SUP o ) 1759 Example: "Sponsor, Co." 1761 2.1.76. 'sponsorPOBox' 1763 The 'sponsorPOBox' attribute type allows for the assignment of a 1764 post office box number to a sponsor entry. 1766 The attribute type 'postOfficeBox', as defined in Section 2.25 of 1767 [RFC4519], is a super type of this attribute type. 1769 ( 1.3.6.1.4.1.56521.101.2.1.76 1770 NAME 'sponsorPOBox' 1771 DESC 'Post office box number for a sponsor entry' 1772 SINGLE-VALUE 1773 SUP postOfficeBox ) 1775 Examples: "555", "475" 1777 2.1.77. 'sponsorPostalAddress' 1779 The 'sponsorPostalAddress' attribute type allows for the assignment 1780 of a complete postal address sponsor entry. This single attribute 1781 may be used instead of other individual address component attribute 1782 types, but will require field parsing on the client side. 1784 The attribute type 'postalAddress', as defined in Section 2.23 of 1785 [RFC4519], is a super type of this attribute type. 1787 ( 1.3.6.1.4.1.56521.101.2.1.77 1788 NAME 'sponsorPostalAddress' 1789 DESC 'Full postal address for a sponsor entry' 1790 SINGLE-VALUE 1791 SUP postalAddress ) 1793 Example: "1 Fake St$Anytown$CA$12345$US" 1795 2.1.78. 'sponsorPostalCode' 1797 The 'sponsorPostalCode' attribute type allows for a postal code 1798 to be assigned to a sponsor entry. 1800 The attribute type 'postalCode', as defined in Section 2.23 of 1801 [RFC4519], is a super type of this attribute type. 1803 ( 1.3.6.1.4.1.56521.101.2.1.78 1804 NAME 'sponsorPostalCode' 1805 DESC 'Postal code for a sponsor entry' 1806 SINGLE-VALUE 1807 SUP postalCode ) 1809 Example: "92262", "34216" 1811 2.1.79. 'sponsorState' 1813 The 'sponsorState' attribute type allows for the assignment of a 1814 state or province name to a sponsor entry. 1816 The attribute type 'st', as defined in Section 2.33 of [RFC4519], 1817 is a super type of this attribute type. 1819 ( 1.3.6.1.4.1.56521.101.2.1.79 1820 NAME 'sponsorState' 1821 DESC 'State or province name for a sponsor entry' 1822 SINGLE-VALUE 1823 SUP st ) 1825 Examples: "California", "North Dakota" 1827 2.1.80. 'sponsorStreet' 1829 The 'sponsorStreet' attribute type allows for the assignment of a 1830 street name and number to a sponsor entry. 1832 The attribute type 'street', as defined in Section 2.34 of [RFC4519], 1833 is a super type of this attribute type. 1835 ( 1.3.6.1.4.1.56521.101.2.1.80 1836 NAME 'sponsorStreet' 1837 DESC 'Street name and number for a sponsor entry' 1838 SINGLE-VALUE 1839 SUP street ) 1841 Example: "1 Fake Street" 1843 2.1.81. 'sponsorTelephone' 1845 The 'sponsorTelephone' attribute type allows for the assignment of 1846 a telephone number to a sponsor entry. 1848 The attribute type 'telephoneNumber', as defined in Section 2.35 of 1849 [RFC4519], is a super type of this attribute type. 1851 ( 1.3.6.1.4.1.56521.101.2.1.81 1852 NAME 'sponsorTelephone' 1853 DESC 'Telephone number for a sponsor entry' 1854 SINGLE-VALUE 1855 SUP telephoneNumber ) 1857 Example: "+11234567890" 1859 2.1.82. 'sponsorTitle' 1861 The 'sponsorTitle' attribute type allows for the assignment of an 1862 official or professional title to a sponsor entry. 1864 The attribute type 'title', as defined in Section 2.38 of [RFC4519], 1865 is a super type of this attribute type. 1867 ( 1.3.6.1.4.1.56521.101.2.1.82 1868 NAME 'sponsorTitle' 1869 DESC 'Title for a sponsor entry' 1870 SINGLE-VALUE 1871 SUP title ) 1873 Example: "Executive Sponsor" 1875 2.1.83. 'sponsorURI' 1877 The 'sponsorURI' attribute type allows for the assignment of one or 1878 more URI values, each with an optional label, to a sponsor entry. 1880 The attribute type 'labeledURI', as defined in [RFC2079], is a super 1881 type of this attribute type. 1883 ( 1.3.6.1.4.1.56521.101.2.1.83 1884 NAME 'sponsorURI' 1885 DESC 'URI, with an optional label, for a 1886 sponsor entry' 1887 SUP labeledURI ) 1889 Examples: "http://example.com Example", "http://example.com" 1891 2.1.84. 'rARegistrationBase' 1893 The 'rARegistrationBase' attribute type allows for the storage 1894 of an LDAP DN meant to store the location of registration entries 1895 within the DIT. Clients SHOULD expect entries of types x660RootArc 1896 or x660SubArc exactly one (1) level below this DN. 1898 This is primarily used in scenarios where it is desirable for an 1899 application to self-configure for maximum efficiency in terms of 1900 registration location and retrieval. 1902 An ideal location for this attribute type is within the DSA's 1903 RootDSE. 1905 The attribute type 'distinguishedName', as defined in Section 2.7 1906 of [RFC4519], is a super type of this attribute type. 1908 ( 1.3.6.1.4.1.56521.101.2.1.84 1909 NAME 'rARegistrationBase' 1910 DESC 'LDAP Distinguished Name of the root X.660 1911 registration entry storage location in a DIT' 1912 SUP distinguishedName ) 1914 Example: "ou=OID,ou=X660,dc=example,dc=com" 1916 2.1.85. 'rARegistrantBase' 1918 The 'rARegistrantBase' attribute type allows for the storage of 1919 an LDAP DN referencing the location of registrant (contact) entries 1920 within the DIT. Clients SHOULD expect entries bearing the object 1921 class of 'x660Registrant' exactly one (1) level below this DN. 1923 This is primarily used in scenarios where it is desirable for an 1924 application to self-configure for maximum efficiency in terms of 1925 registrant location, retrieval and management. 1927 An ideal location for this attribute type is within the DSA's 1928 RootDSE. 1930 The attribute type 'distinguishedName', as defined in Section 2.7 of 1931 [RFC4519], is a super type of this attribute type. 1933 ( 1.3.6.1.4.1.56521.101.2.1.85 1934 NAME 'rARegistrantBase' 1935 DESC 'LDAP Distinguished Name of the root X.660 1936 registrant entry storage location in a DIT' 1937 SUP distinguishedName ) 1939 Example: "ou=Registrants,ou=X660,dc=example,dc=com" 1941 2.1.86. 'rADirectoryModel' 1943 The 'rADirectoryModel' attribute type allows for the storage of 1944 of an object identifier meant to declare the structural design of 1945 the DIT content pertaining to this specification. 1947 This is primarily used in scenarios where it is desirable for an 1948 application to self-configure for maximum efficiency in terms of 1949 registration location and retrieval. 1951 The supported values for this attribute type are as follows and 1952 correspond to Sections 3.2 and 3.3 of this specification: 1954 - 1.3.6.1.4.1.56521.101.3.2 (twoDimensional) 1955 - 1.3.6.1.4.1.56521.101.3.3 (threeDimensional) 1957 An ideal location for this attribute type is within the DSA's 1958 RootDSE. 1960 ( 1.3.6.1.4.1.56521.101.2.1.86 1961 NAME 'rADirectoryModel' 1962 DESC 'Object Identifier meant to advertise 1963 the directory model governing the storage 1964 of X.660 LDAP entries within the DIT' 1965 EQUALITY objectIdentifierMatch 1966 SINGLE-VALUE 1967 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1969 Example: "1.3.6.1.4.1.56521.101.3.3" 1971 2.1.87. 'rAServiceMail' 1973 The 'rAServiceMail' attribute type allows for the assignment 1974 of an email address to an 'x660DUAConfig' entry for the purpose 1975 of email-based RA request handling or error reporting. 1977 The attribute type 'mail', as defined in Section 2.16 of [RFC4524], 1978 is a super type of this attribute type. 1980 ( 1.3.6.1.4.1.56521.101.2.1.87 1981 NAME 'rAServiceMail' 1982 DESC 'Email address used for RA-level 1983 registration requests, inquiries or 1984 problem reports' 1985 SUP mail ) 1987 Example: "ra@example.com" 1989 2.1.88. 'rAServiceURI' 1991 The 'rAServiceURI' attribute type allows for the assignment of one 1992 or more URI values to an 'x660DUAConfig' entry for the purpose of 1993 directing users to appropriate RA endpoint for request handling. 1995 The attribute type 'labeledURI', as defined in [RFC2079], is a super 1996 type of this attribute type. 1998 ( 1.3.6.1.4.1.56521.101.2.1.88 1999 NAME 'rAServiceURI' 2000 DESC 'URI, with an optional label, defining 2001 an appropriate RA endpoint' 2002 SUP labeledURI ) 2004 Example: "http://example.com/ra.html Registrations" 2006 2.2. Object Classes 2008 The following subsections describes LDAP object classes made 2009 available by this specification. 2011 2.2.1. 'x660RootArc' 2013 The 'x660RootArc' class is meant to define a maximum of three (3) 2014 root registrations within a DIT, per Rec. ITU-T X.660 (ISO/IEC 2015 9834-1). 2017 ( 1.3.6.1.4.1.56521.101.2.2.1 2018 NAME 'x660RootArc' 2019 DESC 'Top-level class for entries meant to represent 2020 ITU-T, ISO or Joint-ISO-ITU-T root arcs as defined 2021 in Section A.2 of the X.660 specification' 2022 SUP top STRUCTURAL 2023 MUST ( n $ unicodeValue $ identifier ) 2024 MAY ( registrationInformation $ additionalIdentifier $ 2025 asn1Notation $ iRI $ currentAuthority $ subArc $ 2026 stdNameForm $ description $ registrationURI $ 2027 registrationCreated $ registrationModified $ 2028 leftArc $ rightArc $ nameAndNumberForm $ 2029 firstAuthority ) ) 2031 2.2.2. 'x660SubArc' 2033 The 'x660SubArc' object class makes a collection of attribute 2034 types available for use when crafting subordinate registrations 2035 within a DIT. 2037 ( 1.3.6.1.4.1.56521.101.2.2.2 2038 NAME 'x660SubArc' 2039 DESC 'A generalized class meant to represent sub arcs 2040 beneath any root, as defined in X.660 Sections A.3-A.5' 2041 SUP top STRUCTURAL 2042 MUST ( n ) 2043 MAY ( nameAndNumberForm $ firstAuthority $ finalArc $ 2044 currentAuthority $ supArc $ subArc $ firstArc $ 2045 topArc $ description $ registrationURI $ iRI $ 2046 isFrozen $ discloseTo $ sponsor $ isLeafNode $ 2047 leftArc $ rightArc $ registrationInformation $ 2048 additionalIdentifier $ registrationCreated $ 2049 unicodeValue $ longArc $ registrationRange $ 2050 registrationModified $ registrationStatus $ 2051 identifier $ stdNameForm $ asn1Notation $ 2052 dotNotation ) ) 2054 2.2.3. 'x660Registrant' 2056 The 'x660Registrant' object class allows for current, previous 2057 (first) and/or sponsorship data to be stored within an entry. 2059 ( 1.3.6.1.4.1.56521.101.2.2.3 2060 NAME 'x660Registrant' 2061 DESC 'A generalized auxiliary class for 2062 registrant contact information' 2063 SUP top AUXILIARY 2064 MAY ( currentAuthorityURI $ sponsorCommonName $ sponsorOrg $ 2065 firstAuthorityPOBox $ sponsorPOBox $ sponsorLocality $ 2066 sponsorCountryCode $ firstAuthorityURI $ description $ 2067 firstAuthorityStartTimestamp $ sponsorStartTimestamp $ 2068 firstAuthorityFax $ sponsorCountryName $ sponsorURI $ 2069 sponsorTelephone $ currentAuthorityOrg $ sponsorFax $ 2070 currentAuthorityCommonName $ firstAuthorityMobile $ 2071 currentAuthorityTitle $ firstAuthorityCountryCode $ 2072 currentAuthorityPostalAddress $ firstAuthorityOrg $ 2073 currentAuthorityFax $ firstAuthorityPostalAddress $ 2074 currentAuthorityCountryCode $ firstAuthorityState $ 2075 currentAuthorityCountryName $ firstAuthorityEmail $ 2076 currentAuthorityMobile $ firstAuthorityCommonName $ 2077 firstAuthorityCountryName $ currentAuthorityState $ 2078 currentAuthorityPostalCode $ firstAuthorityStreet $ 2079 currentAuthorityTelephone $ currentAuthorityEmail $ 2080 currentAuthorityLocality $ firstAuthorityLocality $ 2081 currentAuthorityStreet $ firstAuthorityPostalCode $ 2082 firstAuthorityTitle $ registrantID $ sponsorEmail $ 2083 firstAuthorityEndTimestamp $ sponsorEndTimestamp $ 2084 firstAuthorityTelephone $ currentAuthorityPOBox $ 2085 currentAuthorityStartTimestamp $ sponsorTitle $ 2086 sponsorStreet $ sponsorMobile $ sponsorState $ 2087 sponsorPostalCode $ sponsorPostalAddress ) ) 2089 2.2.4. 'x660DUAConfig' 2091 The 'x660DUAConfig' object class allows for the storage of so-called 2092 auto-configuration attribute types meant to guide various DUAs in 2093 their attempt to access registration and/or registrant information 2094 contained within the DIT hosted by the RA DSA. See Section 3.5 for 2095 details. 2097 ( 1.3.6.1.4.1.56521.101.2.2.4 2098 NAME 'x660DUAConfig' 2099 DESC 'Entry class to facilitate advertisement 2100 of optimal X.660 DUA configuration values' 2101 SUP top AUXILIARY 2102 MAY ( rADirectoryModel $ rARegistrantBase $ 2103 rAServiceMail $ rAServiceURI $ 2104 rARegistrationBase ) ) 2106 3. Directory Models and Procedures 2108 This section offers two (2) distinct models, and some procedures, by 2109 which both directory architects and application developers SHOULD be 2110 guided in efforts to implement this specification. 2112 Note that in various examples shown, some DNs are particularly long 2113 and are line-wrapped and indented for readability. 2115 3.1. Naming Context and Organization Entries 2117 In these examples, a naming context of "ou=X660, dc=example, dc=com" 2118 is used as the "suffix". Within this suffix are two (2) entries: 2120 - "ou=OID, ou=X660, dc=example, dc=com" - Storage of all 2121 registration entries (e.g.: 'rARegistrationBase') 2123 - "ou=Registrants, ou=X660, dc=example, dc=com" - Storage 2124 of all registrant (authority/sponsorship) entries (e.g.: 2125 'rARegistrantBase') 2127 Directory architects MAY choose to use models of their own design, so 2128 long as noted requirements in the following sections are satisfied. 2130 3.2. Two-Dimensional Model 2132 This model suggests that registrations reside as siblings within an 2133 LDAP DIT in singular, non-hierarchical locations. 2135 This model is RECOMMENDED for small and/or sparse implementations. 2136 The three-dimensional model (See Section 3.3) may be more appropriate 2137 for larger, more robust implementations. 2139 Use of this model is entirely at the discretion of the directory 2140 architect(s) involved. It should be noted that if users will be 2141 managing OID data directly through use of standard LDAP TUI or GUI 2142 applications, this model would seem to be more convenient as opposed 2143 to the three-dimensional model. 2145 A DSA can advertise the use of this structural model using the 2146 following attribute type and value in a location that is easily 2147 discovered by clients (e.g.: the RootDSE [RFC4512]): 2149 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.2 2151 3.2.1. Requirements 2153 One requirement of this model is strict use of the 'dotNotation' 2154 attribute type, covered in Section 2.1.2. This attribute MUST be 2155 used on all non-root registrations. 2157 Root registrations SHALL NOT bear an 'dotNotation' value, as the 2158 syntax for OIDs (see Section 3.3.26 of [RFC4517]) requires at least 2159 two (2) arcs in a given value. 2161 Uniqueness of 'dotNotation' values within a directory structure 2162 MUST always be enforced to ensure unambiguous results. The simplest 2163 way to meet this requirement would be to adopt a DN structure based 2164 on this attribute type, as shown in Section 3.2.2. 2166 3.2.2. Distinguished Name Convention 2168 Because all LDAP Search Requests [RFC4511] can be conducted using a 2169 scope of singleLevel (per Section 4.5.1.2 of [RFC 4511]) below the 2170 necessary directory branch, a DN structure of hierarchical nature is 2171 wholly unnecessary. While the three-dimensional model (as shown in 2172 Section 3.3) uses the integer-based 'n' attribute type (per Section 2173 2.1.1) to form the effective LDAP RDN of an entry, this would not be 2174 practical in this model. 2176 The most sensible convention for DN involves use of the attribute 2177 type 'dotNotation' as shown: 2179 dn: dotNotation=1.3,ou=OID,ou=X660,dc=example,dc=com 2180 objectClass: top 2181 objectClass: x660SubArc 2182 n: 3 2183 unicodeValue: Identified-Organization 2184 dotNotation: 1.3 2186 Subsequent entries, regardless of their true [X.660] hierarchical 2187 placement, manifest as sibling directory entries. For example, the 2188 addition of "deeper" arcs would be procedurally identical: 2190 dn: dotNotation=1.3.6.1,ou=OID,ou=X660,dc=example,dc=com 2191 objectClass: top 2192 objectClass: x660SubArc 2193 n: 1 2194 identifier: internet 2195 dotNotation: 1.3.6.1 2197 3.2.3. Root Arc Entries 2199 A maximum of three (3) root arcs MAY exist within the directory 2200 landscape. If one or more are created, they SHOULD be identifiable 2201 as follows: 2203 - itu-t (0) 2204 - iso (1) 2205 - joint-iso-itu-t (2) 2207 As sibling entries, these root arcs MUST use the 'x660RootArc' 2208 class, as shown in Section 2.2.1: 2210 dn: n=0,ou=OID,ou=X660,dc=example,dc=com 2211 objectClass: top 2212 objectClass: x660RootArc 2213 n: 0 2214 unicodeValue: ITU-T 2216 dn: n=1,ou=OID,ou=X660,dc=example,dc=com 2217 objectClass: top 2218 objectClass: x660RootArc 2219 n: 1 2220 unicodeValue: ISO 2222 dn: n=2,ou=OID,ou=X660,dc=example,dc=com 2223 objectClass: top 2224 objectClass: x660RootArc 2225 n: 2 2226 unicodeValue: Joint-ISO-ITU-T 2228 Using root registrations is only useful in the two-dimensional model 2229 if the administrator wishes to organize lists of OIDs beneath their 2230 respective roots. This is likely unnecessary in implementations that 2231 are small and sparse. In larger implementations, however, this model 2232 may be convenient in situations where DIT content segmentation is in 2233 effect. 2235 3.3. Three-Dimensional Model 2237 This model is hierarchical by nature, providing a means for storing 2238 registrations in nested fashion, thereby reflecting the hierarchical 2239 logic of the [X.660] specification itself. 2241 This model is RECOMMENDED for thorough or complete implementations, 2242 or implementations in which custom solutions (applications) have been 2243 tailored for this purpose. This model may be prohibitively tedious 2244 in sparse and/or small implementations. 2246 Use of this model is entirely at the discretion of the directory 2247 architect(s) involved. It should be noted that end-users that will 2248 directly access or manage this data through standard LDAP TUI or GUI 2249 applications alone may find this model tedious, and may prefer the 2250 two-dimensional model as described in Section 3.2. 2252 A DSA can advertise the use of this structural model using the 2253 following attribute type and value in a location that is easily 2254 discovered by clients (e.g.: the RootDSE [RFC4512]): 2256 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3 2258 3.3.1. Requirements 2260 In this model, interim arcs MUST exist even if they are otherwise 2261 unnecessary. 2263 For example, in order to add the well-known "internet" OID (1.3.6.1), 2264 directory administrators MUST ensure the following registrations 2265 exist beforehand: 2267 dn: n=1,ou=OID,ou=X660,dc=example,dc=com 2268 objectClass: top 2269 objectClass: x660RootArc 2270 n: 1 2271 identifier: iso 2272 unicodeValue: ISO 2274 dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2275 objectClass: top 2276 objectClass: x660SubArc 2277 n: 3 2278 identifier: identified-organization 2279 unicodeValue: Identified-Organization 2281 dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2282 objectClass: top 2283 objectClass: x660SubArc 2284 n: 6 2285 identifier: dod 2287 Only once this requirement is satisfied would the administrators 2288 be able to create the desired registration, such as a registration 2289 entry for the "internet" OID, as shown in [RFC1155]: 2291 dn: n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2292 objectClass: top 2293 objectClass: x660SubArc 2294 n: 1 2295 identifier: internet 2297 3.3.2. Distinguished Name Convention 2299 Under a strict interpretation of this model, its implementation 2300 will provide a means for bidirectional resolution of registered 2301 OIDs. LDAP DNs can be deduced from OIDs, and vice versa. 2303 This is achieved by using the 'n' attribute type (as defined in 2304 Section 2.1.1) as components in the effective LDAP DN, but in 2305 reverse order to reflect the directory hierarchy. 2307 For example: the "internet" OID would exist as an entry with a DN as 2308 depicted below: 2310 1.3.6.1 2311 ---------------- 2312 | | | | 2313 dn: n=1, n=6, n=3, n=1, ou=OID, ou=X660, dc=example, dc=com 2315 As a result, use of the 'dotNotation' attribute type becomes 2316 unnecessary unless users wish to search for an OID using an LDAP 2317 search filter. 2319 3.3.3. Root Arc Entries 2321 A maximum of three (3) root arcs SHOULD exist within the directory 2322 landscape. If one or more are created, they MUST be identifiable 2323 as follows: 2325 - itu-t (0) 2326 - iso (1) 2327 - joint-iso-itu-t (2) 2329 As sibling entries, these root arcs MUST use the 'x660RootArc' 2330 class, as shown in Section 2.2.1: 2332 dn: n=0,ou=OID,ou=X660,dc=example,dc=com 2333 objectClass: top 2334 objectClass: x660RootArc 2335 n: 0 2336 unicodeValue: ITU-T 2338 dn: n=1,ou=OID,ou=X660,dc=example,dc=com 2339 objectClass: top 2340 objectClass: x660RootArc 2341 n: 1 2342 unicodeValue: ISO 2344 dn: n=2,ou=OID,ou=X660,dc=example,dc=com 2345 objectClass: top 2346 objectClass: x660RootArc 2347 n: 2 2348 unicodeValue: Joint-ISO-ITU-T 2350 Depending on the breadth and scope of an implementation, creation and 2351 use of root registrations is RECOMMENDED, but not required for every 2352 situation. 2354 3.3.3.1. Lack of Root Arc Entries 2356 In situations where a three-dimensional model is used, but only 2357 contains a subset of subordinate registrations, root registrations 2358 may not be necessary. 2360 Instead, directories architects MAY choose to create a subordinate 2361 registration as a false root, and store the relevant contents there. 2363 For example, if a directory architect only wanted to store IANA 2364 PEN registrations that are allocated below the OID 1.3.6.1.4.1, 2365 the relevant DIT entries could manifest as follows: 2367 dn: dotNotation=1.3.6.1.4.1,ou=OID,ou=X660,dc=example, 2368 dc=com 2369 objectClass: top 2370 objectClass: x660SubArc 2371 identifier: enterprise 2372 additionalIdentifier: enterprises 2373 registrationURI: https://www.iana.org/assignments/enterprise 2374 -numbers 2376 dn: n=56521,dotNotation=1.3.6.1.4.1,ou=OID,ou=X660, 2377 dc=example,dc=com 2378 objectClass: top 2379 objectClass: x660SubArc 2381 ... other sibling PEN entries ... 2383 Alternatively, if the above non-standard DN syntax is undesirable, 2384 directory architects MAY choose to honor the three-dimensional model 2385 DN syntax, but limit creation of new entries to those that are direct 2386 ancestors of the intended subset. In this situation use of a root 2387 registration is necessary, but only relevant entries would need to be 2388 created. 2390 Keeping with the above scenario, the relevant DIT entries could 2391 manifest as follows: 2393 dn: n=1,ou=OID,ou=X660,dc=example,dc=com 2394 objectClass: top 2395 objectClass: x660RootArc 2396 n: 1 2397 unicodeValue: ISO 2399 dn: n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2400 objectClass: top 2401 objectClass: x660SubArc 2402 n: 3 2403 unicodeValue: Identified-Organization 2405 dn: n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2406 objectClass: top 2407 objectClass: x660SubArc 2408 n: 6 2409 identifier: dod 2411 dn: n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2412 objectClass: top 2413 objectClass: x660SubArc 2414 n: 1 2415 identifier: internet 2416 dn: n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2417 objectClass: top 2418 objectClass: x660SubArc 2419 n: 4 2420 identifier: private 2422 dn: n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2423 objectClass: top 2424 objectClass: x660SubArc 2425 n: 1 2426 identifier: enterprise 2427 additionalIdentifier: enterprises 2428 registrationURI: https://www.iana.org/assignments/enterprise 2429 -numbers 2431 dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660,dc=example, 2432 dc=com 2433 n: 56521 2434 objectClass: top 2435 objectClass: x660SubArc 2437 ... other sibling PEN entries ... 2439 3.4. Registrant Information 2441 Directory architects MAY choose to store registrant information in 2442 one of two main ways: 2444 - Store sponsor or authority registrant information within 2445 registration entries themselves, or ... 2447 - Store sponsor and/or authority registrant information within 2448 dedicated entries, and reference the DNs of these entries 2449 via the 'currentAuthority', 'sponsor' and/or 'firstAuthority' 2450 attribute types assigned to registrations. 2452 The nature of these contacts will typically encompass three (3) 2453 kinds of entities: 2455 - An individual 2456 - An organization, institution or working group 2457 - A document (e.g.: a standard or draft) 2459 3.4.1. Use of Collective or Virtual Attributes 2461 In situations involving particularly large and/or distributed LDAP 2462 DIT contexts, directory architects MAY choose to extend certain 2463 attribute types within this specification to allow for Collective 2464 Attributes [RFC3671] support, or some other proprietary feature for 2465 the facilitation of so-called "virtual attributes" to allow for a 2466 broad-scale and low-cost association of attribute values across 2467 entire pools of entries. 2469 While these concepts are out of scope for this specification, a few 2470 attribute types defined in Section 2 MAY be used in situations that 2471 involve one or more specific registrants being assigned to a very 2472 large number of registrations, or an entire subtree in perpetuity: 2474 - 'currentAuthority', defined in Section 2.1.28 2475 - 'firstAuthority', defined in Section 2.1.46 2476 - 'sponsor', defined in Section 2.1.65 2478 3.4.2. Examples 2480 3.4.2.1. Combined Registration and Registrant Entries 2482 This is a basic two-dimensional example entry comprised of both 2483 registration and registrant attribute types. 2485 dn: dotNotation=1.3.6.1.4.1.56521,n=1,ou=OID,ou=X660, 2486 dc=example,dc=com 2487 objectClass: x660SubArc 2488 objectClass: x660Registrant 2489 objectClass: top 2490 currentAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262 2491 currentAuthorityCommonName: Jesse Coretta 2492 currentAuthorityEmail: jesse.coretta@example.com 2493 currentAuthorityMobile: +11234567890 2494 dotNotation: 1.3.6.1.4.1.56521 2495 n: 56521 2497 This is a basic three-dimensional example entry of the same design. 2499 dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660, 2500 dc=example,dc=com 2501 objectClass: x660SubArc 2502 objectClass: x660Registrant 2503 objectClass: top 2504 currentAuthorityPostalAddress: 1 Fake St$Anywhere$CA$92262 2505 currentAuthorityCommonName: Jesse Coretta 2506 currentAuthorityEmail: jesse.coretta@example.com 2507 currentAuthorityMobile: +11234567890 2508 n: 56521 2510 3.4.2.2. Dedicated Registrant Entries 2512 This is a basic example of a single authority-based contact entry. 2514 Please note that use of the 'organizationalRole' object class (per 2515 Section 3.10 of [RFC4519]) is purely incidental here. Directory 2516 architects MAY opt for another STRUCTURAL object class. 2518 dn: registrantID=draft-coretta-x660-ldap,ou=Registrants, 2519 ou=X660,dc=example,dc=com 2520 registrantID: draft-coretta-x660-ldap 2521 cn: draft-coretta-x660-ldap 2522 objectClass: organizationalRole 2523 objectClass: x660Registrant 2524 objectClass: top 2525 currentAuthorityPostalAddress: 1 Fake St$Palm Springs$ 2526 CA$92262 2527 currentAuthorityCommonName: Jesse Coretta 2528 currentAuthorityEmail: jesse.coretta@icloud.com 2529 currentAuthorityMobile: +11234567890 2530 currentAuthorityStartTimestamp: 20200229134901Z 2532 In cases where multiple distinct individuals or addresses are used, 2533 they can all be combined into a single entry: 2535 dn: registrantID=draft-coretta-x660-ldap,ou=Registrants, 2536 ou=X660,dc=example,dc=com 2537 registrantID: draft-coretta-x660-ldap 2538 cn: draft-coretta-x660-ldap 2539 objectClass: organizationalRole 2540 objectClass: x660Registrant 2541 objectClass: top 2542 currentAuthorityPostalAddress: 1 Fake St$Palm Springs$ 2543 CA$92262 2544 currentAuthorityCommonName: Jesse Coretta 2545 currentAuthorityEmail: jesse.coretta@icloud.com 2546 currentAuthorityMobile: +11234567890 2547 currentAuthorityStartTimestamp: 20200229134901Z 2548 sponsorOrg: Sponsor, Co. 2549 sponsorEmail: sponsor@example.com 2550 sponsorMobile: +11234560987 2551 sponsorStartTimestamp: 20010104120144Z 2552 sponsorPostalAddress: 456 Fugazzi Ln$Anywhere$CA$92262 2553 firstAuthorityPostalAddress: 1 Fake St$Palm Springs$ 2554 CA$92262 2555 firstAuthorityCommonName: Jesse Coretta 2556 firstAuthorityEmail: jesse.coretta@icloud.com 2557 firstAuthorityMobile: +11234567890 2558 firstAuthorityStartTimestamp: 20200229134901Z 2560 Keeping with the example registration described in Section 3.4.2.2, 2561 the three-dimensional registration would manifest as follows: 2563 dn: n=56521,n=1,n=4,n=1,n=6,n=3,n=1,ou=OID,ou=X660, 2564 dc=example,dc=com 2565 objectClass: x660SubArc 2566 objectClass: top 2567 currentAuthority: registrantID=draft-coretta-x660-ldap, 2568 ou=Registrants,ou=X660,dc=example,dc=com 2569 n: 56521 2571 3.5. DUA Configuration 2573 Two (2) distinct methods for client-side configuration are shown 2574 in this section. Users and directory architects alike MAY opt 2575 for one over the other, depending on the situation. 2577 Regardless of the style of configuration, DUA observance of the 2578 following constants is strongly RECOMMENDED when leveraging this 2579 specification in the manner intended: 2581 - An effective registration search base MUST be made available 2582 - The condition of a missing or undefined registrant search base 2583 MUST indicate that NO authority or sponsorship information is 2584 stored or advertised 2585 - The condition of a registration search base that is equal to 2586 the registrant search base MUST indicate the use of so-called 2587 Combined Registration and Registrant entries 2588 - The condition of a registration search base that is not equal 2589 to the registrant search base MUST indicate the use of so-called 2590 Dedicated Registrant entries 2592 3.5.1. Manual Configuration 2594 Manual configuration MAY be used if: 2596 - Advertisement of configuration information, as shown in Section 2597 3.5.2, is unavailable, or ... 2598 - The information advertised is somehow unreliable, or ... 2599 - The DUA is not optimized for this specification 2601 Assuming one of the above applies, the following conceptual runtime 2602 settings are sufficient for basic interaction with the DSA acting as 2603 an RA: 2605 - Directory model object identifier (see Sections 3.2 and 3.3) 2606 - Distinguished name(s) used for registration and registrant 2607 LDAP search bases 2609 3.5.2. Automatic Configuration 2611 Any DUA optimized or designed with this specification in mind SHOULD 2612 support the automatic retrieval of the following attribute types: 2614 - 'rARegistrationBase', as defined in Section 2.1.84 2615 - 'rARegistrantBase', as defined in Section 2.1.85 2616 - 'rADirectoryModel', as defined in Section 2.1.86 2617 - 'rAServiceMail', as defined in Section 2.1.87 2618 - 'rAServiceURI', as defined in Section 2.1.88 2620 Limitations pertaining to the artificial addition of attributes to 2621 the RootDSE are implementation-specific, and thus the DUA SHOULD 2622 allow manual configuration, as shown in Section 3.5.1, as a fallback 2623 measure. 2625 There are two techniques a DUA MAY use to locate the above attribute 2626 types: 2628 - Check the RootDSE advertised by the DSA(s) 2629 - If a RootDSE check fails, fallback to a broad-level search 2630 for a single LDAP entry bearing the 'x660DUAConfig' object 2631 class, as shown in Section 2.2.4 2633 3.5.2.1. Examples 2635 This subsection shows examples for storing values assigned to the 2636 attribute types mentioned in Section 3.5.2. Note these may not 2637 be complete and legal LDAP entries, as their full contents may be 2638 omitted for brevity. 2640 RootDSE alterations may manifest as follows for an RA storing a 2641 three-dimensional [X.660] DIT structure with dedicated registrant 2642 entries: 2644 dn: 2645 objectClass: x660DUAConfig 2646 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3 2647 rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com 2648 rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com 2650 Alternatively, for an RA storing a two-dimensional [X.660] DIT 2651 structure with combined registration and registrant entries: 2653 dn: 2654 objectClass: x660DUAConfig 2655 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.2 2656 rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com 2657 rARegistrantBase: ou=OID,ou=X660,dc=example,dc=com 2659 If use of the RootDSE is not feasible for storing this information, 2660 but automatic configuration is still desired, directory architects 2661 MAY opt to store entries similar to those above within another DIT, 2662 however the drawback to this approach is that the DUA (or its user) 2663 would require foreknowledge of the relevant suffix. 2665 dn: dc=example,dc=com 2666 objectClass: x660DUAConfig 2667 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3 2668 rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com 2669 rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com 2671 Depending on the nature of the RA service indicated, the creation 2672 or modification of registrations MAY require approval before such 2673 changes can be committed to the directory. As such, a directory 2674 architect MAY opt to advertise an appropriate email address and/or 2675 URI as shown below. 2677 DUAs or services optimized for this specification may be required to 2678 alter their behavior as it relates to write operations against the 2679 RA DSA if the 'rAServiceMail' and/or 'rAServiceURI' attribute 2680 types are present: 2682 dn: 2683 objectClass: x660DUAConfig 2684 rADirectoryModel: 1.3.6.1.4.1.56521.101.3.3 2685 rAServiceMail: ra@example.com 2686 rAServiceURI: https://www.example.com/ra.html 2687 rARegistrationBase: ou=OID,ou=X660,dc=example,dc=com 2688 rARegistrantBase: ou=Registrants,ou=X660,dc=example,dc=com 2690 3.6. Spatial Orientation and Navigation 2692 Some of the more complete RA services, whether public or private, 2693 may offer a simple interface to facilitate intuitive contiguous 2694 movement between logically adjacent registrations in terms of "up", 2695 "down", "left" and "right" 2697 Depending on the needs of the intended audience, as well as the 2698 manner in which this specification is adopted, this can be an 2699 exceptionally difficult feature to implement. 2701 The main concerns on this topic are summarized as follows: 2703 - DSI/DUA (client) capabilities 2704 - DSA resource utilization 2705 - DIT content model, complexity and footprint 2707 The functionality discussed in this subsection is NOT officially 2708 defined in [X.660], but is present in this specification so as to 2709 mitigate or overcome certain challenges associated with the use of 2710 directory services in this context. 2712 3.6.1. Client Capabilities 2714 In terms of this specification, a client will be most effective 2715 when its implementer, or developer, takes care to understand the 2716 nature of the DSA(s) it may use, as well as the DIT(s) in question. 2718 Assuming a sound configuration is in place, per Section 3.5, a given 2719 client needs to determine a means for the following actions by OID 2720 alone: 2722 - Locating individual registrations 2723 - Traversing surrounding registrations (spatially) 2725 3.6.1.1. Locating Individual Registrations 2727 In sufficiently thorough three-dimensional implementations of this 2728 specification, it is not uncommon to see an absence of literal 2729 'dotNotation' values for registrations. The reason for this, as 2730 shown in Section 3.3.2, is that the DN syntax alone is sufficient for 2731 the "storage" of an OID. The drawback, however, is that the client 2732 is now required to perform the following abstract actions to locate 2733 (or extrapolate) an OID to an entry: 2735 - Reverse OID (1.3.6 becomes 6.3.1) 2736 - Transmute reversed OID to a partial RDN sequence using 2737 the 'n' attribute type (n=6,n=3,n=1) 2738 - Combine the appropriate registration suffix DN and RDNs 2739 (n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com) 2741 Procedurally, this is a simple operation and is beneficial when an 2742 application is dealing with a particularly busy DSA, as a baseObject 2743 LDAP Search Request (per Section 4.5.1.2 of [RFC4511]) will always 2744 return either one (1) or zero (0) results. This would result in 2745 lower DSA utilization overall when compared to broad search request 2746 for a 'dotNotation' value, but because the composed DN is "inferred", 2747 subsequent requests come with the risk of a 'noSuchObject (32)' error 2748 being returned (per Appendix A, Section 2 of [RFC4511]) should the 2749 entry not exist at said specified DN. 2751 However, in two-dimensional implementations of this specification, 2752 as shown in Section 3.2.2, a literal 'dotNotation' value exists which 2753 the client can query one of two ways: 2755 - If 'dotNotation' is used as a component in the relevant 2756 DN syntax, call the extrapolated DN, or ... 2757 - Perform broad filter-based searches for the desired OID 2758 as a literal 'dotNotation' (e.g.: '(dotNotation=)') 2760 The former option requires extra effort on part of the client, while 2761 the latter option will require more DSA resources, and would require 2762 the attribute type be populated for the given registration. 2764 3.6.1.2. Traversing Adjacent or Ancestral Registrations 2766 OIDs exist in lexically hierarchical relation to one another, and 2767 with no absolutely no limits imposed on overall OID "depth" nor on 2768 the magnitude of any single NumberForm [X.680] component (so long 2769 as the magnitude is zero (0) or more). 2771 An effective client intended for use in situations involving this 2772 specification SHOULD have the capability to locate all applicable 2773 adjacent entries without extraordinary effort. The subsections that 2774 follow will cover attribute types and procedures to that end. 2776 3.6.1.2.1. Use of the 'supArc' and 'topArc' Attribute Types 2778 The 'supArc' and 'topArc' attribute types are used to describe the 2779 vertical relationships between registrations in an ancestral sense. 2780 One need only perform a baseObject LDAP Search Request (per Section 2781 4.5.1.2 of [RFC4511]) upon the referenced DN to obtain the superior 2782 entry in question. 2784 If a registration possesses a DN value for the 'supArc' attribute 2785 type, the DN MUST belong to the registration that is the immediate 2786 superior (parent). 2788 Similarly, if a registration possesses a DN value for the 'topArc' 2789 attribute type, this DN MUST belong to the absolute root registration 2790 entry within the directory. In this case, the registration entry 2791 MUST ONLY be one (1) of itu-t(0), iso(1) or joint-iso-itu-t(2). 2793 A directory architect MAY choose to leverage either of these types 2794 virtually, depending on the situation. For example, if a certain 2795 registration possesses tens of thousands of subordinate registration 2796 entries, it may be prudent to assign the 'topArc' and/or 'supArc' 2797 attribute types to those registrations through the use of Collective 2798 Attribute [RFC3671] support, or some other proprietary means for the 2799 assignment of virtual values to a vast number of entries. Both of 2800 these concepts are out of scope for this document. 2802 If a registration does not possess a value for either of the above 2803 attribute types, this is indicative of one of these conditions: 2805 - Registration is an 'x660RootArc'-based entry, and thus no 2806 such superior registrations could ever possibly exist, or ... 2807 - The DSA in question is intended only to host a subset of the 2808 OID spectrum, and any superior references would violate such 2809 constraints, or ... 2810 - Client is expected to extrapolate the appropriate superior 2811 registration using its own means 2813 Assuming the client is expected to extrapolate the logically superior 2814 registration, this can be handled in one of two ways: 2816 - If a three-dimensional directory model is indicated, and the DN 2817 syntax described in Section 3.3.2 is in use, the client should 2818 attempt to truncate the leaf-node RDN to achieve its superior 2819 (parent) DN, or ... 2821 - If a two-dimensional directory model is indicated, and the DN 2822 syntax described in Section 3.2.2 is in use, the client should 2823 attempt to read the literal 'dotNotation' value from the entry 2824 DN, truncate the value's leaf-node (right-hand) OID component, 2825 and utilize the remaining contents for the basis of subsequent 2826 entry location 2828 In the former (three-dimensional) case, consider the following 2829 example, in which the leaf-node (n=6) is truncated to obtain the 2830 DN of the superior registration: 2832 - n=6,n=3,n=1,ou=OID,ou=X660,dc=example,dc=com 2833 - n=3,n=1,ou=OID,ou=X660,dc=example,dc=com (parent) 2835 In the latter (two-dimensional) case, consider the following example, 2836 in which the 'dotNotation' RDN value is truncated to extrapolate the 2837 DN of the superior registration: 2839 - dotNotation=1.3.6,ou=OID,ou=X660,dc=example,dc=com 2840 - dotNotation=1.3,ou=OID,ou=X660,dc=example,dc=com 2842 3.6.1.2.2. Use of the 'subArc' Type 2844 The 'subArc' attribute type is intended to hold one (1) or more LDAP 2845 DNs for the purpose of enumerating all subordinate registrations that 2846 reside beneath a given registration, or to reference the (lexically) 2847 first subordinate registration only. 2849 If a registration does not possess a value for 'subArc', this is 2850 indicative of one of the following conditions: 2852 - No subordinate registration manifest exists, and management 2853 of such elements is wholly up to the client, or ... 2854 - No subordinate registrations exist at this time, or ... 2855 - Subordinate registrations exist, but are not visible to 2856 the indicated identity (e.g.: access control) 2858 If only a single 'subArc' value exists for the registration, this can 2859 mean one of the following: 2861 - There are a very large number of subordinate registrations, 2862 and only the first registration is referenced, or ... 2863 - There is only one (1) subordinate registration 2865 dn: n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2866 objectClass: x660SubArc 2867 identifier: example 2868 subArc: n=0,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2870 If two (2) or more 'subArc' values exist for the registration, this 2871 SHOULD be interpreted as a complete manifest of subordinate entries. 2872 As such, costly enumeration of registrations (through a singleLevel 2873 LDAP Search Request, per Section 4.5.1.2 of [RFC4511]) should not be 2874 necessary. 2876 dn: n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2877 objectClass: x660SubArc 2878 identifier: example 2879 subArc: n=0,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2880 subArc: n=1,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2881 ... many DNs omitted for brevity ... 2882 subArc: n=200,n=999,n=2,ou=OID,ou=X660,dc=example,dc=com 2884 If the given 'subArc' manifest is perceived to be exceedingly large, 2885 and DSA utilization and/or performance are concerns, it is strongly 2886 RECOMMENDED the client application support the use of a local cache 2887 to prevent repeated and wasteful calls of certain large entries. 2888 This concept is out of scope for this document. 2890 3.6.1.2.2.1. Awareness of Subordinate Registration Constraints 2892 Any DUA or service interacting with RAs based upon this specification 2893 for the purpose of enumerating and/or allocating registrations MUST 2894 always check for the presence of definitions of both the 'isLeafNode' 2895 attribute type (per Section 2.1.14) and the 'isFrozen' attribute type 2896 (per Section 2.1.15) before any further subordinate traversals or 2897 allocations may take place beneath a given registration. 2899 If an 'isLeafNode' value of "TRUE" is present for a registration, the 2900 requesting entity SHALL NOT enumerate any subordinate entries for any 2901 reason, nor will any new subordinate allocations take place. 2903 If an 'isFrozen' value of "TRUE" is present for a given registration, 2904 but 'isLeafNode' is "FALSE" or otherwise UNDEFINED, the requesting 2905 entity SHOULD enumerate any subordinate entries already present, but 2906 SHALL NOT create any new registrations. 2908 A value of "TRUE" for 'isLeafNode' attribute type SHALL ALWAYS imply 2909 an equal value for 'isFrozen'. 2911 Neither of these attribute types are meant for use in access control 2912 contexts. Instead, see the 'registrationStatus' attribute type (per 2913 Section 2.1.13), as well as the associated remarks in Section 5, for 2914 information on security-specific restrictions relating to subordinate 2915 registration access and privileges. 2917 3.6.1.2.3. Use of Sibling Adjacency Attribute Types 2919 Within the confines of this specification, sibling registration 2920 adjacency can be depicted as follows: 2922 current registration 2923 (2.999.140) 2924 | 2925 << antecedent/left V subsequent/right >> 2926 +---+--------+---+---+---+--------+---+ 2927 | 0 |........|139|140|141|........|200| 2928 +---+--------+---+---+---+--------+---+ 2929 | \ / | 2930 farthest nearest farthest 2932 In order to effectively express such horizontal relationships in a 2933 logical hierarchical data structure, and to foster a low-cost means 2934 for ascertaining these relationships, four (4) DN-based attribute 2935 types are made available: 2937 - 'leftArc', as defined in Section 2.1.22 2938 - 'firstArc', as defined in Section 2.1.23 2939 - 'rightArc', as defined in Section 2.1.24 2940 - 'finalArc', as defined in Section 2.1.25 2942 The 'leftArc' and 'rightArc' attribute types are assigned to entries 2943 in a manual fashion, as the relationships are globally unique in that 2944 no single registration will share the same "left" and "right" sibling 2945 combination as any other registration. As such, the nature of these 2946 two (2) attribute types precludes use of virtual value assignments. 2948 The 'firstArc' and 'finalArc' attribute types MAY be assigned in one 2949 (1) of the following three (3) ways: 2951 - In literal fashion (manually), or ... 2952 - Through the use of Collective Attribute [RFC3671] support, or ... 2953 - Through the use of an implementation-specific attribute value 2954 virtualization feature 2956 Any given sibling registration pool, regardless of its size, will 2957 always share the same 'firstArc' and 'finalArc' attribute values for 2958 every registration contained therein. As such, Directory architects 2959 MAY opt to leverage or otherwise extend these attribute types for 2960 virtualization purposes, a topic out of scope for this document. 2962 If these four (4) attribute types are not defined for a registration, 2963 use of an ordered 'subArc' manifest derived from the registration's 2964 parent, OR a (costly) singleLevel search (per Section 4.5.1.2 of 2965 [RFC4511]) below the superior (parent) registration, are the only 2966 other feasible ways to ascertain sibling adjacency. For more details 2967 on this topic, see Section 3.6.1.2.2. 2969 Another practical use for these attribute types is in case a finite 2970 'registrationRange' value exists in a range of non-contiguous sibling 2971 entries. Use of these attribute types may negate the need for costly 2972 range "size checks". See Section 2.1.12 for more details. 2974 In cases where a collection of sibling entries is prone to continued 2975 growth, directory architects are advised to maintain the effective 2976 'finalArc' value(s) regularly, if defined at all. Such growth will 2977 continue in right-handed (subsequent) fashion, and thus the so-called 2978 "final registration" will shift after a time, rendering a stale value 2979 inaccurate in nature. 2981 3.7. DSA Resource Utilization and Administrative Costs 2983 Much of the previous subsection advocated the use of low-cost client 2984 driven methods for finding and circumnavigating registrations using 2985 only baseObject-scoped LDAP Search Requests (per Section 4.5.1.2 of 2986 [RFC4511]). This section offers some considerations relating to the 2987 DSA's relation to these concepts. 2989 Directory architects who choose to adopt some or all of the precepts 2990 defined in this specification will inevitably encounter a situation 2991 in which they're forced to consider one or more of the following: 2993 - Overall size of DIT is a concern (in terms of bytes 2994 and/or entries) 2995 - Effort required to maintain DIT content for all adopted 2996 attribute types is not feasible 2997 - Client-driven resource utilization is problematic 2999 The following subsections covers these concerns from a variety of 3000 standpoints. 3002 3.7.1. Literal vs. Composite Values 3004 Consider the following scenario: 3006 A directory architect adopts certain elements from this specification 3007 in a minimalistic three-dimensional fashion. In this case, only the 3008 'n', 'unicodeValue' and 'identifier' attribute types are maintained 3009 for any given registration. This is due to the prohibitively costly 3010 and/or time-consuming nature of maintaining any other attributes. 3012 A user consuming this information wants to obtain 'iRI' as well as 3013 'asn1Notation' values for any given registration. Because these 3014 attribute types are not maintained in literal fashion, this forces 3015 the user to traverse the directory through multiple individual LDAP 3016 baseObject Search Requests (per Section 4.5.1.2 of [RFC4511]), so as 3017 to derive the needed component values. 3019 The drawbacks of this strategy are as follows: 3021 - Tedious for the user 3022 - Increased number of requests to DSA 3023 - Extrapolation or prediction of composite values 3024 is not always possible 3026 The merits of this strategy are as follows: 3028 - Smaller data footprint 3029 - Lower overall data maintenance costs 3031 There are several attributes that, in some form or another, contain 3032 data that MAY reside in another attribute assigned to the same entry. 3034 - 'identifier' (a.k.a.: 'nameForm') and 'n' (a.k.a.: 'numberForm') 3035 are the sole components of 'nameAndNumberForm' 3036 - 'nameAndNumberForm' is (often) the iterative component of the 3037 'asn1Notation' type, with outer "curly brace encapsulation" 3038 (e.g.: "{...}") 3039 - 'unicodeValue' and 'n' are (often) the components of 'iRI', using 3040 a solidus (/) prefix and delimitation scheme 3041 - 'n' is the iterative component of 'dotNotation', using a dot (.) 3042 delimitation scheme comprised of two (2) or more elements 3043 - 'additionalIdentifier' is a multi-valued attribute type populated 3044 solely by one or more non-primary 'identifier' (or 'nameForm') 3045 values 3047 With such cases in mind, directory architects are advised to plan 3048 attribute support carefully, as well as manage expectations of the 3049 end-user. 3051 Directory architects SHOULD populate some of the above attribute 3052 types in cases where their true value may not be possible to predict 3053 or extrapolate. One example of this is the 'iRI' value for the OID 3054 assigned to 'asn1' (2.1). While its logical 'unicodeValue'-based 3055 path might produce an effective value of "/Joint-ISO-ITU-T/ASN.1", 3056 which is not its true 'iRI' - the correct value is "/ASN.1". 3058 3.7.2. Subtree Search Operations 3060 Use of wholeSubtree, or Subtree, LDAP Search Operations (as defined 3061 in Section 4.5.1.2 of [RFC4511]) MAY be required in cases where a 3062 registration lookup is needed, but only a single abstract piece of 3063 information is known by the user. Frequently sought-after attribute 3064 types of this nature include: 3066 - 'nameAndNumberForm' 3067 - 'identifier' 3068 - 'additionalIdentifier' 3069 - 'iRI' 3070 - 'longArc' 3071 - 'stdNameForm' 3072 - 'unicodeValue' 3074 Given an effective LDAP Search baseObject (per Section 4.5.1.1 of 3075 [RFC4511]), and depending on the nature of the information requested, 3076 such operations may be especially expensive. Should these operations 3077 be deemed necessary, directory administrators are STRONGLY advised 3078 to take appropriate performance-level actions to ensure fast request 3079 responses. This may be achieved through a variety of DSA-level 3080 optimizations -- concepts that are out of scope for this document. 3082 It may also be prudent for directory administrators to place limits 3083 on the number of entries that can be returned as a result of a given 3084 request. This is especially true if the RA DSA supports substring 3085 search filters (e.g.: '(identifier=a*)') that would almost certainly 3086 return many results. 3088 4. IANA Considerations 3090 There are no requests to IANA in this document. 3092 5. Security Considerations 3094 This document focuses on providing flexible directory models and LDAP 3095 schema elements in order to serve OID-related entries, and to allow 3096 for an LDAP-based means for OID resolution. No assumptions are made 3097 with regards to confidentiality of entries. 3099 If some or all of the [X.660] data in a given directory is sensitive 3100 in nature, directory architects MUST take appropriate steps to secure 3101 this information. Although such concepts are out of scope for this 3102 document, specific attribute types were made available in Section 3103 2 to aid directory architects in this regard. 3105 - 'discloseTo', defined in Section 2.1.26, allows the declaration 3106 of one or more LDAP DNs authorized to read the necessary content 3107 - 'registrationStatus', defined in Section 2.1.13, facilitates 3108 access control evaluations of subtrees with a top-level parent 3109 that is assigned a value of "private" 3110 - 'currentAuthority' and/or 'sponsor', defined in Sections 2.1.28 3111 and 2.1.65 respectively, MAY be used to refer to identities that 3112 are authorized to allocate new registrations, as well to make 3113 certain changes to existing ones 3115 Directory architects SHOULD employ custom attribute types and/or 3116 an enhanced DSA configuration for access control purposes if the 3117 above attribute types are unsuitable in some way. 3119 5.1. Modification Identity Obfuscation 3121 If the operational attributes 'creatorsName' and/or' 'modifiersName' 3122 (as defined in Sections 3.4.1 and 3.4.3 of [RFC4512] respectively) 3123 are exposed, directory architects MAY opt to use Proxy Authorization 3124 Controls, per [RFC4370], to allow an asserted (proxied) identity to 3125 effect the necessary registration changes without exposing the true 3126 authentication identity. 3128 An appropriate proxy identity could be the distinguished name of the 3129 registrant referenced by the 'currentAuthority' or 'sponsor' types, 3130 or even a given registration entry itself. In either case, this will 3131 require [RFC4370] functionality, a topic that is well out of scope 3132 for this document. 3134 5.2. Registrant Privacy 3136 Some public RA services are known to offer privacy options that are 3137 meant to allow redaction of contact-related attributes such as for 3138 telephone numbers and/or email and postal addresses from public view. 3140 In such cases, the directory architect(s) in question SHOULD take the 3141 time to set appropriate security and access control mechanisms so as 3142 to protect the data from undesirable entities, such as spammers. This 3143 MAY include methodologies such as: 3145 - Requiring account registration and authentication to access such 3146 personal data via the RA DSA 3147 - Limiting disclosure of personal data to administrative personnel 3148 and the relevant registrant only 3149 - Requiring deliberate baseObject LDAP Search requests only (per 3150 Section 4.5.1.2 of [RFC4511]), which would result in registrant 3151 entries only being reachable by singular references through an 3152 OID registration 3154 Overall, the public hosting of any contact information, regardless of 3155 its nature, is an enormous responsibility that SHOULD NEVER be taken 3156 lightly. 3158 6. References 3160 6.1. Normative References 3162 [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an 3163 Object Class to Hold Uniform Resource Identifiers (URIs)", 3164 RFC 2079, January 1997. 3166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3167 Requirement Levels", BCP 14, RFC 2119, March 1997. 3169 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 3170 (LDAP): Directory Information Models", RFC 4512, June 3171 2006. 3173 [RFC4517] Legg, Ed., S., "Lightweight Directory Access Protocol 3174 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 3175 2006. 3177 [RFC4519] Sciberras, Ed., A., "Lightweight Directory Access Protocol 3178 (LDAP): Schema for User Applications", RFC 4519, June 3179 2006. 3181 [RFC4524] Zeilenga, K., "Lightweight Directory Access Protocol 3182 (LDAP): COSINE LDAP/X.500 Schema", RFC 4524, June 2006. 3184 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3185 2119 Key Words", RFC 8174, May 2017. 3187 [X.660] International Telecommunication Union - Telecommunication 3188 Standardization Sector, "General procedures and top arcs 3189 of the international object identifier tree", ITU-T X.660, 3190 July 2011. 3192 [X.680] International Telecommunication Union - Telecommunication 3193 Standardization Sector, "Abstract Syntax Notation One 3194 (ASN.1): Specification of basic notation", ITU-T X.680, 3195 July 2002. 3197 6.2. Informative References 3199 [RFC1155] Rose, M., "Structure and Identification of Management 3200 Information for TCP/IP-based Internets", RFC 1155, May 3201 1990. 3203 [RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight 3204 Directory Access Protocol (LDAP) Directories", RFC 3296, 3205 July 2002. 3207 [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight 3208 Directory Access Protocol (LDAP)", RFC 3671, December 3209 2003. 3211 [RFC4370] Weltman, R., "Lightweight Directory Access Protocol 3212 (LDAP): Proxy Authorization Control", RFC 4370, February 3213 2006. 3215 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 3216 (LDAP): Technical Specification Road Map", RFC 4510, June 3217 2006. 3219 [X.501] International Telecommunication Union - Telecommunication 3220 Standardization Sector, "The Directory: Models", ITU-T 3221 X.501, October 2016. 3223 [PRIVATE] IANA, "Private Enterprise Numbers", 3224 https://www.iana.org/assignments/enterprise-numbers. 3226 Author's Address 3228 Jesse Coretta 3229 Palm Springs, CA 92262 3230 United States 3232 Email: jesse.coretta@icloud.com