Rev 54 | Go to most recent revision | Blame | Last modification | View Log | RSS feed
.pl 10.0i.po 0.ll 7.2i.lt 7.2i.nr LL 7.2i.nr LT 7.2i.ds LF Daniel Marschall.ds RF FORMFEED[Page %].ds LH INTERNET DRAFT.ds RH <Issue Date>.ds CH OID-over-WHOIS.ds CF Expires <Expiry Date>.hy 0.nh.ad l.in 0.nf.tl 'INTERNET-DRAFT''Daniel Marschall'.tl 'Intended Status: Informational''ViaThinkSoft'.tl 'Expires: <Expiry Date>''January 2019'.fi.\" Note. The ".tl" directive is used to generate the leading header.\" in Internet drafts. The information specified after ".tl" provides.\" left, center and right components of a line separated by the ' character.\" in the following manner:.\".\" .tl '<left component>'<center component>'<right component>'.\".\" Only the left and right components are used in Internet-draft headers.\" This and other comments in this template can safely be deleted..ce 3Retrieving information about Object Identifiersusing the WHOIS protocoldraft-viathinksoft-oidwhois-00.fi.in 3.ti 0AbstractThis document defines a machine-readable structure for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) using the WHOIS protocol..ti 0Status of this MemoThis Internet-Draft is submitted to IETF in full conformance with the provisions of BCP\078 and BCP\079.Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as \%Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed at \%http://www.ietf.org/1id-abstracts.htmlThe list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.ti 0Copyright and License Notice\" Boilerplate from December 2009.\" NOTE: Insert current <year> in the following paragraphCopyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.This document is subject to BCP\078 and the IETF Trust's Legal Provisions Relating to IETF Documents \%(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section\04.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License..\" \# TD4 -- Set TOC depth by altering this value (TD5 = depth 5).\" \# TOC -- Beginning of auto updated Table of Contents.in 0Table of Contents.nf1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 32 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1 Authentication tokens . . . . . . . . . . . . . . . . . . . 42.2 BNF notation . . . . . . . . . . . . . . . . . . . . . . . 53. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1 Format and encoding . . . . . . . . . . . . . . . . . . . . 53.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Section that displays the query and the result . . . . . . 63.3.1 "RESULT: Found" . . . . . . . . . . . . . . . . . . . . 73.3.2 "RESULT: Not found; superior object found" . . . . . . 72.3.3 "RESULT: Not found" . . . . . . . . . . . . . . . . . . 73.4 Section that displays information about the OID . . . . . . 73.6 Section that displays information about the RA . . . . . . 93.7 Referral . . . . . . . . . . . . . . . . . . . . . . . . . 103.8 Date/Time references . . . . . . . . . . . . . . . . . . . 114 Full example . . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . 125. Alternative namespaces . . . . . . . . . . . . . . . . . . . . 136 Security Considerations . . . . . . . . . . . . . . . . . . . . 147 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 148 References . . . . . . . . . . . . . . . . . . . . . . . . . . 158.1 Normative References . . . . . . . . . . . . . . . . . . . 158.2 Informative References . . . . . . . . . . . . . . . . . . 15Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15.fi.in 3.\" \# ETC -- End of auto updated Table of Contents.bp.ti 01 IntroductionAn Object Identifier (OID) is an extensively used identification mechanism jointly developed by ITU-T and ISO/IEC for naming any type of object with a globally unambiguous name. OIDs provide a persistent identification of objects based on a hierarchical structure of Registration Authorities (RA), where each parent has an Object Identifier and allocates Object Identifiers to child nodes.More information about OIDs can be found in Recommendation ITU-T X.660 | ISO/IEC 9834-1 [X660].There are a few methods of retrieving information about an Object Identifier, like:(A) Searching through web repositories like www.oid-info.com or www.alvestrand.no/objectid/ . This has the disadvantage that the information is usually not machine readable.(B) Retrieving information using the Object Identifier Resolution System (ORS) defined in Recommendation ITU-T X.672 | ISO/IEC 29168-1 [X672]. This has the disadvantage that the Registration Authority needs to include specific DNS Resource Records to their domain, and additionally, all superior RAs must implement ORS.This document describes an additional method of retrieving information about OIDs, which is both human-readable and machine-readable..ti 01.1 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].In this document, "RA" is an abbreviation for "Registration Authority" and "OID" is an abbreviation for "Object Identifier"..bp.ti 02 RequestOID-over-WHOIS uses the WHOIS protocol specified in RFC\03912 [RFC3912].During the request, the client sends a query beginning with "oid:", followed by an OID in dot notation, as defined in RFC\02252 [RFC2252], but with following differences:(a) Numbers must not have leading zeroes.(b) A leading dot in front of the OID is permitted.(c) To query the root of the OID tree, the OID may be empty or only consist of a single dot.Examples of valid queries:.in 7.nfoid:oid:.oid:2.999oid:.2.999.fi.in 3All OIDs must be interpreted as absolute OIDs. Relative OIDs (e.g. relative to the root of the Registration Authority operating the WHOIS service) are not allowed..ti 02.1 Authentication tokensAt the end of the query, the client may additionally append case sensitive, non-empty alphanumeric authentication tokens to control the display of confidential information.Each authentication token is prepended by a dollar sign ("$")Examples of valid queries:.in 7.nfoid:2.999$firstTokenoid:2.999$firstToken$secondToken.fi.in 3Please note that authentication tokens are only a weak protection. For more information, see "security considerations"..bp.ti 02.2 BNF notationFor the purposes of defining the query string, the following BNFdefinitions will be used. They are based on the BNF styles ofRFC\0822 [RFC822]..nfdigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"nonzero-digit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"char = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" /"k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" /"u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" /"E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" /"O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /"Y" / "Z" / digitpositive-number = "0" / nonzero-digit *( digit )oid = positive-number *( "." positive-number )optional-oid = 0*1( "." ) 0*1( oid )authtoken = char *( char )query = "oid:" optional-oid *( "$" authtoken ).fi.ti 03. Response.ti 03.1 Format and encodingThe response should be UTF-8 encoded (as defined in RFC\03629 [RFC3629]), without Byte-Order-Mark (BOM).It is recommended that each line be limited to 80 characters.The response contains multiple lines with fields and values,which are separated by a double colon (":").Whitespace characters after the double colon are allowed.Field names are case insensitive.If a value needs to be split into multiple lines, e.g.if the line would exceed the length limit, the key including doublecolon needs to be repeated at the beginning of the new line.If attributes have multiple values (e.g. multiple Unicode labels,alternative email-addresses etc.),a new line with the same field name may be added.Comment lines start with a percent sign ("%") at the beginning of a line,without whitespaces in front of it. Comment lines shall not be evaluated by machines..ti 03.2 StructureA response can have different sections, which are defined in the following clauses.It is recommended that sections are divided by at least one empty line and/or comment line.This document defines following sections (which should stay in this order):(1) Section that displays the request and the result, starting with the field "query".(2) Section that displays information about the OID, starting with the field "object".(3) Section that displays information about the Registration Authority, starting with the field "ra".The service may define additional sections between or after these sections, but not at the beginning at the response..ti 03.3 Section that displays the query and the resultThis section must always be present and must start with the field "query". It must be the first section in the response.Possible fields:- "query" contains the request of the user (beginning with "oid:"). No canonization or sanitation should be applied at this step. Authentication tokens must be omitted.- "result" may only be "Found", "Not found" or "Not found; superior object found". These result types are defined below.- "distance" is only present if the result is "Not found; superior object found". A distance of "1" means that the direct parent was found. A distance of "2" means that the grand-parent was found, etc..ti 03.3.1 "RESULT: Found"The system can verify that the requested OID exists. It has either full information about the OID, or knows another service (e.g. another WHOIS service) where information can be retrieved from..ti 03.3.2 "RESULT: Not found; superior object found"The system cannot verify that the requested OID exists, or it denies that the OID exists (because it is confidential).However, the system knows a superior OID does exist. The response will show information about this superior OID instead..ti 02.3.3 "RESULT: Not found"The system cannot verify that the requested OID exists, or it denies that the OID exists (because it is confidential). Additionally, the system does not have information about any superior OID..ti 03.4 Section that displays information about the OIDThis section is mandatory if the result is not "Not found", and must start with the field "object".Possible fields:- "object" which shows the OID in dot-notation, beginning with "oid:".- "status" which usually has the value "Found", but it can also have different values like "Confidential" (in case the server doesn't deny the existence of the OID).- "whois-service" should be present if the service does not have full information about the OID (e.g. if the requested OID is inside a branch that was delegated to a different RA operating an own WHOIS service). If the response was "Found" (i.e. the service has full information about the OID), the information "whois-service" is only informational; its existence is most likely a hint that subsequent OIDs will be found at this WHOIS server. If the result is "Not found; superior object found", the client must query the referred WHOIS server in order to receive accurate information about the OID.- "url" (optional, multiple values allowed) contains a website that contains more information about the OID.- "identifier" (optional, multiple values allowed) contains the ASN.1 alphanumeric value ("NameForm") as defined in Recommendation ITU-T X.680 | ISO/IEC 8824-1, clause 32 [X680].- "standardized-id" (optional, multiple values allowed) contains an identifier that has a standardized NameForm, i.e. in an ASN.1 notation, it can be written without its associated number.- "unicode-label" (optional, multiple values allowed) contains an Unicode label that can be used in an OID Internationalized Resource Identifier (OID-IRI), as defined in Recommendation ITU-T X.680 | ISO/IEC 8824-1, clause 34 [X680].- "long-arc" (optional, multiple values allowed) contains an Unicode label that can be used as first identifier in an ORI-IRI, shortening it.- "attribute" (optional, multiple values allowed) contains attributes for that OID.Possible attributes:"leaf" (this means that no child OIDs can be allocated under this OID),"frozen" (this means that no more child OIDs can be created under this OID,e.g. because the RA has stopped operating, but the existing child OIDs stay valid),"no-identifiers" (this means that the RA is not allocating identifiers), or"no-unicode-labels" (this means that the RA is not allocating Unicode labels).- "name" contains the name of the OID.- "description" (optional) contains a short description of the OID.- "information" (optional) contains additional information.- "created" (optional) contains the date the OID was allocated by the superior RA.- "registered" (optional) contains the date the OID was registered in the local database.- "updated" (optional) contains the date the OID was last updated.- "parent" (optional) contains the OID of the nearest known object, beginning with "oid:".- "subordinate" (optional, multiple values allowed) contains a list of subordinate OIDs, beginning with "oid:".- Additional fields can be defined by the service..ti 03.6 Section that displays information about the RAThis section must not be present when result is "Not found", otherwise it is optional. If it is present, it must start with the field "ra".Fields:- "ra" contains a general name of the RA like a person name, a group name, or a company name.- "ra-status" shows the status of the RA. It can be "Found", "Not found" (if the service does only know the name of the RA and nothing else), or "Confidential".- "ra-name" (optional) contains the name of a person or group responsible for the allocation of OIDs.- "ra-organization" (optional) contains the name of the organization, in case "ra-name" is the name of a person or workgroup.- "ra-address" (optional) contains the postal address of the Registration Authority.- "ra-phone" (optional) contains the phone number of the Registration Authority, including the international country code.- "ra-fax" (optional) contains the fax number of the Registration Authority, including the international country code.- "ra-email" (optional) contains the email address of the Registration Authority.- "ra-created" (optional) contains the date the RA was created/registered in the database.- "ra-updated" (optional) contains the date the RA information was last modified.- Additional fields can be defined by the service, but must begin with "ra-"..bp.ti 03.7 ReferralBy using the field "whois-service", the service can instruct the client to query another service that might have more information about the requested object.If Registration Authorities maintain up-to-date references to WHOIS service references of their OID delegations, it is possible to automatically retrieve information about any OID.Example: OID 2.999 is owned by Registration Authority "A", operating a WHOIS service at "a.example.com".The OID 2.999.1000 has been allocated to Registration Authority "B" who is operating a WHOIS service at "b.example.com".The client asks a.example.com for information about 2.999.1000.1 and should receive following reply:.in 7.nfquery: oid:2.999.1000.1result: Not found; superior object foundobject: oid:2.999.1000status: Foundname: Company "B"whois-service: b.example.comra: "B"ra-status: Not Found.fi.in 3The client now knows that "a.example.com" only knows 2.999.1000, and that there is a reference to another WHOIS service located at "b.example.com". So, the client could then accordingly query "b.example.com", asking for information about 2.999.1000.1..in 7.nfquery: oid:2.999.1000.1result: Foundobject: oid:2.999.1000.1status: Foundname: Example OID 1ra: "B"ra-status: Not Found.fi.in 3.bp.ti 03.8 Date/Time referencesDate/Time references should have the format "YYYY-MM-DD hh:mm:ss +/-zzzz", e.g. "2019-03-15 18:32:00 +0200".If parts of the date/time reference are uncertain, they may be removed until the date/time reference has the highest correctness.Examples of valid date/time references:.nf2019-03-15 18:32:00 +02002019-03-15 18:32:002019-03-15 18:32 +02002019-03-15 18:322019-03-152019-032019.fi.bp.ti 04 Full example.ti 04.1 Request.nfoid:2.999.fi.ti 04.2 Response.nfquery: oid:2.999result: Foundobject: oid:2.999status: Foundname: Exampleinformation: This OID can be used by anyone, without anyinformation: permission, for the purpose of documenting examplesinformation: of object identifiers (in the same way asinformation: "example.com" is defined in IETF RFC 2606 as aninformation: example for web sites).identifier: exampleunicode-label: Beispielunicode-label: Ejemplounicode-label: Exampleunicode-label: Exempleunicode-label: (Korean characters omitted in this example)unicode-label: (Arabian characters omitted in this example)unicode-label: (Japanese characters omitted in this example)unicode-label: (Chinese characters omitted in this example)unicode-label: (Russian characters omitted in this example)long-arc: Beispiellong-arc: Ejemplolong-arc: Examplelong-arc: Exemplelong-arc: (Korean characters omitted in this example)long-arc: (Arabian characters omitted in this example)long-arc: (Japanese characters omitted in this example)long-arc: (Chinese characters omitted in this example)long-arc: (Russian characters omitted in this example)created: 2011-06updated: 2011-09ra: ITU-T SG 17 & ISO/IEC JTC 1/SC 6ra-status: Not found.fi.bp.ti 05. Alternative namespacesThis document describes the usage of retrieving information about OIDs using the WHOIS protocol. In addition to the namespace "oid", the methods described in this document can also be applied to other namespaces like "ipv4", "ipv6", "uuid", "doi" etc.In the following example, the client wants to retrieve information about the IPv6 address "2001:1af8:4700:a07e:1::1336". The WHOIS service didn't find this particular IPv6 address in its database, however, it did find the address range "2001:1af8:4700:a07e:1::/112", with the distance of 16 (bits):.in 7.nfquery: ipv6:2001:1af8:4700:a07e:1::1336result: Not found; superior object founddistance: 16object: ipv6:2001:1af8:4700:a07e:1::/112status: Foundname: ...description: ...created: ...updated: ...ra: ...ra-status: ....fi.in 3Another usage example is the retrieval of information about UUIDs (i.e. GUIDs used by Microsoft COM interfaces). The UUID namespace has no hierarchical structure, so the WHOIS service can only reply "Found" or "Not Found"..in 7.nfquery: uuid:2a00375e-224c-49de-b8d1-440df7ef3ddcresult: Foundobject: uuid:2a00375e-224c-49de-b8d1-440df7ef3ddcstatus: Foundname: LocalizedResourcesDirdescription: GUID used as "Custom Place" in file dialogs.created: ...updated: ...ra: Microsoft Corp.ra-status: Not found.fi.in 3.bp.ti 06 Security Considerations(1) The knowledge of existence or information about some OIDs could be considered confidential. In this case, the service can either deny the existence of the requested OID (by setting the result to "Not found") or redact information in the object output section.(2) Registration Authorities might demand that their personal data is kept confidential, or at least be partially redacted to increase privacy or as a measurement against spam.(3) The service can decide if confidential material is omitted or shown, based on authentication mechanisms like white-listing client IP addresses or by using authentication tokens supplied by the client during the request.(4) The usage of authentication tokens is not recommended if the traffic between client and server is transmitted through an untrusted network, because the WHOIS protocol is not encrypted. Furthermore, authentication tokens must have an sufficient length to avoid brute force attacks, or the service must limit the number of requests.(5) The WHOIS protocol itself has no mechanism for verifying the integrity of data received.Due to this fact, information should not be trusted if it is transmitted through an untrusted network.If integrity/authenticity is required, the WHOIS output should be signed using a public key (this mechanism is not described in this document)..ti 07 IANA ConsiderationsIANA is running a WHOIS service at whois.iana.org. This WHOIS service could be extended by allowing requests starting with "oid:" and could serve the following contents:(1) The service could output information about OIDs owned or delegated by IANA, for example it could output information about Private Enterprise Numbers (PEN) located at 1.3.6.1.4.1. Owners of Private Enterprise Numbers could store the addresses of their own WHOIS servers in the IANA database, so that these addresses can be included in the WHOIS output of IANA.(2) The service can furthermore maintain records for the OID roots "oid:" (refers to IANA itself), "oid:0" (refers to ITU-T), "oid:1" (refers to ISO) and "oid:2" (refers to either an ISO or an ITU-T server). This could alternatively be accomplished by a WHOIS service operated by ISO or ITU-T..ti 08 References.ti 08.1 Normative References.in 14.ti 3[X672] "Object identifier resolution system (ORS)", Recommendation ITU-T\0X.672 | ISO/IEC 29168-1..in 14.ti 3[RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March\01997..in 14.ti 3[RFC3912] Daigle, "WHOIS Protocol Specification", RFC\03912, September\02004..in 14.ti 3[RFC2252] Wahl, et. al., Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, RFC\0RFC2252, December\01997..in 14.ti 3[RFC822] Crocker, "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC\0822, August\01982..in 14.ti 3[RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC\03629, November\02003..in 14.ti 3[X680] "Abstract Syntax Notation One (ASN.1) & ASN.1 encoding rules", Recommendation ITU-T\0X.680 | ISO/IEC\08824-1..ti 08.2 Informative References.in 14.ti 3[X660] "Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree", Recommendation ITU-T\0X.660 | ISO/IEC\09834-1.ti 0Authors' Addresses.in 3.sp.nfDaniel MarschallViaThinkSoftPostfach 11 5369243 BammentalGermanyEMail: daniel-marschall@viathinksoft.de.sp.fi