Subversion Repositories oidplus

INTERNET-DRAFT                                              D. Marschall

Intended Status: Informational                              ViaThinkSoft

Expires: 26 July 2024                                    23 January 2024

            Retrieving information about Object Identifiers

                      using a text-based protocol

                      draft-viathinksoft-oidip-07

Abstract

   This document defines a method for retrieving information about

   Object Identifiers (OIDs) and their associated Registration

   Authorities (RAs) through a text-based protocol, in a way that is

   both human-readable and machine-readable.  Besides a text output

   format, OID-IP also supports sending information in JSON and XML.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 26 July 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as

   described in Section 4.e of the Trust Legal Provisions and are

   provided without warranty as described in the Revised BSD License.

Marschall                 Expires 26 July 2024                  [Page 1]

INTERNET DRAFT          OID Information Protocol         23 January 2024

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4

     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  5

   2  Request . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6

     2.1  Input Parameters  . . . . . . . . . . . . . . . . . . . . .  6

       2.1.1  Format ("format" Argument)  . . . . . . . . . . . . . .  7

       2.1.2  Authentication Tokens ("auth" Argument) . . . . . . . .  8

       2.1.3  Preferred Language ("lang" Argument)  . . . . . . . . .  8

       2.1.4  Custom Input Parameters . . . . . . . . . . . . . . . .  9

     2.2  Request ABNF Notation . . . . . . . . . . . . . . . . . . .  9

   3  Response  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

     3.1  Format and Encoding . . . . . . . . . . . . . . . . . . . . 11

       3.1.1 "text" Format  . . . . . . . . . . . . . . . . . . . . . 11

       3.1.2 "json" Format  . . . . . . . . . . . . . . . . . . . . . 11

       3.1.3 "xml" Format . . . . . . . . . . . . . . . . . . . . . . 12

     3.2  Sections  . . . . . . . . . . . . . . . . . . . . . . . . . 12

       3.2.1  Query-Section (Information about Query and Result)  . . 12

       3.2.2  Object-Section (Information about the OID)  . . . . . . 13

       3.2.3  RA-Section (Information about the Current RA) . . . . . 17

       3.2.4  Sections for Previous Registration Authorities  . . . . 19

     3.3  Digital Signature . . . . . . . . . . . . . . . . . . . . . 19

       3.3.1  "text" Format . . . . . . . . . . . . . . . . . . . . . 19

       3.3.2  "json" Format . . . . . . . . . . . . . . . . . . . . . 19

       3.3.3  "xml" Format  . . . . . . . . . . . . . . . . . . . . . 20

     3.4  Date/Time Format  . . . . . . . . . . . . . . . . . . . . . 20

       3.4.1  Date/Time Format ABNF Notation  . . . . . . . . . . . . 21

       3.4.2  Date/Time Format Examples . . . . . . . . . . . . . . . 21

   4  Referral  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

   5  Full Example ("text" Format)  . . . . . . . . . . . . . . . . . 23

     5.1  Request . . . . . . . . . . . . . . . . . . . . . . . . . . 23

     5.2  Response  . . . . . . . . . . . . . . . . . . . . . . . . . 23

   6  Alternative Namespaces  . . . . . . . . . . . . . . . . . . . . 24

     6.1  Example: UUID Namespace . . . . . . . . . . . . . . . . . . 25

   7  Internationalization Considerations . . . . . . . . . . . . . . 25

   8  Security Considerations . . . . . . . . . . . . . . . . . . . . 26

   9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26

   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27

     10.1  Normative References . . . . . . . . . . . . . . . . . . . 27

     10.2  Informative References . . . . . . . . . . . . . . . . . . 28

   Appendix A.  JSON Format Schema and Example  . . . . . . . . . . . 30

   Appendix A.1.  JSON Format Schema  . . . . . . . . . . . . . . . . 30

   Appendix A.2.  JSON Format Example of Output . . . . . . . . . . . 39

   Appendix B.  XML Format Schema and Example . . . . . . . . . . . . 41

   Appendix B.1.  XML Format Schema . . . . . . . . . . . . . . . . . 41

   Appendix B.2.  XML Format Example of Output  . . . . . . . . . . . 50

   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 52

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52

Marschall                 Expires 26 July 2024                  [Page 2]

INTERNET DRAFT          OID Information Protocol         23 January 2024

