Subversion Repositories oidplus

 



INTERNET-DRAFT                                          Daniel Marschall
Intended Status: Informational                              ViaThinkSoft
Expires: <Expiry Date>                                      January 2019


            Retrieving information about Object Identifiers
                        using the WHOIS protocol
                     draft-viathinksoft-oidwhois-00


Abstract

   This document defines a machine-readable structure for retrieving
   information about Object Identifiers (OIDs) and their associated
   Registration Authorities (RAs) using the WHOIS protocol.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 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
 


Daniel Marschall         Expires <Expiry Date>                  [Page 1]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


   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 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Request . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1  Authentication tokens . . . . . . . . . . . . . . . . . . .  4
     2.2  BNF notation  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Response . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1  Format and encoding . . . . . . . . . . . . . . . . . . . .  5
     3.2  Structure . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3  Section that displays the query and the result  . . . . . .  6
       3.3.1  "RESULT: Found" . . . . . . . . . . . . . . . . . . . .  7
       3.3.2  "RESULT: Not found; superior object found"  . . . . . .  7
       2.3.3  "RESULT: Not found" . . . . . . . . . . . . . . . . . .  7
     3.4  Section that displays information about the OID . . . . . .  7
     3.6  Section that displays information about the RA  . . . . . .  9
     3.7  Referral  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.8  Date/Time references  . . . . . . . . . . . . . . . . . . . 11
   4  Full example  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1  Request . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.2  Response  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   5. Alternative namespaces  . . . . . . . . . . . . . . . . . . . . 13
   6  Security Considerations . . . . . . . . . . . . . . . . . . . . 14
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 15
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15












 


Daniel Marschall         Expires <Expiry Date>                  [Page 2]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


1  Introduction

   An 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.


1.1  Terminology

   The 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".











 


Daniel Marschall         Expires <Expiry Date>                  [Page 3]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


2  Request

   OID-over-WHOIS uses the WHOIS protocol specified in RFC 3912
   [RFC3912].

   During the request, the client sends a query beginning with "oid:",
   followed by an OID in dot notation, as defined in RFC 2252 [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:

       oid:
       oid:.
       oid:2.999
       oid:.2.999

   All 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.

2.1  Authentication tokens

   At 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:

       oid:2.999$firstToken
       oid:2.999$firstToken$secondToken

   Please note that authentication tokens are only a weak protection.
   For more information, see "security considerations".






 


Daniel Marschall         Expires <Expiry Date>                  [Page 4]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


2.2  BNF notation

   For the purposes of defining the query string, the following BNF
   definitions will be used. They are based on the BNF styles of RFC 822
   [RFC822].

   digit   = "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" / digit

   positive-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 )


3.  Response

