idnits 2.17.1 draft-viathinksoft-oidip-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2021) is 1105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCyyyy' is mentioned on line 889, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Marschall 3 Intended Status: Informational ViaThinkSoft 4 Expires: October 22, 2021 April 2021 6 Retrieving information about Object Identifiers 7 using a text-based protocol 8 draft-viathinksoft-oidip-00 10 Abstract 12 This document defines a method for retrieving information about 13 Object Identifiers (OIDs) and their associated Registration 14 Authorities (RAs) using a text-based protocol, in a way that is both 15 human-readable and machine-readable. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 9, 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1 Authentication Tokens . . . . . . . . . . . . . . . . . . . 5 55 2.2 Request ABNF Notation . . . . . . . . . . . . . . . . . . . 5 56 3 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Format and Encoding . . . . . . . . . . . . . . . . . . . . 6 58 3.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2.1 Query-Section (Information about Query and Result) . . 7 60 3.2.2 Object-Section (Information about the OID) . . . . . . 8 61 3.2.3 RA-Section (Information about the Current RA) . . . . . 11 62 3.2.4 Sections for Previous Registration Authorities . . . . 13 63 3.3 Digital Signature . . . . . . . . . . . . . . . . . . . . . 13 64 3.4 Date/Time Format . . . . . . . . . . . . . . . . . . . . . 13 65 3.4.1 Date/Time Format ABNF Notation . . . . . . . . . . . . 14 66 3.4.2 Date/Time Format Examples . . . . . . . . . . . . . . . 14 67 4 Referral . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 5 Full Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 5.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 5.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 6 Alternative Namespaces . . . . . . . . . . . . . . . . . . . . 17 72 6.1 Example: UUID Namespace . . . . . . . . . . . . . . . . . . 18 73 7 Internationalization Considerations . . . . . . . . . . . . . . 18 74 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 75 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 76 9.1 Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 20 77 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 10.1 Normative References . . . . . . . . . . . . . . . . . . . 20 79 10.2 Informative References . . . . . . . . . . . . . . . . . . 21 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1 Introduction 85 An Object Identifier (OID) is an extensively used identification 86 mechanism jointly developed by ITU-T and ISO/IEC for naming any type 87 of object with a globally unambiguous name. OIDs provide a 88 persistent identification of objects based on a hierarchical 89 structure of Registration Authorities (RA), where each parent has an 90 Object Identifier and allocates Object Identifiers to child nodes. 91 More information about Object Identifiers can be found in 92 Recommendation ITU-T X.660 (2011) | ISO/IEC 9834-1:2012 [X660]. 94 There are a few methods of retrieving information about an OID, like: 96 (A) Searching through web repositories like 97 or . This has the disadvantage 98 that the information is usually not machine-readable without 99 functionalities like an API. 101 (B) Retrieving information using the Object Identifier Resolution 102 System (ORS) as defined in Recommendation ITU-T X.672 (2010) | 103 ISO/IEC 29168-1:2011 [X672]. This has the disadvantage that 104 Registration Authorities need to include specific DNS Resource 105 Records to their domains, and additionally, all RAs of the superior 106 OIDs must implement the ORS. 108 This document describes an additional method for retrieving 109 information about OIDs, which is both human-readable and machine- 110 readable. 112 Three of many possible use-case scenarios are: 114 (1) Many web-browsers and Operating Systems can handle ITU-T X.509 115 certificates [X509] and usually contain a viewer application that 116 shows the contents of these certificates. Attributes that are 117 unknown by the application are either only displayed by their OID, or 118 hidden to avoid confusion to the user. With OID-IP, the application 119 could query the name of these unknown OIDs or even retrieve 120 instructions on how the data described by this OID can be parsed and 121 displayed. 123 (2) Applications that handle SNMP (Simple Network Management 124 Protocol) [RFC1157] might need information about additional MIB files 125 or their OIDs. OID-IP could aid these applications in gathering the 126 required information. 128 (3) In directory services like LDAP (Lightweight Directory Access 129 Protocol) [RFC4511], applications could query the name of attributes 130 that are described by an OID the application doesn't know. 132 1.1 Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 In this document, "RA" is an abbreviation for "Registration 139 Authority", "OID" is an abbreviation for "Object Identifier" and 140 "OID-IP" is an abbreviation for "Object Identifier Information 141 Protocol". 143 2 Request 145 OID-IP is a text-based protocol similar to the WHOIS protocol 146 specified in RFC 3912 [RFC3912]. 148 An OID-IP server listens on TCP port XXX for requests from OID-IP 149 clients. The OID-IP client makes a text request to the OID-IP 150 server, then the OID-IP server replies with text content. All 151 requests are terminated with ASCII CR followed by ASCII LF. The 152 response contains multiple lines of text, separated by ASCII CR 153 followed by ASCII LF. The OID-IP server closes its connection as 154 soon as the output is finished. The closed TCP connection is the 155 indication to the client that the response has been received. 157 Alternatively to TCP port XXX, an OID-IP server can listen to the 158 WHOIS TCP port 43. Existing WHOIS servers can add the 159 functionalities described in this document in addition to their usual 160 operation, i.e. they may accept queries beginning with "oid:" as well 161 as other types of queries. 163 During the request, the client sends a query beginning with "oid:", 164 followed by an OID in dot-notation, as defined in RFC 3061, section 2 165 [RFC3061], but with the following differences: 167 (1) The OID MAY contain a leading dot. 169 (2) To query the root of the OID tree, the OID MUST be either missing 170 or consisting only of a single dot. 172 Examples of valid queries are: 174 oid: 175 oid:. 176 oid:2.999 177 oid:.2.999 179 All OIDs MUST be interpreted as absolute OIDs. Relative OIDs (e.g. 181 relative to the OID of the Registration Authority operating the OID- 182 IP service) are not allowed. 184 The namespace identifier (i.e. "oid") MUST be written in lower-case. 186 2.1 Authentication Tokens 188 Some organizations might not want to present their OID information 189 (or part of it) to the public, e.g. for reasons like privacy or 190 confidentiality. Therefore, at the end of the query, the client can 191 append case-sensitive, non-empty alphanumeric authentication tokens 192 to control the display of confidential information. 194 Each authentication token MUST be prepended by a dollar sign ("$"). 196 Examples of valid queries are: 198 oid:2.999$firstToken 199 oid:2.999$firstToken$secondToken 201 Please note that authentication tokens are only weak protection. For 202 more information, see section 8 "Security Considerations". 204 2.2 Request ABNF Notation 206 To define the query string, the following Augmented BNF definitions 207 will be used. They are based on the ABNF styles of RFC 5234 208 [RFC5234]. 210 query = namespace ":" optional-oid *( "$" authtoken ) 212 namespace = %x6F %x69 %x64 ; "oid" 214 optional-oid = [ "." ] [ oid ] 216 oid = unsigned-number *( "." unsigned-number ) 218 authtoken = 1*( char-or-digit ) 220 digit = %x30-39 ; 0-9 222 nonzero-digit = %x31-39 ; 1-9 224 uppercase-char = %x41-5A ; A-Z 226 lowercase-char = %x61-7A ; a-z 228 char-or-digit = uppercase-char / lowercase-char / digit 229 unsigned-number = "0" / nonzero-digit *( digit ) 231 3 Response 233 3.1 Format and Encoding 235 (1) The response MUST be UTF-8 encoded (as defined in RFC 3629 236 [RFC3629]), without Byte-Order-Mark (BOM). 238 (2) The response contains multiple lines with field names and values, 239 which MUST be separated by a double colon (":"). Whitespace 240 characters after the double colon are allowed. 242 (3) If possible, each line SHOULD be limited to 80 characters, 243 including the field name, double colon, value, and whitespaces. 245 (4) Field names and values MUST be treated case-sensitive. 247 (5) If a value needs to be split into multiple lines, e.g. if the 248 line would exceed the length limit, the same field name including 249 double colon MUST be repeated at the beginning of the next line. 251 (6) If an attribute has multiple values (e.g. multiple Unicode 252 labels, alternative email addresses, etc.), each value MUST be 253 written in a new line with the same field name. 255 (7) Lines with the same field name SHALL be kept together. 257 (8) Comment lines MUST start with a percent sign ("%") at the 258 beginning of a line, without prepending whitespaces. They MUST NOT 259 be evaluated by machines (except for signature validation, as 260 mentioned in section 3.3 "Digital Signature"). 262 3.2 Structure 264 A response consists of sections, which SHOULD be separated by at 265 least one empty line and/or comment line. 267 This document specifies the following sections (which SHALL stay in 268 this order): 270 (1) Query-Section which contains the request and the result. This 271 section MUST start with the field "query". 273 (2) Object-Section which contains information about the OID. This 274 section MUST start with the field "object". 276 (3) RA-Section which contains information about the current 277 Registration Authority. This section MUST start with the field "ra". 279 (4) Optional RA-Sections containing information about RAs that were 280 previously in charge of managing the OID. 282 The OID-IP service MAY define additional sections after any of these 283 sections, but the Query-Section MUST be the first section in the 284 response. 286 3.2.1 Query-Section (Information about Query and Result) 288 This section MUST always be present and MUST start with the field 289 "query". It MUST be the first section in the response. 291 Possible fields are: 293 (1) "query" MUST be present and contain the request of the client 294 (beginning with the namespace identifier and double colon, i.e. 295 "oid:"). Canonization or sanitation (like removing a leading dot) 296 SHOULD NOT be applied at this step. Authentication tokens SHOULD be 297 omitted, though. 299 (2) "result" MUST be present and SHALL be one of the following 300 values: 302 "Found" means that the OID-IP service can verify that the 303 requested OID exists. The following sections will contain 304 information about this OID. 306 "Not found; superior object found" means that the OID-IP service 307 cannot verify that the requested OID exists, or it denies that 308 the OID exists (e.g. because it is confidential). However, the 309 OID-IP service knows a superior OID which does exist. The 310 following sections will contain information about that superior 311 OID instead. 313 "Not found" means that the OID-IP service cannot verify that the 314 requested OID exists, or it denies that the OID exists (e.g. 315 because it is confidential). Additionally, the OID-IP service 316 does not have information about any superior OID, or their 317 existence is also denied. 319 "Service error" means that an internal error occurred, or that 320 the system is in maintenance mode. The client should try again 321 later. 323 (3) "distance" SHOULD be present if it is applicable in the requested 324 namespace (it is always applicable for OIDs) and if the result is 325 "Not found; superior object found". A distance of 1 means that the 326 direct parent was found. A distance of 2 means that the grand-parent 327 was found, etc. 329 (4) "message" SHOULD be present if the result is "Service error". It 330 contains a message explaining why the service is not available (e.g. 331 displaying an error message). It MUST NOT be present if the result 332 has a different value. 334 The OID-IP service SHOULD NOT add additional fields to this section. 336 3.2.2 Object-Section (Information about the OID) 338 This section MUST be present if the result is "Found" or "Not found; 339 superior object found". It MUST start with the field "object". It 340 MUST NOT be present if the result is "Not found" or "Service error". 342 Possible fields are: 344 (1) "object" contains the OID in dot-notation, prepended by the 345 namespace identifier and double colon ("oid:"). This field MUST be 346 present. 348 (2) "status" MUST be present and SHALL be one of the following 349 values: 351 "Information available" means that information about the OID is 352 fully available. 354 "Information partially available" means that part of the 355 information about the OID is not available. Possible reasons 356 could be that part of the information is redacted due to 357 confidentiality, or the OID-IP service only knows basic 358 information, while the full information can be found somewhere 359 else (e.g. at a referred OID-IP service). The field "attribute" 360 MAY be used with the value "confidential". 362 "Information unavailable" means that the information about the 363 OID is missing, redacted due to confidentiality, or otherwise 364 unavailable. The field "attribute" MAY be used with the value 365 "confidential". 367 (3) "name" (OPTIONAL) contains the name of the OID. It SHOULD be as 368 short as possible. 370 (4) "description" (OPTIONAL) contains a short description of the OID. 371 The description SHOULD only be a single sentence. 373 (5) "information" (OPTIONAL) contains additional information, e.g. 374 Management Information Base (MIB) definitions. 376 (6) "url" (OPTIONAL, multiple values allowed) contains a URL (as 377 defined in RFC 3986 [RFC3986]) leading to more information about the 378 OID. 380 (7) "asn1-notation" (OPTIONAL, multiple values allowed) contains one 381 or more possible notations in the ASN.1 syntax, as defined in 382 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 32.3 383 [X680], e.g. {joint-iso-itu-t(2) example(999)}. 385 Note: A line-break, to break up lines that are too long, as 386 defined in section 3.1 ("Format and Encoding") SHOULD be used. 387 This is no problem because multiple ASN.1 notations can be 388 distinguished by their opening curly bracket and their closing 389 curly bracket. 391 (8) "iri-notation" (OPTIONAL, multiple values allowed) contains one 392 or more possible notations in the OID-IRI syntax, as defined in 393 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 34.3 394 [X680] (but without quotation marks), e.g. /Joint-ISO-ITU-T/Example. 396 Note: A line-break, to break up lines which are too long, as 397 defined in section 3.1 ("Format and Encoding") SHALL NOT be used, 398 otherwise, it would be ambiguous if the line-break was used to 399 shorten the line, or if the line-break indicates a new value in 400 case multiple OID-IRI notations are supplied. 402 (9) "identifier" (OPTIONAL, multiple values allowed) contains an 403 alphanumeric identifier ("NameForm") as defined in Recommendation 404 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 12.3 [X680]. 406 (10) "standardized-id" (OPTIONAL, multiple values allowed) contains 407 an alphanumeric identifier that has a standardized "NameForm", i.e. 408 in ASN.1 notation, it can be written without its associated number. 409 See more information in Recommendation ITU-T X.680 (2015) | ISO/IEC 410 8824-1:2015, clause 32.7 [X680]. 412 (11) "unicode-label" (OPTIONAL, multiple values allowed) contains a 413 Non-integer Unicode label, as defined in Recommendation ITU-T X.680 414 (2015) | ISO/IEC 8824-1:2015, clause 12.27 [X680]. 416 (12) "long-arc" (OPTIONAL, multiple values allowed) contains a Non- 417 integer Unicode label that can be used as the first identifier in an 418 OID Internationalized Resource Identifier (OID-IRI), shortening it. 419 More information can be found in Recommendation ITU-T X.660 (2011) | 420 ISO/IEC 9834-1:2012, clause 3.5.8 [X660]. 422 (13) "oidip-service" (OPTIONAL) contains an IP address or hostname of 423 a system that offers an OID-IP service that can supply information 424 about the OID and/or its subordinate OIDs, followed by a double-colon 425 (:) and a port number. If the result is "Found" (i.e. the OID is 426 existing in the local database), then the information "oidip-service" 427 is only informational; its existence is most likely a hint that 428 subordinate OIDs will be found at that OID-IP server. If the result 429 is "Not found; superior object found", then the client SHOULD query 430 the referred OID-IP server to receive more information about the OID. 431 See more information in section 4 "Referral". 433 (14) "attribute" (OPTIONAL, multiple values allowed) contains 434 attributes of the OID. An attribute MUST be one of the following 435 values: 437 "confidential" means that information about the OID or part of it 438 is confidential. 440 "draft" means that the allocation of the OID is not yet official 441 and the information is subject to change without notice. This 442 includes deletion and relocation. 444 "frozen" means that no more child OIDs can be created under this 445 OID, e.g. because the RA has stopped operating, but the existing 446 child OIDs stay valid. 448 "leaf" means that no child OIDs can be allocated under this OID. 449 The field "subordinate" SHALL therefore not be present. 451 "no-identifiers" means that the RA is not allocating alphanumeric 452 identifiers. 454 "no-unicode-labels" means that the RA is not allocating Non- 455 integer Unicode labels. 457 "retired" means that the OID is withdrawn, revoked, retired, 458 expired, etc. Please consult Recommendation ITU-T X.660 (2011) | 459 ISO/IEC 9834-1:2012 [X660] for more information about such cases. 461 (15) "parent" (OPTIONAL) contains the OID of the nearest known parent 462 OID, prepended by namespace identifier and double colon, i.e. "oid:". 463 It MAY be followed by additional human-readable information, e.g. a 464 description or a list of ASN.1 identifiers. There SHALL be at least 465 1 whitespace in between. 467 (16) "subordinate" (OPTIONAL, multiple values allowed) contains a 468 list of subordinate OIDs, prepended by namespace identifier and 469 double colon, i.e. "oid:". It MAY be followed by additional human- 470 readable information, e.g. a description or a list of ASN.1 471 identifiers. There SHALL be at least 1 whitespace in between. 473 (17) "created" (OPTIONAL) contains the date and time (as specified in 474 section 3.4 "Date/Time Format") when the OID was first allocated by 475 the RA of the superior OID. 477 (18) "updated" (OPTIONAL) contains the date and time (as specified in 478 section 3.4 "Date/Time Format") when the OID information was last 479 updated. 481 Additional fields can be defined by the OID-IP service. The field 482 names SHALL only consist of the lower-case letters "a..z", hyphens 483 ("-"), and numbers, and SHOULD be written in the English language. 484 The field name MUST NOT begin or end with a hyphen and a hyphen MUST 485 NOT be followed by another hyphen. 487 3.2.3 RA-Section (Information about the Current RA) 489 This section MUST NOT be present if the result is "Not found" or 490 "Service error", otherwise it MAY be present. If it is present, it 491 MUST start with the field "ra". 493 Possible fields are: 495 (1) "ra" contains a general name of the RA, like the name of a 496 person, the name of a group, or the name of an organization. This 497 field MUST be present. 499 (2) "ra-status" MUST be present and SHALL be one of the following 500 values: 502 "Information available" means that information about this RA is 503 fully available. 505 "Information partially available" means that part of the 506 information is not available. A possible reason could be that 507 part of the information is redacted due to confidentiality. The 508 field "attribute" MAY be used with the value "confidential". 510 "Information unavailable" means that the data is missing (if the 511 OID-IP service only knows the name of the RA and nothing else), 512 redacted due to confidentiality, or otherwise unavailable. The 513 field "attribute" MAY be used with the value "confidential". 515 (3) "ra-contact-name" (OPTIONAL, multiple values allowed) contains 516 the name of a person responsible for the allocation of subordinate 517 OIDs, in case "ra" is a group or organization. 519 (4) "ra-address" (OPTIONAL) contains the physical location of the RA. 520 While a fully qualified postal address is recommended, the field can 521 also just contain a rough location like city and country name, state 522 and country name, or just the country name, etc. The name of the 523 country SHOULD always be present. 525 (5) "ra-phone" (OPTIONAL, multiple values allowed) contains a 526 landline phone number of the Registration Authority. It SHOULD be 527 written in the international number format specified in 528 Recommendation ITU-T E.164 (2010) [E164], e.g. +1 206 555 0100. 530 (6) "ra-mobile" (OPTIONAL, multiple values allowed) contains a mobile 531 phone number of the Registration Authority. It SHOULD be written in 532 the international number format specified in Recommendation ITU-T 533 E.164 (2010) [E164], e.g. +1 206 555 0100. 535 (7) "ra-fax" (OPTIONAL, multiple values allowed) contains a fax 536 number of the Registration Authority. It SHOULD be written in the 537 international number format specified in Recommendation ITU-T E.164 538 (2010) [E164], e.g. +1 206 555 0100. 540 (8) "ra-email" (OPTIONAL, multiple values allowed) contains an email 541 address of the Registration Authority. 543 (9) "ra-url" (OPTIONAL, multiple values allowed) contains a URL (as 544 defined in RFC 3986 [RFC3986]) leading to more information about the 545 RA (usually the website of the RA). 547 (10) "ra-attribute" (OPTIONAL, multiple values allowed) contains 548 attributes of the RA. An attribute MUST be one of the following 549 values: 551 "confidential" means that the information about the RA or part of 552 it is confidential. 554 "retired" means that the RA is defunct. If this attribute is set 555 to the current RA, then the OID MUST have the attribute "frozen" 556 (until the responsibility is transferred to a non-defunct RA, or 557 until the current RA becomes active again). 559 (11) "ra-created" (OPTIONAL) contains the date and time (as specified 560 in section 3.4 "Date/Time Format") when the RA was created/registered 561 in the database. 563 (12) "ra-updated" (OPTIONAL) contains the date and time (as specified 564 in section 3.4 "Date/Time Format") when the RA information was last 565 modified. 567 Additional fields can be defined by the OID-IP service, but they MUST 568 begin with "ra-". The field names SHALL only consist of the lower- 569 case letters "a..z", hyphens ("-"), and numbers, and SHOULD be 570 written in the English language. The field name MUST NOT begin or 571 end with a hyphen and a hyphen MUST NOT be followed by another 572 hyphen. 574 3.2.4 Sections for Previous Registration Authorities 576 To optionally display information about RAs that were previously in 577 charge of managing the OID, a new section per RA can be added with 578 the following field name prefixes: 580 "ra-" is the prefix of the current Registration Authority. 582 "ra1-" is the prefix of the first RA. It is the very first person or 583 company to whom the OID was allocated by the RA of the superior OID. 584 "ra2-" is the prefix of the second RA, after the responsibility has 585 been transferred. etc. 587 The definition of these sections is identical to the definition of 588 the RA-Section (described in section 3.2.3 "RA-Section"), just with a 589 different prefix. 591 The history does not need to be complete, e.g. it is no problem to 592 only serve information about the first and the current RA, or only 593 serve information about the current RA. 595 3.3 Digital Signature 597 If integrity/authenticity is required, the whole response can be 598 signed, e.g. by using S/MIME, RSA, or PGP. This document does not 599 describe a mechanism for detecting which signature method was used. 600 The creation and verification of the signature are therefore 601 implementation-specific and no interoperability regarding signature 602 creation and validation is given at this time. 604 Depending on the signature method being used, various things need to 605 be appended and/or prepended to the response. These additional lines 606 MUST be prepended by a percent sign ("%") to avoid that an 607 application confuses these additional lines (e.g. lines belonging to 608 a PGP header, as defined in RFC 4880 [RFC4880]) with parts of the 609 actual OID-IP response. 611 3.4 Date/Time Format 613 Date/Time references SHALL be formatted as described in 614 section 3.4.1. 616 If parts of the date/time reference are uncertain, then they SHOULD 617 be omitted until the date/time reference has the highest correctness. 619 Examples of valid date/time references can be found in section 3.4.2. 621 3.4.1 Date/Time Format ABNF Notation 623 To define the format of a Date/Time reference, the following 624 Augmented BNF definitions will be used. They are based on the ABNF 625 styles of RFC 5234 [RFC5234]. 627 date-time = year [ "-" month [ "-" day [ " " time ] ] ] 629 year = 4*4DIGIT 631 month = ( "0" %x31-39 ) / 632 ( "1" %x30-32 ) ; 01-12 634 day = ( "0" %x31-39 ) / 635 ( "1" %x30-39 ) / 636 ( "2" %x30-39 ) / 637 ( "3" %x30-31 ) / ; 01-31 639 time = hour ":" minute [ ":" second ] [ " " timezone ] 641 hour = ( "0" %x30-39 ) / 642 ( "1" %x30-39 ) / 643 ( "2" %x30-33 ) ; 00-23 645 minute = %x30-35 DIGIT ; 00-59 647 second = %x30-35 DIGIT ; 00-59 649 timezone = ( "+" / "-" ) hour minute 651 3.4.2 Date/Time Format Examples 653 Examples of valid date/time references are: 655 2021-04-29 18:32:00 +0200 656 2021-04-29 18:32:00 657 2021-04-29 18:32 +0200 658 2021-04-29 18:32 659 2021-04-29 660 2021-04 661 2021 663 4 Referral 665 By using the field "oidip-service", the OID-IP service can instruct 666 the client to query another OID-IP service that might have more 667 information about the requested OID. 669 If Registration Authorities maintain up-to-date OID-IP service 670 references of their OID delegations, it is possible to automatically 671 retrieve information about any OID. 673 Example: OID "2.999" is owned by Registration Authority "A", 674 operating an OID-IP service at "a.example.com". 676 Registration Authority "A" allocated OID "2.999.1000" to Registration 677 Authority "B" who is operating an OID-IP service at "b.example.com". 679 The client asks a.example.com for information about OID 680 "2.999.1000.1" and should receive the following reply: 682 query: oid:2.999.1000.1 683 result: Not found; superior object found 684 distance: 1 686 object: oid:2.999.1000 687 status: Information available 688 name: Company "B" 689 oidip-service: b.example.com:XXX 691 ra: "B" 692 ra-status: Information unavailable 694 The client is now aware that "a.example.com" only knows OID 695 "2.999.1000", and that there is a reference to another OID-IP service 696 located at "b.example.com". So, the client should then accordingly 697 query "b.example.com", asking for information about OID 698 "2.999.1000.1": 700 query: oid:2.999.1000.1 701 result: Found 703 object: oid:2.999.1000.1 704 status: Information available 705 name: Example OID 1 707 ra: "B" 708 ra-status: Information unavailable 710 5 Full Example 712 5.1 Request 714 oid:2.999 716 5.2 Response 718 query: oid:2.999 719 result: Found 721 object: oid:2.999 722 status: Information available 723 name: Example 724 description: This OID can be used by anyone, for the purposes of 725 description: documenting examples of Object Identifiers. 726 asn1-notation: {joint-iso-itu-t(2) example(999)} 727 iri-notation: /Example 728 identifier: example 729 unicode-label: Beispiel 730 unicode-label: Ejemplo 731 unicode-label: Example 732 unicode-label: Exemple 733 unicode-label: (Korean characters are omitted in this example) 734 unicode-label: (Arabian characters are omitted in this example) 735 unicode-label: (Japanese characters are omitted in this example) 736 unicode-label: (Chinese characters are omitted in this example) 737 unicode-label: (Russian characters are omitted in this example) 738 long-arc: Beispiel 739 long-arc: Ejemplo 740 long-arc: Example 741 long-arc: Exemple 742 long-arc: (Korean characters are omitted in this example) 743 long-arc: (Arabian characters are omitted in this example) 744 long-arc: (Japanese characters are omitted in this example) 745 long-arc: (Chinese characters are omitted in this example) 746 long-arc: (Russian characters are omitted in this example) 747 parent: oid:2 (joint-iso-itu-t) 748 created: 2011-06 749 updated: 2011-09 751 ra: ITU-T SG 17 & ISO/IEC JTC 1/SC 6 752 ra-status: Information unavailable 753 % -----BEGIN RSA SIGNATURE----- 754 % DwnqRtx/ONtPh4onXnrZPl9jF+G50RMLZkSwuClaoH2t/yK8CnYJrmzkzA5+gkfWkoQ 755 % cq+J8J9cvnwXvBfpVHh+7lyNOVW1N016TYFcBt8MVxb6K2KhkKclqeA6wz0kSUuE4qR 756 % ZohzrZBcCP7aLIpcaoVi6QACAt6J0vOvYBaf0= 757 % -----END RSA SIGNATURE----- 759 6 Alternative Namespaces 761 This document describes the retrieval of information about OIDs using 762 the OID-IP protocol. In addition to the OID namespace, the methods 763 described in this document can also be applied to other namespaces 764 like "uuid", "isbn", "gtin" etc. 766 Following things need to be considered if alternative namespaces are 767 implemented: 769 (1) The request MUST be UTF-8 encoded (as defined in RFC 3629 770 [RFC3629]), without Byte-Order-Mark (BOM). 772 (2) The namespace SHALL be a namespace identifier (NID) as defined in 773 RFC 8141 [RFC8141]. 775 (3) The namespace identifier SHALL be written in lower-case (this is 776 already defined in section 2 "Request"). 778 (4) If available, a formal URN namespace identifier (as defined in 779 RFC 8141, section 5.1 [RFC8141]) SHOULD be used, e.g. "uuid" should 780 be used instead of "guid". 782 (5) If things like "Owner", "Creator", "Manager", "Administrator", 783 etc., are relevant to the identifiers in the namespace, then the RA- 784 section as described in section 3.2.3 SHALL be used, even though the 785 word "Registration Authority" might not be appropriate in the 786 terminology of the namespace. 788 (6) The namespace-specific identifier MUST NOT contain dollar signs 789 ("$"), because section 2.1 "Authentication Tokens" defines them as a 790 separator for authentication tokens. 792 (7) The namespace-specific identifier MUST be treated case-sensitive 793 if the namespace distinguishes between lower-case and upper-case. 795 (8) Fields that can only be used in the OID namespace (e.g. "unicode- 796 label") MUST NOT be used for other namespaces. 798 6.1 Example: UUID Namespace 800 The following example shows the retrieval of information about 801 Universally Unique Identifiers (e.g. UUIDs used by the Microsoft 802 Common Object Model, also known as GUIDs). The UUID namespace has no 803 hierarchical structure, which means that the OID-IP service can only 804 respond with the result "Found", "Not found" or "Service error" and 805 the fields "parent" and "subordinate" cannot be used. 807 Request: 809 uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 811 Response: 813 query: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 814 result: Found 816 object: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 817 status: Information available 818 name: Desktop 819 information: GUID can be used in file dialogs as "Custom Place". 821 ra: Microsoft Corp. 822 ra-status: Information unavailable 824 More information about UUIDs can be found in Recommendation ITU-T 825 X.667 (2012) | ISO/IEC 9834-8:2014 [X667]. 827 More information about the Microsoft Common Object Model (COM) can be 828 found at Microsoft Docs . 831 7 Internationalization Considerations 833 This document specifies that the request and response MUST be UTF-8 834 encoded (as defined in RFC 3629 [RFC3629]), without Byte-Order-Mark 835 (BOM). 837 The OID-IP service can define additional field names, but they SHOULD 838 be written in the English language so that there is consistency with 839 the field names defined in this document. 841 8 Security Considerations 843 (1) The knowledge of existence or information about some OIDs could 844 be considered confidential. In this case, the OID-IP service can 845 either deny the existence of the requested OID (by setting the result 846 to "Not found") or redact information in the Object-Section, as 847 defined in section 3.2.2 "Object-Section". 849 (2) Registration Authorities might demand that their data is kept 850 confidential, or at least be partially redacted to increase privacy 851 or as a measurement against spam. In this case, the OID-IP service 852 can redact information in the RA-Section, as defined in section 3.2.3 853 "RA-Section". 855 (3) The OID-IP service can decide if confidential material is omitted 856 or shown, based on authentication mechanisms like white-listing 857 client IP addresses or by using authentication tokens supplied by the 858 client, as defined in section 2.1 "Authentication Tokens". 860 (4) The usage of authentication tokens is not recommended if the 861 traffic between client and server is transmitted through an untrusted 862 network, because the OID-IP protocol is not encrypted. 864 (5) Authentication tokens must have a sufficient length and 865 complexity to avoid successful brute force attacks, or the OID-IP 866 service must limit the number of requests per time. 868 (6) The OID-IP protocol itself has no mechanism for verifying the 869 integrity of data received. Due to this fact, the information should 870 not be trusted if it is transmitted through an untrusted network. If 871 integrity/authenticity is required, the OID-IP response can be 872 signed, as described in section 3.3 "Digital Signature". However, 873 this document does not describe a mechanism for detecting which 874 signature method was used. Therefore, no interoperability of 875 signature creation/validation is given at this time. 877 9 IANA Considerations 879 9.1 Port Numbers 881 This document requires the assignment of a TCP port number. 883 +--------------------+-----------------------------+ 884 | Service Name | oidip | 885 | Transport Protocol | TCP | 886 | Assignee | ... | 887 | Contact | ... | 888 | Description | OID Information Protocol | 889 | Reference | [RFCyyyy] | 890 | Port Number | XXX | 891 +--------------------+-----------------------------+ 893 [Please change "yyyy" to the RFC number allocated to this document 894 before publication.] 896 [Please change "XXX" placed at various locations in this document to 897 the port number allocated by IANA.] 899 10 References 901 10.1 Normative References 903 [E164] "The international public telecommunication numbering 904 plan", Recommendation ITU-T E.164 (2010), November 2010. 905 . 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, 909 DOI 10.17487/RFC2119, March 1997. 910 . 912 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 913 RFC 3061, DOI 10.17487/RFC3061, February 2001. 914 . 916 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 917 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 918 November 2003. 919 . 921 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 922 DOI 10.17487/RFC3912, September 2004. 924 . 926 [RFC3986] Berners-Lee, T., "Uniform Resource Identifier (URI): 927 Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 928 January 2005. 929 . 931 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 932 Specifications: ABNF", STD 68, RFC 5234, 933 DOI 10.17487/RFC5234, January 2008. 934 . 936 [RFC8141] Saint-Andre, P., "Uniform Resource Names (URNs)", 937 RFC 8141, DOI 10.17487/RFC8141, April 2017. 938 . 940 [X660] "Information technology - Procedures for the operation of 941 object identifier registration authorities: General 942 procedures and top arcs of the international object 943 identifier tree", Recommendation ITU-T X.660 (2011) | 944 ISO/IEC 9834-1:2012, July 2011. 945 . 947 [X680] "Information technology - Abstract Syntax Notation One 948 (ASN.1): Specification of basic notation", Recommendation 949 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, August 2015. 950 . 952 10.2 Informative References 954 [RFC1157] Case, J., Fedor, M., Schoffstall, M., Davin, J., "A Simple 955 Network Management Protocol (SNMP)", RFC 1157, 956 DOI 10.17487/RFC1157, May 1990. 957 . 959 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 960 (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, 961 June 2006. 962 . 964 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., Thayer, 965 R., "OpenPGP Message Format", RFC 4880, 966 DOI 10.17487/RFC4880, November 2007. 967 . 969 [X509] "Information technology - Open Systems Interconnection - 970 The Directory: Public-key and attribute certificate 971 frameworks", Recommendation ITU-T X.509 (2016) | 972 ISO/IEC 9594-8:2017, October 2016. 973 . 975 [X667] "Information technology - Procedures for the operation of 976 object identifier registration authorities: Generation of 977 universally unique identifiers and their use in object 978 identifiers", Recommendation ITU-T X.667 (2012) | 979 ISO/IEC 9834-8:2014, October 2012. 980 . 982 [X672] "Information technology - Open systems interconnection - 983 Object identifier resolution system", 984 Recommendation ITU-T X.672 (2010) | ISO/IEC 29168-1:2011, 985 August 2010. 986 . 988 Acknowledgements 990 Olivier Dubuisson 992 Authors' Addresses 994 Daniel Marschall 995 Postfach 11 53 996 69243 Bammental 997 Germany 999 EMail: daniel-marschall@viathinksoft.de