Marschall                 Expires 26 July 2024                  [Page 3]

INTERNET DRAFT          OID Information Protocol         23 January 2024

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 Object Identifiers can be found in

   Recommendation ITU-T X.660 (2011) | ISO/IEC 9834-1:2012 [X660].

   There are a few methods of retrieving information about an OID, like:

   (A) Searching through web repositories like <http://www.oid-info.com>

   or <http://www.alvestrand.no/objectid/>.  This has the disadvantage

   that the information is usually not machine-readable without

   functionalities like an API.

   (B) Retrieving information using the Object Identifier Resolution

   System (ORS) as defined in Recommendation ITU-T X.672 (2010) |

   ISO/IEC 29168-1:2011 [X672].  This has the disadvantage that

   Registration Authorities need to include specific DNS Resource

   Records to their domains, and additionally, all RAs of the superior

   OIDs must implement the ORS.

   This document describes an additional method for retrieving

   information about OIDs, which is both human-readable and machine-

   readable.

   Three of many possible use-case scenarios are:

   (1) Many web browsers and Operating Systems can handle ITU-T X.509

   certificates [X509] and usually contain a viewer application that

   shows the contents of these certificates.  Attributes that are

   unknown by the application are either only displayed by their OID, or

   hidden to avoid confusion for the user.  With OID-IP, the application

   could query the name of these unknown OIDs or even retrieve

   instructions on how the data described by this OID can be parsed and

   displayed.

   (2) Applications that handle SNMP (Simple Network Management

   Protocol) [RFC1157] might need information about additional MIB files

   or their OIDs.  OID-IP could aid these applications in gathering the

   required information.

   (3) In directory services like LDAP (Lightweight Directory Access

   Protocol) [RFC4511], applications could query the name of attributes

   that are described by an OID the application doesn't know.

Marschall                 Expires 26 July 2024                  [Page 4]

INTERNET DRAFT          OID Information Protocol         23 January 2024

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

   "OPTIONAL" in this document are to be interpreted as described in

   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all

   capitals, as shown here.

   The following list describes terminology and definitions used

   throughout this document:

      ABNF        Augmented Backus-Naur Form, a format used to represent

                  permissible strings in a protocol or language, as

                  defined in [RFC5234].

      arc         Synonymous for "node" in the terminology of Object

                  Identifiers.

      ASCII       American Standard Code for Information Interchange

      JSON        JavaScript Object Notation, an open standard file

                  format and data interchange format, as defined in

                  [RFC8259].

      OID         Object Identifier, an identifier mechanism

                  standardized by the International Telecommunication

                  Union (ITU) and ISO/IEC.

      OID-IP      Object Identifier Information Protocol, as defined in

                  this document.

      RA          Registration Authority, an entity responsible for

                  allocating arcs to sub-nodes and recording that

                  allocation (together with the organization the

                  subordinate node has been allocated to).

      TCP         Transmission Control Protocol

      UTF-8       8-bit Unicode Transformation Format, as defined in

                  [RFC3629].

      XML         Extensible Markup Language, a markup language and file

                  format for storing, transmitting, and reconstructing

                  arbitrary data ([XML]).

Marschall                 Expires 26 July 2024                  [Page 5]

INTERNET DRAFT          OID Information Protocol         23 January 2024

2  Request

   OID-IP is a text-based protocol.

   By default, an OID-IP server listens on TCP port 43 (WHOIS) for

   requests from OID-IP clients.  Due to the compatibility, existing

   WHOIS clients can be re-used and existing WHOIS servers can add the

   functionalities described in this document in addition to their usual

   operation.

   The OID-IP client makes a text request to the OID-IP server, then the

   OID-IP server replies with text content.  All requests are terminated

   with ASCII CR followed by ASCII LF.  The response contains multiple

   lines of text, separated by ASCII CR followed by ASCII LF.  The OID-

   IP server closes its connection as soon as the output is finished. 

   The closed TCP connection indicates to the client that the response

   has been received.

   During the request, the client sends a query beginning with "oid:",

   followed by an OID in dot-notation, as defined in RFC 3061, section 2

   [RFC3061], but with the following differences:

   (1) The OID MAY contain a leading dot.

   (2) To query the root of the OID tree, the OID MUST be either missing

   or consisting only of a single dot.

   Examples of valid queries are:

       oid:

       oid:.

       oid:2.999

       oid:.2.999

   All OIDs MUST be interpreted as absolute OIDs.  Relative OIDs (e.g.

   relative to the OID of the Registration Authority operating the OID-

   IP service) are not allowed.

   The namespace identifier (i.e. "oid") MUST be written in lower-case.