3.1  Format and encoding

   The response should be UTF-8 encoded (as defined in RFC 3629
   [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 double colon needs
   to be repeated at the beginning of the new line.

   If attributes have multiple values (e.g. multiple Unicode labels,
 


Daniel Marschall         Expires <Expiry Date>                  [Page 5]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


   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.


3.2  Structure

   A 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.


3.3  Section that displays the query and the result

   This 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.

 


Daniel Marschall         Expires <Expiry Date>                  [Page 6]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


3.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.

3.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.

2.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.


3.4  Section that displays information about the OID

   This 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
 


Daniel Marschall         Expires <Expiry Date>                  [Page 7]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


   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.


 


Daniel Marschall         Expires <Expiry Date>                  [Page 8]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


3.6  Section that displays information about the RA

   This 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-".







 


Daniel Marschall         Expires <Expiry Date>                  [Page 9]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


3.7  Referral

   By 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:

       query:          oid:2.999.1000.1
       result:         Not found; superior object found

       object:         oid:2.999.1000
       status:         Found
       name:           Company "B"
       whois-service:  b.example.com

       ra:             "B"
       ra-status:      Not Found

   The 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.

       query:          oid:2.999.1000.1
       result:         Found

       object:         oid:2.999.1000.1
       status:         Found
       name:           Example OID 1

       ra:             "B"
       ra-status:      Not Found




 


Daniel Marschall         Expires <Expiry Date>                 [Page 10]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


3.8  Date/Time references

   Date/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:

   2019-03-15 18:32:00 +0200
   2019-03-15 18:32:00
   2019-03-15 18:32 +0200
   2019-03-15 18:32
   2019-03-15
   2019-03
   2019































 


Daniel Marschall         Expires <Expiry Date>                 [Page 11]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


4  Full example

4.1  Request

   oid:2.999

4.2  Response

   query:          oid:2.999
   result:         Found

   object:         oid:2.999
   status:         Found
   name:           Example
   information:    This OID can be used by anyone, without any
   information:    permission, for the purpose of documenting examples
   information:    of object identifiers (in the same way as
   information:    "example.com" is defined in IETF RFC 2606 as an
   information:    example for web sites).
   identifier:     example
   unicode-label:  Beispiel
   unicode-label:  Ejemplo
   unicode-label:  Example
   unicode-label:  Exemple
   unicode-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:       Beispiel
   long-arc:       Ejemplo
   long-arc:       Example
   long-arc:       Exemple
   long-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-06
   updated:        2011-09

   ra:             ITU-T SG 17 & ISO/IEC JTC 1/SC 6
   ra-status:      Not found





 


Daniel Marschall         Expires <Expiry Date>                 [Page 12]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


5. Alternative namespaces

   This 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):

       query:        ipv6:2001:1af8:4700:a07e:1::1336
       result:       Not found; superior object found
       distance:     16

       object:       ipv6:2001:1af8:4700:a07e:1::/112
       status:       Found
       name:         ...
       description:  ...
       created:      ...
       updated:      ...

       ra:           ...
       ra-status:    ...

   Another 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".

       query:        uuid:2a00375e-224c-49de-b8d1-440df7ef3ddc
       result:       Found

       object:       uuid:2a00375e-224c-49de-b8d1-440df7ef3ddc
       status:       Found
       name:         LocalizedResourcesDir
       description:  GUID used as "Custom Place" in file dialogs.
       created:      ...
       updated:      ...

       ra:           Microsoft Corp.
       ra-status:    Not found




 


Daniel Marschall         Expires <Expiry Date>                 [Page 13]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


6  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).

7  IANA Considerations

   IANA 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.

 


Daniel Marschall         Expires <Expiry Date>                 [Page 14]

INTERNET DRAFT               OID-over-WHOIS                 <Issue Date>


8  References

8.1  Normative References

   [X672]     "Object identifier resolution system (ORS)",
              Recommendation ITU-T X.672 | ISO/IEC 29168-1.

   [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3912]  Daigle, "WHOIS Protocol Specification", RFC 3912,
              September 2004.

   [RFC2252]  Wahl, et. al., Lightweight Directory Access Protocol (v3):
              Attribute Syntax Definitions, RFC RFC2252, December 1997.

   [RFC822]   Crocker, "Standard of the Format of ARPA-Internet Text
              Messages", STD 11, RFC 822, August 1982.

   [RFC3629]  Yergeau, "UTF-8, a transformation format of ISO 10646",
              RFC 3629, November 2003.

   [X680]     "Abstract Syntax Notation One (ASN.1) & ASN.1 encoding
              rules", Recommendation ITU-T X.680 | ISO/IEC 8824-1.


8.2  Informative References

   [X660]     "Procedures for the operation of object identifier
              registration authorities: General procedures and top arcs
              of the international object identifier tree",
              Recommendation ITU-T X.660 | ISO/IEC 9834-1


Authors' Addresses


   Daniel Marschall
   ViaThinkSoft
   Postfach 11 53
   69243 Bammental
   Germany

   EMail: daniel-marschall@viathinksoft.de







Daniel Marschall         Expires <Expiry Date>                 [Page 15]