idnits 2.17.1 draft-viathinksoft-oidwhois-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 2021) is 1137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 9, 2021 March 2021 6 Retrieving information about Object Identifiers 7 using the WHOIS protocol 8 draft-viathinksoft-oidwhois-02 10 Abstract 12 This document defines a method for retrieving information about 13 Object Identifiers (OIDs) and their associated Registration 14 Authorities (RAs) using the WHOIS 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 19 76 10 Object Identifier of OID-WHOIS . . . . . . . . . . . . . . . . 20 77 11 Annotation about the deprecation of the WHOIS protocol . . . . 20 78 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 12.1 Normative References . . . . . . . . . . . . . . . . . . . 20 80 12.2 Informative References . . . . . . . . . . . . . . . . . . 21 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 84 1 Introduction 86 An Object Identifier (OID) is an extensively used identification 87 mechanism jointly developed by ITU-T and ISO/IEC for naming any type 88 of object with a globally unambiguous name. OIDs provide a 89 persistent identification of objects based on a hierarchical 90 structure of Registration Authorities (RA), where each parent has an 91 Object Identifier and allocates Object Identifiers to child nodes. 92 More information about Object Identifiers can be found in 93 Recommendation ITU-T X.660 (2011) | ISO/IEC 9834-1:2012 [X660]. 95 There are a few methods of retrieving information about an OID, like: 97 (A) Searching through web repositories like 98 or . This has the disadvantage 99 that the information is usually not machine-readable without 100 functionalities like an API. 102 (B) Retrieving information using the Object Identifier Resolution 103 System (ORS) as defined in Recommendation ITU-T X.672 (2010) | 104 ISO/IEC 29168-1:2011 [X672]. This has the disadvantage that 105 Registration Authorities need to include specific DNS Resource 106 Records to their domains, and additionally, all RAs of the superior 107 OIDs must implement the ORS. 109 This document describes an additional method for retrieving 110 information about OIDs, which is both human-readable and machine- 111 readable. 113 Three of many possible use-case scenarios are: 115 (1) Many web-browsers and Operating Systems can handle ITU-T X.509 116 certificates [X509] and usually contain a viewer application that 117 shows the contents of these certificates. Attributes which are 118 unknown by the application are either only displayed by their OID, or 119 hidden to avoid confusion to the user. With OID-WHOIS, the 120 application could query the name of these unknown OIDs or even 121 retrieve instructions on how the data described by this OID can be 122 parsed and displayed. 124 (2) Applications that handle SNMP (Simple Network Management 125 Protocol) [RFC1157] might need information about additional MIB files 126 or their OIDs. OID-WHOIS could aid these applications in gathering 127 the required information. 129 (3) In directory services like LDAP (Lightweight Directory Access 130 Protocol) [RFC4511], applications could query the name of attributes 131 that are described by an OID the application doesn't know. 133 1.1 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 In this document, "RA" is an abbreviation for "Registration 140 Authority" and "OID" is an abbreviation for "Object Identifier". 142 2 Request 144 OID-WHOIS is based on the WHOIS protocol specified in RFC 3912 145 [RFC3912]. 147 During the request, the client sends a query beginning with "oid:", 148 followed by an OID in dot-notation, as defined in RFC 3061, section 2 149 [RFC3061], but with the following differences: 151 (1) The OID MAY contain a leading dot. 153 (2) To query the root of the OID tree, the OID MUST be either missing 154 or consisting only of a single dot. 156 Examples of valid queries are: 158 oid: 159 oid:. 160 oid:2.999 161 oid:.2.999 163 All OIDs MUST be interpreted as absolute OIDs. Relative OIDs (e.g. 164 relative to the OID of the Registration Authority operating the WHOIS 165 service) are not allowed. 167 The namespace identifier (i.e. "oid") MUST be written in lower-case. 169 Note: Existing WHOIS servers can add the functionalities described in 170 this document in addition to their usual operation, i.e. they may 171 accept queries beginning with "oid:" as well as other types of 172 queries. 174 2.1 Authentication Tokens 176 Some organizations might not want to present their OID information 177 (or part of it) to the public, e.g. for reasons like privacy or 178 confidentiality. Therefore, at the end of the query, the client can 179 append case-sensitive, non-empty alphanumeric authentication tokens 180 to control the display of confidential information. 182 Each authentication token MUST be prepended by a dollar sign ("$"). 184 Examples of valid queries are: 186 oid:2.999$firstToken 187 oid:2.999$firstToken$secondToken 189 Please note that authentication tokens are only weak protection. For 190 more information, see section 8 "Security Considerations". 192 2.2 Request ABNF Notation 194 To define the query string, the following Augmented BNF definitions 195 will be used. They are based on the ABNF styles of RFC 5234 196 [RFC5234]. 198 query = namespace ":" optional-oid *( "$" authtoken ) 200 namespace = %x6F %x69 %x64 ; "oid" 202 optional-oid = [ "." ] [ oid ] 204 oid = unsigned-number *( "." unsigned-number ) 206 authtoken = 1*( char-or-digit ) 208 digit = %x30-39 ; 0-9 210 nonzero-digit = %x31-39 ; 1-9 212 uppercase-char = %x41-5A ; A-Z 214 lowercase-char = %x61-7A ; a-z 216 char-or-digit = uppercase-char / lowercase-char / digit 218 unsigned-number = "0" / nonzero-digit *( digit ) 220 3 Response 222 3.1 Format and Encoding 224 (1) The response MUST be UTF-8 encoded (as defined in RFC 3629 225 [RFC3629]), without Byte-Order-Mark (BOM). 227 (2) The response contains multiple lines with field names and values, 228 which MUST be separated by a double colon (":"). Whitespace 229 characters after the double colon are allowed. 231 (3) If possible, each line SHOULD be limited to 80 characters, 232 including the field name, double colon, value, and whitespaces. 234 (4) Field names and values MUST be treated case-sensitive. 236 (5) If a value needs to be split into multiple lines, e.g. if the 237 line would exceed the length limit, the same field name including 238 double colon MUST be repeated at the beginning of the next line. 240 (6) If an attribute has multiple values (e.g. multiple Unicode 241 labels, alternative email-addresses, etc.), each value MUST be 242 written in a new line with the same field name. 244 (7) Lines with the same field name SHALL be kept together. 246 (8) Comment lines MUST start with a percent sign ("%") at the 247 beginning of a line, without prepending whitespaces. They MUST NOT 248 be evaluated by machines (except for signature validation, as 249 mentioned in section 3.3 "Digital Signature"). 251 3.2 Structure 253 A response consists of sections, which SHOULD be separated by at 254 least one empty line and/or comment line. 256 This document specifies the following sections (which SHALL stay in 257 this order): 259 (1) Query-Section which contains the request and the result. This 260 section MUST start with the field "query". 262 (2) Object-Section which contains information about the OID. This 263 section MUST start with the field "object". 265 (3) RA-Section which contains information about the current 266 Registration Authority. This section MUST start with the field "ra". 268 (4) Optional RA-Sections containing information about RAs which were 269 previously in charge of managing the OID. 271 The WHOIS service MAY define additional sections after any of these 272 sections, but the Query-Section MUST be the first section in the 273 response. 275 3.2.1 Query-Section (Information about Query and Result) 277 This section MUST always be present and MUST start with the field 278 "query". It MUST be the first section in the response. 280 Possible fields are: 282 (1) "query" MUST be present and contain the request of the client 283 (beginning with the namespace identifier and double colon, i.e. 284 "oid:"). Canonization or sanitation (like removing a leading dot) 285 SHOULD NOT be applied at this step. Authentication tokens SHOULD be 286 omitted, though. 288 (2) "result" MUST be present and SHALL be one of the following 289 values: 291 "Found" means that the WHOIS service can verify that the 292 requested OID exists. The following sections will contain 293 information about this OID. 295 "Not found; superior object found" means that the WHOIS service 296 cannot verify that the requested OID exists, or it denies that 297 the OID exists (e.g. because it is confidential). However, the 298 WHOIS service knows a superior OID which does exist. The 299 following sections will contain information about that superior 300 OID instead. 302 "Not found" means that the WHOIS service cannot verify that the 303 requested OID exists, or it denies that the OID exists (e.g. 304 because it is confidential). Additionally, the WHOIS service 305 does not have information about any superior OID, or their 306 existence is also denied. 308 "Service error" means that an internal error occurred, or that 309 the system is in maintenance mode. The client should try again 310 later. 312 (3) "distance" SHOULD be present if it is applicable in the requested 313 namespace (it is always applicable for OIDs) and if the result is 314 "Not found; superior object found". A distance of 1 means that the 315 direct parent was found. A distance of 2 means that the grand-parent 316 was found, etc. 318 (4) "message" SHOULD be present if the result is "Service error". It 319 contains a message explaining why the service is not available (e.g. 320 displaying an error message). It MUST NOT be present if the result 321 has a different value. 323 The WHOIS service SHOULD NOT add additional fields to this section. 325 3.2.2 Object-Section (Information about the OID) 327 This section MUST be present if the result is "Found" or "Not found; 328 superior object found". It MUST start with the field "object". It 329 MUST NOT be present if the result is "Not found" or "Service error". 331 Possible fields are: 333 (1) "object" contains the OID in dot-notation, prepended by the 334 namespace identifier and double colon ("oid:"). This field MUST be 335 present. 337 (2) "status" MUST be present and SHALL be one of the following 338 values: 340 "Information available" means that information about the OID is 341 fully available. 343 "Information partially available" means that part of the 344 information about the OID is not available. Possible reasons 345 could be that part of the information is redacted due to 346 confidentiality, or the WHOIS service does only know basic 347 information, while the full information can be found somewhere 348 else (e.g. at a referred WHOIS service). The field "attribute" 349 MAY be used with the value "confidential". 351 "Information unavailable" means that the information about the 352 OID is missing, redacted due to confidentiality, or otherwise 353 unavailable. The field "attribute" MAY be used with the value 354 "confidential". 356 (3) "name" (OPTIONAL) contains the name of the OID. It SHOULD be as 357 short as possible. 359 (4) "description" (OPTIONAL) contains a short description of the OID. 360 The description SHOULD only be a single sentence. 362 (5) "information" (OPTIONAL) contains additional information, e.g. 363 Management Information Base (MIB) definitions. 365 (6) "url" (OPTIONAL, multiple values allowed) contains a URL (as 366 defined in RFC 3986 [RFC3986]) leading to more information about the 367 OID. 369 (7) "asn1-notation" (OPTIONAL, multiple values allowed) contains one 370 or more possible notations in the ASN.1 syntax, as defined in 371 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 32.3 372 [X680], e.g. {joint-iso-itu-t(2) example(999)}. 374 Note: A line-break, to break up lines which are too long, as 375 defined in section 3.1 ("Format and Encoding") SHOULD be used. 376 This is no problem because multiple ASN.1 notations can be 377 distinguished by their opening curly bracket and their closing 378 curly bracket. 380 (8) "iri-notation" (OPTIONAL, multiple values allowed) contains one 381 or more possible notations in the OID-IRI syntax, as defined in 382 Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 34.3 383 [X680] (but without quotation marks), e.g. /Joint-ISO-ITU-T/Example. 385 Note: A line-break, to break up lines which are too long, as 386 defined in section 3.1 ("Format and Encoding") SHALL NOT be used, 387 otherwise, it would be ambiguous if the line-break was used to 388 shorten the line, or if the line-break indicates a new value in 389 case multiple OID-IRI notations are supplied. 391 (9) "identifier" (OPTIONAL, multiple values allowed) contains an 392 alphanumeric identifier ("NameForm") as defined in Recommendation 393 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 12.3 [X680]. 395 (10) "standardized-id" (OPTIONAL, multiple values allowed) contains 396 an alphanumeric identifier that has a standardized "NameForm", i.e. 397 in ASN.1 notation, it can be written without its associated number. 398 See more information in Recommendation ITU-T X.680 (2015) | ISO/IEC 399 8824-1:2015, clause 32.7 [X680]. 401 (11) "unicode-label" (OPTIONAL, multiple values allowed) contains a 402 Non-integer Unicode label, as defined in Recommendation ITU-T X.680 403 (2015) | ISO/IEC 8824-1:2015, clause 12.27 [X680]. 405 (12) "long-arc" (OPTIONAL, multiple values allowed) contains a Non- 406 integer Unicode label that can be used as the first identifier in an 407 OID Internationalized Resource Identifier (OID-IRI), shortening it. 408 More information can be found in Recommendation ITU-T X.660 (2011) | 409 ISO/IEC 9834-1:2012, clause 3.5.8 [X660]. 411 (13) "whois-service" (OPTIONAL) contains an IP-address or hostname of 412 a system that offers a WHOIS service that can supply information 413 about the OID and/or its subordinate OIDs. If the result is "Found" 414 (i.e. the OID is existing in the local database), then the 415 information "whois-service" is only informational; its existence is 416 most likely a hint that subordinate OIDs will be found at that WHOIS 417 server. If the result is "Not found; superior object found", then 418 the client SHOULD query the referred WHOIS server to receive more 419 information about the OID. See more information in section 4 420 "Referral". 422 (14) "attribute" (OPTIONAL, multiple values allowed) contains 423 attributes of the OID. An attribute MUST be one of the following 424 values: 426 "confidential" means that information about the OID or part of it 427 is confidential. 429 "draft" means that the allocation of the OID is not yet official 430 and the information is subject to change without notice. This 431 includes deletion and relocation. 433 "frozen" means that no more child OIDs can be created under this 434 OID, e.g. because the RA has stopped operating, but the existing 435 child OIDs stay valid. 437 "leaf" means that no child OIDs can be allocated under this OID. 438 The field "subordinate" SHALL therefore not be present. 440 "no-identifiers" means that the RA is not allocating alphanumeric 441 identifiers. 443 "no-unicode-labels" means that the RA is not allocating Non- 444 integer Unicode labels. 446 "retired" means that the OID is withdrawn, revoked, retired, 447 expired, etc. Please consult Recommendation ITU-T X.660 (2011) | 448 ISO/IEC 9834-1:2012 [X660] for more information about such cases. 450 (15) "parent" (OPTIONAL) contains the OID of the nearest known parent 451 OID, prepended by namespace identifier and double colon, i.e. "oid:". 452 It MAY be followed by additional human-readable information, e.g. a 453 description or a list of ASN.1 identifiers. There SHALL be at least 454 1 whitespace in between. 456 (16) "subordinate" (OPTIONAL, multiple values allowed) contains a 457 list of subordinate OIDs, prepended by namespace identifier and 458 double colon, i.e. "oid:". It MAY be followed by additional human- 459 readable information, e.g. a description or a list of ASN.1 460 identifiers. There SHALL be at least 1 whitespace in between. 462 (17) "created" (OPTIONAL) contains the date and time (as specified in 463 section 3.4 "Date/Time Format") when the OID was first allocated by 464 the RA of the superior OID. 466 (18) "updated" (OPTIONAL) contains the date and time (as specified in 467 section 3.4 "Date/Time Format") when the OID information was last 468 updated. 470 Additional fields can be defined by the WHOIS service. The field 471 names SHALL only consist of the lower-case letters "a..z", hyphens 472 ("-") and numbers, and SHOULD be written in the English language. 473 The field name MUST NOT begin or end with a hyphen and a hyphen MUST 474 NOT be followed by another hyphen. 476 3.2.3 RA-Section (Information about the Current RA) 478 This section MUST NOT be present if the result is "Not found" or 479 "Service error", otherwise it MAY be present. If it is present, it 480 MUST start with the field "ra". 482 Possible fields are: 484 (1) "ra" contains a general name of the RA, like the name of a 485 person, the name of a group, or the name of an organization. This 486 field MUST be present. 488 (2) "ra-status" MUST be present and SHALL be one of the following 489 values: 491 "Information available" means that information about this RA is 492 fully available. 494 "Information partially available" means that part of the 495 information is not available. A possible reason could be that 496 part of the information is redacted due to confidentiality. The 497 field "attribute" MAY be used with the value "confidential". 499 "Information unavailable" means that the data is missing (if the 500 WHOIS service does only know the name of the RA and nothing 501 else), redacted due to confidentiality or otherwise unavailable. 502 The field "attribute" MAY be used with the value "confidential". 504 (3) "ra-contact-name" (OPTIONAL, multiple values allowed) contains 505 the name of a person responsible for the allocation of subordinate 506 OIDs, in case "ra" is a group or organization. 508 (4) "ra-address" (OPTIONAL) contains the physical location of the RA. 509 While a fully qualified postal address is recommended, the field can 511 also just contain a rough location like city and country name, state 512 and country name, or just the country name, etc. The name of the 513 country SHOULD always be present. 515 (5) "ra-phone" (OPTIONAL, multiple values allowed) contains a 516 landline phone number of the Registration Authority. It SHOULD be 517 written in the international number format specified in 518 Recommendation ITU-T E.164 (2010) [E164], e.g. +1 206 555 0100. 520 (6) "ra-mobile" (OPTIONAL, multiple values allowed) contains a mobile 521 phone number of the Registration Authority. It SHOULD be written in 522 the international number format specified in Recommendation ITU-T 523 E.164 (2010) [E164], e.g. +1 206 555 0100. 525 (7) "ra-fax" (OPTIONAL, multiple values allowed) contains a fax 526 number of the Registration Authority. It SHOULD be written in the 527 international number format specified in Recommendation ITU-T E.164 528 (2010) [E164], e.g. +1 206 555 0100. 530 (8) "ra-email" (OPTIONAL, multiple values allowed) contains an email 531 address of the Registration Authority. 533 (9) "ra-url" (OPTIONAL, multiple values allowed) contains a URL (as 534 defined in RFC 3986 [RFC3986]) leading to more information about the 535 RA (usually the website of the RA). 537 (10) "ra-attribute" (OPTIONAL, multiple values allowed) contains 538 attributes of the RA. An attribute MUST be one of the following 539 values: 541 "confidential" means that the information about the RA or part of 542 it is confidential. 544 "retired" means that the RA is defunct. If this attribute is set 545 to the current RA, then the OID MUST have the attribute "frozen" 546 (until the responsibility is transferred to a non-defunct RA, or 547 until the current RA becomes active again). 549 (11) "ra-created" (OPTIONAL) contains the date and time (as specified 550 in section 3.4 "Date/Time Format") when the RA was created/registered 551 in the database. 553 (12) "ra-updated" (OPTIONAL) contains the date and time (as specified 554 in section 3.4 "Date/Time Format") when the RA information was last 555 modified. 557 Additional fields can be defined by the WHOIS service, but they MUST 558 begin with "ra-". The field names SHALL only consist of the lower- 559 case letters "a..z", hyphens ("-") and numbers, and SHOULD be written 560 in the English language. The field name MUST NOT begin or end with a 561 hyphen and a hyphen MUST NOT be followed by another hyphen. 563 3.2.4 Sections for Previous Registration Authorities 565 To optionally display information about RAs which were previously in 566 charge of managing the OID, a new section per RA can be added with 567 the following field name prefixes: 569 "ra-" is the prefix of the current Registration Authority. 571 "ra1-" is the prefix of the first RA. It is the very first person or 572 company to whom the OID was allocated by the RA of the superior OID. 573 "ra2-" is the prefix of the second RA, after the responsibility has 574 been transferred. etc. 576 The definition of these sections is identical to the definition of 577 the RA-Section (described in section 3.2.3 "RA-Section"), just with a 578 different prefix. 580 The history does not need to be complete, e.g. it is no problem to 581 only serve information about the first and the current RA, or only 582 serve information about the current RA. 584 3.3 Digital Signature 586 If integrity/authenticity is required, the whole response can be 587 signed, e.g. by using S/MIME, RSA, or PGP. This document does not 588 describe a mechanism for detecting which signature method was used. 589 The creation and verification of the signature are therefore 590 implementation-specific and no interoperability regarding signature 591 creation and validation is given at this time. 593 Depending on the signature method being used, various things need to 594 be appended and/or prepended to the response. These additional lines 595 MUST be prepended by a percent sign ("%") to avoid that an 596 application confuses these additional lines (e.g. lines belonging to 597 a PGP header, as defined in RFC 4880 [RFC4880]) with parts of the 598 actual WHOIS response. 600 3.4 Date/Time Format 602 Date/Time references SHALL be formatted as described in 603 section 3.4.1. 605 If parts of the date/time reference are uncertain, then they SHOULD 606 be omitted until the date/time reference has the highest correctness. 608 Examples of valid date/time references can be found in section 3.4.2. 610 3.4.1 Date/Time Format ABNF Notation 612 To define the format of a Date/Time reference, the following 613 Augmented BNF definitions will be used. They are based on the ABNF 614 styles of RFC 5234 [RFC5234]. 616 date-time = year [ "-" month [ "-" day [ " " time ] ] ] 618 year = 4*4DIGIT 620 month = ( "0" %x31-39 ) / 621 ( "1" %x30-32 ) ; 01-12 623 day = ( "0" %x31-39 ) / 624 ( "1" %x30-39 ) / 625 ( "2" %x30-39 ) / 626 ( "3" %x30-31 ) / ; 01-31 628 time = hour ":" minute [ ":" second ] [ " " timezone ] 630 hour = ( "0" %x30-39 ) / 631 ( "1" %x30-39 ) / 632 ( "2" %x30-33 ) ; 00-23 634 minute = %x30-35 DIGIT ; 00-59 636 second = %x30-35 DIGIT ; 00-59 638 timezone = ( "+" / "-" ) hour minute 640 3.4.2 Date/Time Format Examples 642 Examples of valid date/time references are: 644 2020-06-29 18:32:00 +0200 645 2020-06-29 18:32:00 646 2020-06-29 18:32 +0200 647 2020-06-29 18:32 648 2020-06-29 649 2020-06 650 2020 652 4 Referral 654 By using the field "whois-service", the WHOIS service can instruct 655 the client to query another WHOIS service that might have more 656 information about the requested OID. 658 If Registration Authorities maintain up-to-date WHOIS service 659 references of their OID delegations, it is possible to automatically 660 retrieve information about any OID. 662 Example: OID "2.999" is owned by Registration Authority "A", 663 operating a WHOIS service at "a.example.com". 665 Registration Authority "A" allocated OID "2.999.1000" to Registration 666 Authority "B" who is operating a WHOIS service at "b.example.com". 668 The client asks a.example.com for information about OID 669 "2.999.1000.1" and should receive the following reply: 671 query: oid:2.999.1000.1 672 result: Not found; superior object found 673 distance: 1 675 object: oid:2.999.1000 676 status: Information available 677 name: Company "B" 678 whois-service: b.example.com 680 ra: "B" 681 ra-status: Information unavailable 683 The client is now aware that "a.example.com" only knows OID 684 "2.999.1000", and that there is a reference to another WHOIS service 685 located at "b.example.com". So, the client should then accordingly 686 query "b.example.com", asking for information about OID 687 "2.999.1000.1": 689 query: oid:2.999.1000.1 690 result: Found 692 object: oid:2.999.1000.1 693 status: Information available 694 name: Example OID 1 696 ra: "B" 697 ra-status: Information unavailable 699 5 Full Example 701 5.1 Request 703 oid:2.999 705 5.2 Response 707 query: oid:2.999 708 result: Found 710 object: oid:2.999 711 status: Information available 712 name: Example 713 description: This OID can be used by anyone, for the purposes of 714 description: documenting examples of Object Identifiers. 715 asn1-notation: {joint-iso-itu-t(2) example(999)} 716 iri-notation: /Example 717 identifier: example 718 unicode-label: Beispiel 719 unicode-label: Ejemplo 720 unicode-label: Example 721 unicode-label: Exemple 722 unicode-label: (Korean characters are omitted in this example) 723 unicode-label: (Arabian characters are omitted in this example) 724 unicode-label: (Japanese characters are omitted in this example) 725 unicode-label: (Chinese characters are omitted in this example) 726 unicode-label: (Russian characters are omitted in this example) 727 long-arc: Beispiel 728 long-arc: Ejemplo 729 long-arc: Example 730 long-arc: Exemple 731 long-arc: (Korean characters are omitted in this example) 732 long-arc: (Arabian characters are omitted in this example) 733 long-arc: (Japanese characters are omitted in this example) 734 long-arc: (Chinese characters are omitted in this example) 735 long-arc: (Russian characters are omitted in this example) 736 parent: oid:2 (joint-iso-itu-t) 737 created: 2011-06 738 updated: 2011-09 740 ra: ITU-T SG 17 & ISO/IEC JTC 1/SC 6 741 ra-status: Information unavailable 742 % -----BEGIN RSA SIGNATURE----- 743 % DwnqRtx/ONtPh4onXnrZPl9jF+G50RMLZkSwuClaoH2t/yK8CnYJrmzkzA5+gkfWkoQ 744 % cq+J8J9cvnwXvBfpVHh+7lyNOVW1N016TYFcBt8MVxb6K2KhkKclqeA6wz0kSUuE4qR 745 % ZohzrZBcCP7aLIpcaoVi6QACAt6J0vOvYBaf0= 746 % -----END RSA SIGNATURE----- 748 6 Alternative Namespaces 750 This document describes the retrieval of information about OIDs using 751 the WHOIS protocol. In addition to the OID namespace, the methods 752 described in this document can also be applied to other namespaces 753 like "uuid", "isbn", "gtin" etc. 755 Following things need to be considered if alternative namespaces are 756 implemented: 758 (1) The request MUST be UTF-8 encoded (as defined in RFC 3629 759 [RFC3629]), without Byte-Order-Mark (BOM). 761 (2) The namespace SHALL be a namespace identifier (NID) as defined in 762 RFC 8141 [RFC8141]. 764 (3) The namespace identifier SHALL be written in lower-case (this is 765 already defined in section 2 "Request"). 767 (4) If available, a formal URN namespace identifier (as defined in 768 RFC 8141, section 5.1 [RFC8141]) SHOULD be used, e.g. "uuid" should 769 be used instead of "guid". 771 (5) If things like "Owner", "Creator", "Manager", "Administrator", 772 etc., are relevant to the identifiers in the namespace, then the RA- 773 section as described in section 3.2.3 SHALL be used, even though the 774 word "Registration Authority" might not be appropriate in the 775 terminology of the namespace. 777 (6) The namespace specific identifier MUST NOT contain dollar signs 778 ("$"), because section 2.1 "Authentication Tokens" defines them as a 779 separator for authentication tokens. 781 (7) The namespace specific identifier MUST be treated case-sensitive 782 if the namespace distinguishes between lower-case and upper-case. 784 (8) Fields which can only be used in the OID namespace (e.g. 785 "unicode-label") MUST NOT be used for other namespaces. 787 6.1 Example: UUID Namespace 789 The following example shows the retrieval of information about 790 Universally Unique Identifiers (e.g. UUIDs used by the Microsoft 791 Common Object Model, also known as GUIDs). The UUID namespace has no 792 hierarchical structure, which means that the WHOIS service can only 793 respond with the result "Found", "Not found" or "Service error" and 794 the fields "parent" and "subordinate" cannot be used. 796 Request: 798 uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 800 Response: 802 query: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 803 result: Found 805 object: uuid:b4bfcc3a-db2c-424c-b029-7fe99a87c641 806 status: Information available 807 name: Desktop 808 information: GUID can be used in file dialogs as "Custom Place". 810 ra: Microsoft Corp. 811 ra-status: Information unavailable 813 More information about UUIDs can be found in Recommendation ITU-T 814 X.667 (2012) | ISO/IEC 9834-8:2014 [X667]. 816 More information about the Microsoft Common Object Model (COM) can be 817 found at Microsoft Docs . 820 7 Internationalization Considerations 822 The WHOIS protocol as defined in RFC 3912 [RFC3912] does not define 823 any character set and there is no mechanism for indicating which 824 character set is in use. 826 To enhance interoperability, this document specifies that the request 827 and response MUST be UTF-8 encoded (as defined in RFC 3629 828 [RFC3629]), without Byte-Order-Mark (BOM). 830 The WHOIS service can define additional field names, but they SHOULD 831 be written in the English language so that there is consistency with 832 the field names defined in this document. 834 8 Security Considerations 836 (1) The knowledge of existence or information about some OIDs could 837 be considered confidential. In this case, the WHOIS service can 838 either deny the existence of the requested OID (by setting the result 839 to "Not found") or redact information in the Object-Section, as 840 defined in section 3.2.2 "Object-Section". 842 (2) Registration Authorities might demand that their data is kept 843 confidential, or at least be partially redacted to increase privacy 844 or as measurement against spam. In this case, the WHOIS service can 845 redact information in the RA-Section, as defined in section 3.2.3 846 "RA-Section". 848 (3) The WHOIS service can decide if confidential material is omitted 849 or shown, based on authentication mechanisms like white-listing 850 client IP addresses or by using authentication tokens supplied by the 851 client, as defined in section 2.1 "Authentication Tokens". 853 (4) The usage of authentication tokens is not recommended if the 854 traffic between client and server is transmitted through an untrusted 855 network, because the WHOIS protocol is not encrypted. 857 (5) Authentication tokens must have a sufficient length and 858 complexity to avoid successful brute force attacks, or the WHOIS 859 service must limit the number of requests per time. 861 (6) The WHOIS protocol itself has no mechanism for verifying the 862 integrity of data received. Due to this fact, the information should 863 not be trusted if it is transmitted through an untrusted network. If 864 integrity/authenticity is required, the WHOIS response can be signed, 865 as described in section 3.3 "Digital Signature". However, this 866 document does not describe a mechanism for detecting which signature 867 method was used. Therefore, no interoperability of signature 868 creation/validation is given at this time. 870 9 IANA Considerations 872 This document has no actions for IANA. 874 10 Object Identifier of OID-WHOIS 876 The following OID can be used to identify the procedure and/or the 877 format of OID-WHOIS: 879 Dot notation: 880 1.3.6.1.4.1.37476.3.5.10.1 882 ASN.1 notation: 883 { iso(1) identified-organization(3) dod(6) internet(1) private(4) 884 enterprise(1) 37476 specifications(3) communication(5) 885 oid-whois(10) v1(1) } 887 OID-IRI notation: 888 /ISO/Identified-Organization/6/1/4/1/37476 889 /Specifications/Communication/OIDWhois/Version1 891 11 Annotation about the deprecation of the WHOIS protocol 893 The WHOIS protocol is currently extensively used for querying 894 databases that store the registered users or assignees of an Internet 895 resource, such as a domain name, an IP address block, or an 896 autonomous system. Due to various reasons, there are efforts in 897 deprecating the WHOIS protocol to introduce the Registration Data 898 Access Protocol (RDAP). This document is not meant to interfere with 899 these efforts. 901 As this document describes a new way to use the WHOIS protocol, it 902 should be noted that while the usage of e.g. domain holder 903 information exchange will be deprecated, the protocol itself still 904 can be used for other purposes and therefore doesn't need to be 905 completely deprecated. 907 The WHOIS protocol was chosen as the base of OID-WHOIS because it is 908 better human-readable. Furthermore, OID-WHOIS fixes some of the 909 weaknesses of the WHOIS protocol, for example, the format is 910 standardized, internationalization is addressed (UTF-8), users can be 911 authenticated, redirections are standardized, etc. Therefore, good 912 machine-readability is also ensured. 914 12 References 916 12.1 Normative References 918 [E164] "The international public telecommunication numbering 919 plan", Recommendation ITU-T E.164 (2010), November 2010. 920 . 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997. 925 . 927 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 928 RFC 3061, DOI 10.17487/RFC3061, February 2001. 929 . 931 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 932 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 933 November 2003. 934 . 936 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 937 DOI 10.17487/RFC3912, September 2004. 938 . 940 [RFC3986] Berners-Lee, T., "Uniform Resource Identifier (URI): 941 Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 942 January 2005. 943 . 945 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 946 Specifications: ABNF", STD 68, RFC 5234, 947 DOI 10.17487/RFC5234, January 2008. 948 . 950 [RFC8141] Saint-Andre, P., "Uniform Resource Names (URNs)", 951 RFC 8141, DOI 10.17487/RFC8141, April 2017. 952 . 954 [X660] "Information technology - Procedures for the operation of 955 object identifier registration authorities: General 956 procedures and top arcs of the international object 957 identifier tree", Recommendation ITU-T X.660 (2011) | 958 ISO/IEC 9834-1:2012, July 2011. 959 . 961 [X680] "Information technology - Abstract Syntax Notation One 962 (ASN.1): Specification of basic notation", Recommendation 963 ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, August 2015. 964 . 966 12.2 Informative References 968 [RFC1157] Case, J., Fedor, M., Schoffstall, M., Davin, J., "A Simple 969 Network Management Protocol (SNMP)", RFC 1157, 970 DOI 10.17487/RFC1157, May 1990. 971 . 973 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 974 (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, 975 June 2006. 976 . 978 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., Thayer, 979 R., "OpenPGP Message Format", RFC 4880, 980 DOI 10.17487/RFC4880, November 2007. 981 . 983 [X509] "Information technology - Open Systems Interconnection - 984 The Directory: Public-key and attribute certificate 985 frameworks", Recommendation ITU-T X.509 (2016) | 986 ISO/IEC 9594-8:2017, October 2016. 987 . 989 [X667] "Information technology - Procedures for the operation of 990 object identifier registration authorities: Generation of 991 universally unique identifiers and their use in object 992 identifiers", Recommendation ITU-T X.667 (2012) | 993 ISO/IEC 9834-8:2014, October 2012. 994 . 996 [X672] "Information technology - Open systems interconnection - 997 Object identifier resolution system", 998 Recommendation ITU-T X.672 (2010) | ISO/IEC 29168-1:2011, 999 August 2010. 1000 . 1002 Acknowledgements 1004 Olivier Dubuisson 1006 Authors' Addresses 1008 Daniel Marschall 1009 Postfach 11 53 1010 69243 Bammental 1011 Germany 1013 EMail: daniel-marschall@viathinksoft.de