2.1  Input Parameters

   The client can send additional information to the server using "input

   parameters".

   Names MUST be treated as case-sensitive.

   A request can contain multiple input parameters which are each

Marschall                 Expires 26 July 2024                  [Page 6]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   prepended by a dollar sign ("$").

   An equal sign ("=") divides the "name" from the "value".

   Each name MUST only appear a single time in the list of input

   parameters.

   This document describes the following input parameters:

   (1) Format ("format" argument), which is described in section 2.1.1.

   (2) Authentication tokens ("auth" argument), which is described in

   section 2.1.2.

   (3) Preferred language ("lang" argument), which is described in

   section 2.1.3.

   Constraints for custom input parameters are described in

   section 2.1.4.

   The following request is an example of a valid query where the client

   sends a "format" argument with the value "json":

       oid:2.999$format=json

2.1.1  Format ("format" Argument)

   The "format" argument defines the desired output format.

   This document defines 3 formats:

   (1) "text": A text representation as defined in section 3.1.1

   (MANDATORY).

   (2) "json": The JavaScript Object Notation (JSON, [RFC8259])

   representation as defined in section 3.1.2 (RECOMMENDED).

   (3) "xml": Extensible Markup Language (XML, [XML]) representation as

   defined in section 3.1.3 (RECOMMENDED).

   The default format is "text", which is assumed if the "format"

   argument is omitted.

   Besides these 3 formats, the server can accept other formats not

   defined in this document.  The name of the formats MUST be

   alphanumeric, lower-case, and non-empty, and SHOULD be written in the

   English language (e.g. "text") or be common abbreviations (e.g.

   "json").

Marschall                 Expires 26 July 2024                  [Page 7]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   If the client requests a format that is not implemented, then the

   server MUST respond with the "text" format, and the output MUST

   consist of the "query" field, "result: Service error", and a fitting

   "message" field (as described in section 3.2.1).

   The usage of the argument "format" is OPTIONAL.

2.1.2  Authentication Tokens ("auth" Argument)

   Some organizations might not want to present their OID information

   (or part of it) to the public, e.g. for reasons like privacy or

   confidentiality.  Therefore, one or more "authentication tokens" can

   be sent to control the display of confidential information returned

   by the OID-IP service.

   Authentication tokens MUST be case-sensitive and non-empty, and MUST

   NOT contain a dollar sign ("$"), an equal sign ("="), or a comma sign

   (",").

   If multiple authentication tokens need to be submitted, then the

   "auth" argument MUST NOT be repeated.  Instead, the tokens are

   separated using a comma sign (",").  A token MUST NOT be used

   multiple times in the same query.

   Examples of valid queries are:

       oid:2.999$auth=firstToken

       oid:2.999$auth=firstToken,secondToken

   Please note that authentication tokens are only weak protection.  For

   more information, see section 8 "Security Considerations".

   The usage of the argument "auth" is OPTIONAL.

2.1.3  Preferred Language ("lang" Argument)

   The client can request the preferred language of human-readable

   descriptions, names, comments, and error messages using the "lang"

   argument.

   If the server has data in different languages, it should try to find

   the best-fitting language according to the client's request.

   The value of the "lang" argument MUST be a list of language tags as

   defined by [RFC5646], separated by a comma sign, sorted by

   preference, and containing at least one element.

   The translation SHALL only affect the "message", "name",

Marschall                 Expires 26 July 2024                  [Page 8]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   "description", and "information" fields, as well as additional fields

   and comments if their translation makes sense.  Field names MUST NOT

   be translated.  For example, the field name "description" will always

   be in the English language, even if the client requests a response in

   the German language.

   The following request is an example of a valid query where the client

   asks for information written in the English language, preferring US

   American English:

       oid:2.999$lang=en-US,en

   The usage of the argument "lang" is OPTIONAL.

2.1.4  Custom Input Parameters

   The usage of input parameters not described in this document is

   individual for each implementation.

   Names MUST be alphanumeric, lower-case, and non-empty, and SHOULD be

   written in the English language (e.g. "database") or be common

   abbreviations (e.g. "db").

   Values MUST be case-sensitive and non-empty, and MUST NOT contain a

   dollar sign ("$") or an equal sign ("=").

   The usage of the custom input parameters MUST be OPTIONAL.

2.2  Request ABNF Notation

   To define the query string, the following Augmented BNF definitions

   will be used.  They are based on the ABNF styles of RFC 5234

   [RFC5234].

   query           = object optional-args

   object          = ( str-oid       ":" optional-oid ) /

                     ( other-ns-name ":" other-ns-val )

   str-oid         = %x6F.69.64           ; %s"oid"    in RFC 7405

   ; Additional constraint: Query MUST NOT contain more than one

   ;                        argument with the same name.

   optional-args   = *( "$" argument )

   argument        = ( str-format     "=" format ) /

                     ( str-auth       "=" tokens ) /

                     ( str-lang       "=" languages ) /

                     ( other-arg-name "=" other-arg-val )

Marschall                 Expires 26 July 2024                  [Page 9]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   str-format      = %x66.6F.72.6D.61.74  ; %s"format" in RFC 7405

   str-auth        = %x61.75.74.68        ; %s"auth"   in RFC 7405

   str-lang        = %x6C.61.6E.67        ; %s"lang"   in RFC 7405

   optional-oid    = [ "." ] [ oid ]

   oid             = unsigned-number *( "." unsigned-number )

   format          = str-text /

                     str-json /

                     str-xml  /

                     1*( lowercase-char / digit )

   str-text        = %x74.65.78.74        ; %s"text"   in RFC 7405

   str-json        = %x6A.73.6F.6E        ; %s"json"   in RFC 7405

   str-xml         = %x78.6D.6C           ; %s"xml"    in RFC 7405

   ; Language-Tag is defined in RFC 5646

   languages       = Language-Tag *( "," Language-Tag )

   ; Additional constraint: Tokens MUST NOT be used more than one time

   ;                        in the same query.

   tokens          = token *( "," token )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$"),

   ; equal sign (%x3D "="), and comma sign (%x2C ",").

   token           = 1*( %x21-23 / %x25-2B / %x2D-3C / %x3E-7E )

   ; Additional constraint: MUST NOT be <str-format> or <str-auth>.

   other-arg-name  = 1*( lowercase-char / digit )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$")

   ; and equal sign (%x3D "=").

   other-arg-val   = 1*( %x21-23 / %x25-3C / %x3E-7E )

   ; Additional constraint: MUST NOT be <str-oid>.

   other-ns-name   = 1*( lowercase-char / digit )

   ; Printable characters (%x21-7E), excluding dollar sign (%x24 "$").

   other-ns-val    = *( %x21-23 / %x25-7E )

   unsigned-number = "0" / ( nonzero-digit *digit )

   digit           = %x30-39  ; 0-9

   nonzero-digit   = %x31-39  ; 1-9

   lowercase-char  = %x61-7A  ; a-z

Marschall                 Expires 26 July 2024                 [Page 10]

INTERNET DRAFT          OID Information Protocol         23 January 2024

3  Response

3.1  Format and Encoding

3.1.1 "text" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629

   [RFC3629]), without Byte-Order-Mark (BOM).

   (2) The response contains multiple lines with field names and values,

   which MUST be separated by a double colon (":").  Whitespace

   characters after the double colon are allowed.

   (3) If possible, each line SHOULD be limited to 80 characters,

   including the field name, double colon, value, and whitespaces.

   (4) Field names and values MUST be treated as case-sensitive.

   (5) If a value needs to be split into multiple lines, e.g. if the

   line would exceed the length limit, the same field name including

   double colon MUST be repeated at the beginning of the next line.

   (6) If an attribute has multiple values (e.g. multiple Unicode

   labels, alternative email addresses, etc.), each value MUST be

   written in a new line with the same field name.

   (7) Lines with the same field name SHALL be kept together.

   (8) Comment lines MUST start with a percent sign ("%") at the

   beginning of a line, without prepending whitespaces.  They MUST NOT

   be evaluated by machines (except for signature validation, as

   mentioned in section 3.3 "Digital Signature").

   (9) A response consists of sections, which MUST be separated by at

   least one empty line and/or comment line. 

   (10) Custom sections CAN be added after any section defined in this

   document.  The query section MUST be the first section in the

   response.

3.1.2 "json" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629

   [RFC3629]), without Byte-Order-Mark (BOM).

   (2) A response consists of sections, which MUST be named

   "querySection", "objectSection", "raSection", "ra1Section", etc.

   which SHOULD stay in this order.

Marschall                 Expires 26 July 2024                 [Page 11]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   (3) Custom sections CAN be added.  The name of these custom sections

   MUST be the name of the first field, appended by the string

   "Section".

   (4) The JavaScript Object Notation (JSON, [RFC8259]) output MUST

   match the schema defined in Appendix A.1 of this document.

3.1.3 "xml" Format

   (1) The response MUST be UTF-8 encoded (as defined in RFC 3629

   [RFC3629]), without Byte-Order-Mark (BOM).

   (2) A response consists of sections, which MUST be named

   "querySection", "objectSection", "raSection", "ra1Section", etc.

   which MUST stay in this order.

   (3) Custom sections CAN be added.  The name of these custom sections

   MUST be the name of the first field, appended by the string

   "Section".  These custom sections MUST be specified in a different

   XML namespace at the end of the last RA section.

   (4) The Extensible Markup Language (XML, [XML]) output MUST match the

   schema defined in Appendix B.1 of this document.

3.2  Sections

   This document specifies the following sections:

   (1) Query-Section which contains the request and the result, as

   described in section 3.2.1.

   (2) Object-Section which contains information about the OID, as

   described in section 3.2.2.

   (3) RA-Section which contains information about the current

   Registration Authority, as described in section 3.2.3.

   (4) Optional RA-Sections containing information about RAs that were

   previously in charge of managing the OID, as described in

   section 3.2.4.

3.2.1  Query-Section (Information about Query and 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 are:

Marschall                 Expires 26 July 2024                 [Page 12]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   (1) "query" MUST be present and contains the request string the

   client has sent.  Canonization or sanitation (like removing a leading

   dot in front of the OID) SHOULD NOT be applied at this step. 

   Authentication tokens SHOULD be omitted, though.

   (2) "result" MUST be present and SHALL be one of the following

   values:

       "Found" means that the OID-IP service can verify that the

       requested OID exists.  The following sections will contain

       information about this OID.

       "Not found; superior object found" means that the OID-IP service

       cannot verify that the requested OID exists, or it denies that

       the OID exists (e.g. because it is confidential).  However, the

       OID-IP service knows a superior OID which does exist.  The

       following sections will contain information about that superior

       OID instead.

       "Not found" means that the OID-IP service cannot verify that the

       requested OID exists, or it denies that the OID exists (e.g.

       because it is confidential).  Additionally, the OID-IP service

       does not have information about any superior OID, or their

       existence is also denied.

       "Service error" means that an internal error occurred, or that

       the system is in maintenance mode.  The client should try again

       later.

   (3) "distance" SHOULD be present if it is applicable in the requested

   namespace (it is always applicable for OIDs) and 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.

   (4) "message" SHOULD be present if the result is "Service error".  It

   contains a message explaining why the service is not available (e.g.

   displaying an error message).  It MUST NOT be present if the result

   has a different value.

   (5) "lang" (OPTIONAL) contains the language of the field "message". 

   The language should be a language tag as defined in [RFC5646].

   The OID-IP service SHOULD NOT add additional fields to this section.

3.2.2  Object-Section (Information about the OID)

   This section MUST be present if the result is "Found" or "Not found;

Marschall                 Expires 26 July 2024                 [Page 13]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   superior object found".  It MUST start with the field "object".  It

   MUST NOT be present if the result is "Not found" or "Service error".

   Possible fields are:

   (1) "object" contains the OID in dot-notation, prepended by the

   namespace identifier and double colon ("oid:").  This field MUST be

   present.

   (2) "status" MUST be present and SHALL be one of the following

   values:

       "Information available" means that information about the OID is

       fully available.

       "Information partially available" means that part of the

       information about the OID is not available.  Possible reasons

       could be that part of the information is redacted due to

       confidentiality, or the OID-IP service only knows basic

       information, while the full information can be found somewhere

       else (e.g. at a referred OID-IP service).  The field "attribute"

       MAY be used with the value "confidential".

       "Information unavailable" means that the information about the

       OID is missing, redacted due to confidentiality, or otherwise

       unavailable.  The field "attribute" MAY be used with the value

       "confidential".

   (3) "lang" (OPTIONAL) contains the language of the fields "name",

   "description", "information", and additional fields if their

   translation makes sense.  The language should be a language tag as

   defined in [RFC5646].

   (4) "name" (OPTIONAL) contains the name of the OID.  It SHOULD be as

   short as possible.

   (5) "description" (OPTIONAL) contains a short description of the OID.

    The description SHOULD only be a single sentence.

   (6) "information" (OPTIONAL) contains additional information, e.g.

   Management Information Base (MIB) definitions.

   (7) "url" (OPTIONAL, multiple values allowed) contains a URL (as

   defined in RFC 3986 [RFC3986]) leading to more information about the

   OID.

   (8) "asn1-notation" (OPTIONAL, multiple values allowed) contains one

   or more possible notations in the ASN.1 syntax, as defined in

Marschall                 Expires 26 July 2024                 [Page 14]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 32.3

   [X680], e.g. {joint-iso-itu-t(2) example(999)}.

       Note: A line break, to break up lines that are too long, as

       defined in section 3.1 ("Format and Encoding") SHOULD be used. 

       This is no problem because multiple ASN.1 notations can be

       distinguished by their opening curly bracket and their closing

       curly bracket.

   (9) "iri-notation" (OPTIONAL, multiple values allowed) contains one

   or more possible notations in the OID-IRI syntax, as defined in

   Recommendation ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 34.3

   [X680] (but without quotation marks), e.g. /Joint-ISO-ITU-T/Example.

       Note: A line break, to break up lines that are too long, as

       defined in section 3.1 ("Format and Encoding") SHALL NOT be used,

       otherwise, it would be ambiguous if the line break was used to

       shorten the line, or if the line break indicates a new value in

       case multiple OID-IRI notations are supplied.

   (10) "identifier" (OPTIONAL, multiple values allowed) contains an

   alphanumeric identifier ("NameForm") as defined in Recommendation

   ITU-T X.680 (2015) | ISO/IEC 8824-1:2015, clause 12.3 [X680].

   (11) "standardized-id" (OPTIONAL, multiple values allowed) contains

   an alphanumeric identifier that has a standardized "NameForm", i.e.

   in ASN.1 notation, it can be written without its associated number. 

   See more information in Recommendation ITU-T X.680 (2015) | ISO/IEC

   8824-1:2015, clause 32.7 [X680].

   (12) "unicode-label" (OPTIONAL, multiple values allowed) contains a

   Non-integer Unicode label, as defined in Recommendation ITU-T X.680

   (2015) | ISO/IEC 8824-1:2015, clause 12.27 [X680].

   (13) "long-arc" (OPTIONAL, multiple values allowed) contains a Non-

   integer Unicode label that can be used as the first identifier in an

   OID Internationalized Resource Identifier (OID-IRI), shortening it. 

   More information can be found in Recommendation ITU-T X.660 (2011) |

   ISO/IEC 9834-1:2012, clause 3.5.8 [X660].

   (14) "oidip-service" (OPTIONAL) contains an IP address or hostname of

   a system that offers an OID-IP service that can supply information

   about the OID and/or its subordinate OIDs, followed by a double-colon

   (:) and a port number.  If the result is "Found" (i.e. the OID is

   existing in the local database), then the information "oidip-service"

   is only informational; its existence is most likely a hint that

   subordinate OIDs will be found at that OID-IP server.  If the result

   is "Not found; superior object found", then the client SHOULD query

Marschall                 Expires 26 July 2024                 [Page 15]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   the referred OID-IP server to receive more information about the OID.

    See more information in section 4 "Referral".

   (15) "oidip-pubkey" (OPTIONAL) contains the public key of the service

   that is identified with "oidip-service", in case it uses signatures

   (see section 3.3 "Digital Signature") and the referring service knows

   about it.

   (16) "attribute" (OPTIONAL, multiple values allowed) contains

   attributes of the OID.  An attribute MUST be one of the following

   values:

       "confidential" means that information about the OID or part of it

       is confidential.

       "draft" means that the allocation of the OID is not yet official

       and the information is subject to change without notice.  This

       includes deletion and relocation.

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

       "leaf" means that no child OIDs can be allocated under this OID. 

       The field "subordinate" SHALL therefore not be present.

       "no-identifiers" means that the RA is not allocating alphanumeric

       identifiers.

       "no-unicode-labels" means that the RA is not allocating Non-

       integer Unicode labels.

       "retired" means that the OID is withdrawn, revoked, retired,

       expired, etc.  Please consult Recommendation ITU-T X.660 (2011) |

       ISO/IEC 9834-1:2012 [X660] for more information about such cases.

   (17) "parent" (OPTIONAL) contains the OID of the nearest known parent

   OID, prepended by namespace identifier and double colon, i.e. "oid:".

    It MAY be followed by additional human-readable information, e.g. a

   description or a list of ASN.1 identifiers.  There SHALL be at least

   1 whitespace in between.

   (18) "subordinate" (OPTIONAL, multiple values allowed) contains a

   list of subordinate OIDs, prepended by namespace identifier and

   double colon, i.e. "oid:".  It MAY be followed by additional human-

   readable information, e.g. a description or a list of ASN.1

   identifiers.  There SHALL be at least 1 whitespace in between.

Marschall                 Expires 26 July 2024                 [Page 16]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   (19) "created" (OPTIONAL) contains the date and time (as specified in

   section 3.4 "Date/Time Format") when the OID was first allocated by

   the RA of the superior OID.

   (20) "updated" (OPTIONAL) contains the date and time (as specified in

   section 3.4 "Date/Time Format") when the OID information was last

   updated.

   Additional fields can be defined by the OID-IP service.  The field

   names SHALL only consist of the lower-case letters "a..z", hyphens

   ("-"), and numbers, and SHOULD be written in the English language. 

   The field name MUST NOT begin or end with a hyphen and a hyphen MUST

   NOT be followed by another hyphen.

3.2.3  RA-Section (Information about the Current RA)

   This section MUST NOT be present if the result is "Not found" or

   "Service error", otherwise it MAY be present.  If it is present, it

   MUST start with the field "ra".

   Possible fields are:

   (1) "ra" contains a general name of the RA, like the name of a

   person, the name of a group, or the name of an organization.  This

   field MUST be present.

   (2) "ra-status" MUST be present and SHALL be one of the following

   values:

       "Information available" means that information about this RA is

       fully available.

       "Information partially available" means that part of the

       information is not available.  A possible reason could be that

       part of the information is redacted due to confidentiality.  The

       field "attribute" MAY be used with the value "confidential".

       "Information unavailable" means that the data is missing (if the

       OID-IP service only knows the name of the RA and nothing else),

       redacted due to confidentiality, or otherwise unavailable.  The

       field "attribute" MAY be used with the value "confidential".

   (3) "ra-lang" (OPTIONAL) contains the language of the fields in this

   section, if their translation makes sense.  The language should be a

   language tag as defined in [RFC5646].

   (4) "ra-contact-name" (OPTIONAL, multiple values allowed) contains

   the name of a person responsible for the allocation of subordinate

Marschall                 Expires 26 July 2024                 [Page 17]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   OIDs, in case "ra" is a group or organization.

   (5) "ra-address" (OPTIONAL) contains the physical location of the RA.

    While a fully qualified postal address is recommended, the field can

   also just contain a rough location like city and country name, state

   and country name, or just the country name, etc.  The name of the

   country SHOULD always be present.

   (6) "ra-phone" (OPTIONAL, multiple values allowed) contains a

   landline phone number of the Registration Authority.  It SHOULD be

   written in the international number format specified in

   Recommendation ITU-T E.164 (2010) [E164], e.g. +1 206 555 0100.

   (7) "ra-mobile" (OPTIONAL, multiple values allowed) contains a mobile

   phone number of the Registration Authority.  It SHOULD be written in

   the international number format specified in Recommendation ITU-T

   E.164 (2010) [E164], e.g. +1 206 555 0100.

   (8) "ra-fax" (OPTIONAL, multiple values allowed) contains a fax

   number of the Registration Authority.  It SHOULD be written in the

   international number format specified in Recommendation ITU-T E.164

   (2010) [E164], e.g. +1 206 555 0100.

   (9) "ra-email" (OPTIONAL, multiple values allowed) contains an email

   address of the Registration Authority.

   (10) "ra-url" (OPTIONAL, multiple values allowed) contains a URL (as

   defined in RFC 3986 [RFC3986]) leading to more information about the

   RA (usually the website of the RA).

   (11) "ra-attribute" (OPTIONAL, multiple values allowed) contains

   attributes of the RA.  An attribute MUST be one of the following

   values:

       "confidential" means that the information about the RA or part of

       it is confidential.

       "retired" means that the RA is defunct.  If this attribute is set

       to the current RA, then the OID MUST have the attribute "frozen"

       (until the responsibility is transferred to a non-defunct RA, or

       until the current RA becomes active again).

   (12) "ra-created" (OPTIONAL) contains the date and time (as specified

   in section 3.4 "Date/Time Format") when the RA was created/registered

   in the database.

   (13) "ra-updated" (OPTIONAL) contains the date and time (as specified

   in section 3.4 "Date/Time Format") when the RA information was last

Marschall                 Expires 26 July 2024                 [Page 18]

INTERNET DRAFT          OID Information Protocol         23 January 2024

   modified.

   Additional fields can be defined by the OID-IP service, but they MUST

   begin with "ra-".  The field names SHALL only consist of the lower-

   case letters "a..z", hyphens ("-"), and numbers, and SHOULD be

   written in the English language.  The field name MUST NOT begin or

   end with a hyphen and a hyphen MUST NOT be followed by another

   hyphen.

3.2.4  Sections for Previous Registration Authorities

   To optionally display information about RAs that were previously in

   charge of managing the OID, a new section per RA can be added with

   the following field name prefixes:

   "ra-" is the prefix of the current Registration Authority,

   "ra1-" is the prefix of the first RA.  It is the very first person or

   company to whom the OID was allocated by the RA of the superior OID,

   "ra2-" is the prefix of the second RA, after the responsibility has

   been transferred, etc.

   Each section MUST start with the field "ra1", "ra2", etc.

   The definition of these sections is identical to the definition of

   the RA-Section (described in section 3.2.3 "RA-Section"), just with a

   different prefix.

   The history does not need to be complete, e.g. it is no problem to

   only serve information about the first ("ra1") and the current RA

   ("ra"), or only serve information about the current RA ("ra").

3.3  Digital Signature

3.3.1  "text" Format

   If integrity/authenticity is required, the whole response can be

   signed, e.g. by using PGP, RSA, ECDSA, etc.  Depending on the

   signature method being used, various things need to be appended

   and/or prepended to the response (e.g. "-----BEGIN PGP MESSAGE-----"

   and "-----END PGP MESSAGE-----").  These additional lines MUST be

   prepended by a percent sign ("%") to avoid an application confusing

   these additional lines (e.g. lines belonging to a PGP header, as

   defined in RFC 4880 [RFC4880]) with parts of the actual OID-IP

   response.

3.3.2  "json" Format

   Steps for signing a message:

Marschall                 Expires 26 July 2024                 [Page 19]

INTERNET DRAFT          OID Information Protocol         23 January 2024

       1. Make sure that the JSON file has no signature (remove the

       "signature" key if one exists).

       2. Create a working-copy of the JSON file and canonize the

       contents using the procedures described in RFC 8785 [RFC8785].

       3. Create a JSON Web Signature (JWS, RFC 7515 [RFC7515]) using

       your public key and the canonized form of the JSON contents.

       4. Add the signature in the "signature" field to the original

       JSON file.  Note that the original JSON does not need to be

       canonized, since the canonization will be repeated in the

       verification procedure.

   Steps for verifying a message:

       1. Extract the contents of the "signature" key from the JSON

       file.  This is the JSON Web Signature containing a header, a

       payload, and a signature.

       2. Create a working-copy of the JSON file and remove the

       "signature" key there.

       3. Canonize the remaining contents using the procedures described

       in RFC 8785 [RFC8785].

       4. Compare the canonized contents to the base64-encoded payload

       of the JSON Web Signature which was extracted before.  The

       contents MUST be equal.

       5. Verify the JSON Web Signature of the original JSON file

       according to the procedures described in RFC 7515 [RFC7515].

3.3.3  "xml" Format

   Signing and verifying signatures will be performed as described in

   the W3C Recommendation "XML Signature Syntax and Processing"

   ([XMLDSig]).

3.4  Date/Time Format

   Date/Time references SHALL be formatted as described in

   section 3.4.1.

   If parts of the date/time reference are uncertain, then they SHOULD

   be omitted until the date/time reference has the highest correctness.

   Examples of valid date/time references can be found in section 3.4.2.

Marschall                 Expires 26 July 2024                 [Page 20]

INTERNET DRAFT          OID Information Protocol         23 January 2024