← Back to packages

Package doirp_v3.v1.element

Message HsAdmin

Message HsPubkey

Message HsServ

Message ServiceInterface

Message ServerRecord

Message HsSite

Message YdAltId

Message YdService

Enum Permission

Enum Type

Enum Type

Enum TransportProtocol

Enum HashOption

Messages

message HsAdmin doirp_v3/v1/element/hs_admin.proto

Spec: 4.3.1 IDENTIFIER ADMINISTRATOR: HS_ADMIN

An administrative operation on an identifier record or on the DO-IRP service (e.g., add, delete or modify an element) can only be performed by an administrator that is authenticated and that has adequate privileges.

We defined an "administrator" as an entity represented by an identifier and an element index within that identifier record. This identifier-index is a reference to an element that must contain a public key or secret key to be used when challenging the entity to authenticate itself.

An authenticated administrator is an entity that has demonstrated that it possesses either the private key matching the public key, or the secret key, pointed to by the administrator's identifier- index element reference.

The privileges or authorizations that an administrator has over an identifier record is specified in one or more elements of type HS_ADMIN within that identifier record. Each HS_ADMIN element can be used to define a set of administrators sharing the same administration privilege. Identifiers with multiple administrators of different privileges may have multiple HS_ADMIN elements. HS_ADMIN elements are used by DO-IRP servers to authenticate administrators before fulfilling any DO-IRP administration request. However, as an implementation option, an identifier record without an HS_ADMIN element can be modified by a qualified DO-IRP server administrator.

An HS_ADMIN element is one whose field is HS_ADMIN and whose field consists of the following entries encoded as binary data:

Spec: A 16-bit bit-mask that defines the administration privilege of the administrator or set of administrators identified by the entry; see below for the permissions.

Field Type Description
1 permission uint32

See Permission enum below for details.

2 admin_ref doirp_v3.v1.common.ElementRef

Spec: Specifies the record's administrator. It consists of the administrator's identifier and element index (as defined above), encoded as a 4-byte length followed by that many UTF-8 encoded bytes, followed by a 4-byte unsigned integer for the index of the element that is referenced in the administrator's identifier record. The referred element in the administrator's identifier record must either be an identity authentication element (such as an HS_PUBKEY or HS_SECKEY element) or an HS_VLIST element, which specifies a group of administrators consisting of a list of one or more administrator identification and authentication elements references. (See HS_VLIST paragraph below for more description as well as HS_VLIST in section 4.2.8 for its detailed specification). An index value of 0 implies that the reference is to all elements in the administrator's identifier record; this means all HS_SECKEY or HS_PUBKEY elements in that record can be used.

message HsPubkey doirp_v3/v1/element/hs_pubkey.proto

Spec: 4.3.6 IDENTITY: HS_PUBKEY

An element of type HS_PUBKEY stores a public key. The element can be used as an administrative identity, for referring to in HS_ADMIN or HS_VLIST elements for authorization, or for identifying the administrative identity in DO-IRP authentication. A reference to the element for use as an administrative identity is as a pair of the identifier and the index of the element within the identifier record; in this document this is often written with a colon as :.

The of the element is a binary encoding of the public key which for key types considered in this specification is as follows. First, there is a UTF8-string that describes the key type; then, a two- byte option field reserved for future use; and finally, a key-type-dependent number of length- prefixed byte-arrays that contains the public key itself.

Field Type Description
1 type string

a UTF8-string that describes the key type, see Type for details

2 option uint32

a two-byte option field reserved for future use

3 bytes repeated bytes

a key-type-dependent number of byte-arrays that contains the public key itself.

message HsServ doirp_v3/v1/element/hs_serv.proto

Spec: 4.3.4 SERVICE IDENTIFIER: HS_SERV

Any DO-IRP service can be defined in terms of one or more HS_SITE elements. These HS_SITE elements may be assigned directly to the relevant prefix identifier, or an additional level of indirection may be introduced through the use of an HS_SERV element in the prefix identifier record. The value of the HS_SERV element contains the service identifier, meaning an identifier whose record contains the HS_SITE elements defining the DO-IRP service. This way, the HS_SITE elements can be maintained in a separate record

Use of service identifiers allows sharing of service information among multiple prefixes. It also allows changes to service configuration (e.g., adding a new site) to be made in one place rather than in every prefix identifier involved.

Although not typical, a prefix identifier may have multiple HS_SITE and multiple HS_SERV elements. In such a case the service information for the prefix should be considered as the concatenation of the HS_SITE elements in the prefix identifier record, together with the service information from all of the HS_SERV elements.

The use of service identifiers raises several special considerations. Multiple levels of service identifier redirection should be avoided due to their lack of efficiency, but are not signaled as an error. Looped reference of service identifiers or HS_SERV elements that refer to non-existent service identifiers should be caught and error conditions passed back to the user.

4.3.5 SERVICE IDENTIFIER: HS_SERV.PREFIX

HS_SERV.PREFIX serves the same role with respect to HS_SITE.PREFIX as HS_SERV serves with respect to HS_SITE. If a prefix identifier has an HS_SERV.PREFIX element, the data of that element is an identifier, whose corresponding record describes, via one or more HS_SITE.PREFIX elements and/or recursively via HS_SERV.PREFIX elements, the service information at which clients may be able to resolve derived prefixes of the original prefix.

Field Type Description
1 service_doid string

An identifier whose record contains the HS_SITE elements defining the DO-IRP service.

message ServiceInterface (Nested in doirp_v3.v1.element.HsSite.ServerRecord ) doirp_v3/v1/element/hs_site.proto

Spec: Consists of the following data fields: ::= [ ]

A 4-byte integer followed by an array of triplets consisting of . The 4-byte integer specifies the number of triplets. Each triplet lists a service interface provided by the server.

Field Type Description
1 type doirp_v3.v1.element.HsSite.ServerRecord.ServiceInterface.Type

Spec: The is an octet (as a bit mask) that specifies whether the interface is for administration (0x01), resolution (0x02), or both (0x03).

2 transport_protocol doirp_v3.v1.element.HsSite.ServerRecord.ServiceInterface.TransportProtocol

Spec: The is also an octet (as a bit mask) that specifies the protocol. Possible protocols include UDP (0x00), TCP (0x01), HTTP (0x02), and HTTPS (0x03). The following are additional protocols not in the spec: gRPC (0x04)

3 port_number uint32

Spec: The is a 4-byte unsigned integer that specifies the port number used by the interface.The conventional port number used by DO-IRP servers is 2641 for UDP and TCP, and 8000 for HTTP.

message ServerRecord (Nested in doirp_v3.v1.element.HsSite ) doirp_v3/v1/element/hs_site.proto

Spec: Each consists of the following data fields: ::=

Field Type Description
1 id uint32

Spec: A 4-byte unsigned integer that uniquely identifies a server process under the service site. s do not have to begin with 1 and they don't have to be consecutive numbers. They are used to distinguish servers under a service site from each other. Note that there can be multiple servers residing on any given computer, each with a different .

2 address string

represented as text here for convenience

3 public_key doirp_v3.v1.element.HsPubkey

Spec: A 4-byte integer followed by a byte-array that contains the server's public key (server authentication key). The integer specifies the size of the byte-array. For key types described in this specification, the byte-array (for the public key) consists of a number of parts: a UTF8-string that describes the key type, a two-byte option field reserved for future use, and a key-type-dependent number of length-prefixed byte-arrays that describe the public key itself. The key types in current use are "DSA_PUB_KEY," where there are four byte-arrays after the two-byte option field for the four DSA parameters q, p, g, and y; and "RSA_PUB_KEY", where after the two-byte option field are two byte- arrays for the exponent and modulus, followed by an empty byte-array (four zero bytes). Other key types may be useful to consider in the future.

The public key in the can be used to authenticate any service response from the DO-IRP server.

4 service_interface repeated doirp_v3.v1.element.HsSite.ServerRecord.ServiceInterface

service interface provided by the server

message HsSite doirp_v3/v1/element/hs_site.proto

Spec: 4.3.2 SERVICE SITE INFORMATION: HS_SITE

HS_SITE is used to provide information about a DO-IRP service to inform a DO-IRP clients how to contact it. This information specifies the server's address, its protocol version, its public key. Each prefix identifier should have one or more HS_SITE elements in its prefix identifier record. This is called the service information for the prefix and denotes, among other things, the location of servers where any existing identifier that is based on that prefix can be created, updated, deleted, or resolved. A user that tries to resolve an identifier that does not exist will get a “identifier not found” response from the local service specified in the HS_SITE information. Attempts to resolve an invalid identifier, namely one that does not exist within the designated LIS, will get a “identifier not found” response from that local service.

The service information is managed by the system administrator. It must reflect the configuration of the DO-IRP service for each of the prefixes it manages. An additional layer of indirection is provided by the use of HS_SERV, which is called a service identifier; HS_SERV allows multiple prefixes to reference a single set of HS_SITE elements, as described in section 4.3.4. DO-IRP clients depend on the service information to locate a responsible DO-IRP server before they can send their service requests. The service information can also be used by clients to authenticate any service response from the server.

An HS_SITE element is one whose field is HS_SITE and whose field consists of the following entries encoded as binary data:

Spec: A 2-byte value that identifies the version number of the data format used in the encoding of the field of the HS_SITE element. It is defined to allow backward compatibility over time.

Note that this version number is not the same as the DO-IRP protocol version number used in request and response messages.

Field Type Description
1 version uint32

current version number: 1

2 protocol_version_major uint32

Spec: A 2-byte integer value that identifies the highest DO-IRP protocol version understood by servers of the site. The higher byte of the value identifies the major version and the lower byte the minor version. Details of the message format for DO-IRP protocol version 3.0 are specified in section 6.2. Although the terminology used is the same, this field does not denote the protocol version of this DO-IRP specification. Rather, it denotes the protocol version as specified by the prefix administrator for the implementation of the local service that supports the identifier record. Local services which support the DO-IRP protocol version 3.0 specified in this document should be described with HS_SITE elements specifying 3.0.

3 protocol_version_minor uint32
4 serial_number uint32

This should be automatically increased on the IRS service side

5 primary_mask uint32

Spec: An 8-bit mask that identifies the primary site(s) of the DO-IRP service. The first bit of the octet is the bit. It indicates whether the HS_SITE element is a primary site. A primary site is the one that supports administrative operations for its identifiers. The second bit of the octet is the bit. It indicates whether the service has multiple primary sites. A entry with zero value indicates that the service has a single primary site and all administration has to be done at that site. A non-zero entry indicates that the service has multiple primary sites. Each primary site may be used to administer identifiers managed under the service.

6 hash_option doirp_v3.v1.element.HsSite.HashOption

hash option used by the service site to distribute identifiers among its multiple servers; not meaningful for a typical service site with a single server.

7 hash_filter string

Spec: An UTF8-string entry reserved for future use.

8 attributes map<string, string>

represented as map from to here for convenience

9 server_records repeated doirp_v3.v1.element.HsSite.ServerRecord

a list of s each defines a server that is part of the service

message YdAltId doirp_v3/v1/element/yd_alt_id.proto

Field Type Description
1 type string
2 id string

message YdService doirp_v3/v1/element/yd_service.proto

Field Type Description
1 address string
2 version float
3 status bool
4 protocol_version float
5 doa_protocol string

Enums

enum Permission doirp_v3/v1/element/hs_admin.proto

The set of possible permissions for an administrator. This is for generating consts, won't be used directly in .proto files.

Name Number Description
PERMISSION_UNSPECIFIED 0
PERMISSION_ADD_IDENTIFIER 1

Spec: Add_Identifier (0x0001) This permission, when set in a prefix identifier record, allows an authenticated administrator to create new identifiers under that prefix. This permission is only meaningful when set in an identifier record pertaining to a prefix, as it is a prefix-only permission.

PERMISSION_DELETE_IDENTIFIER 2

Spec: Delete_Identifier (0x0002) This permission allows an authenticated administrator to delete the identifier record.

PERMISSION_ADD_DERIVED_PREFIX 4

Spec: Add_Derived_Prefix (0x0004) This permission, when set in a prefix identifier record, allows an authenticated administrator to create new prefixes derived from the stated prefix identifier. This permission is only meaningful when set in a prefix identifier record and it is a prefix-only permission.

PERMISSION_RESERVED 8

Spec: Reserved (0x0008) This bit is reserved for historical reasons.

PERMISSION_MODIFY_ELEMENT 16

Spec: Modify_Element (0x0010) This permission allows an authenticated administrator to modify any elements other than HS_ADMIN elements. HS_ADMIN elements are used to define administrators and are managed by a different set of permissions (as described next).

PERMISSION_DELETE_ELEMENT 32

Spec: Delete_Element (0x0020) This permission allows an authenticated administrator to delete any element other than the HS_ADMIN elements.

PERMISSION_ADD_ELEMENT 64

Spec: Add_Element (0x0040) This permission allows an authenticated administrator to add elements other than the HS_ADMIN elements.

PERMISSION_MODIFY_ADMIN 128

Spec: Modify_Admin (0x0080) This permission allows an authenticated administrator to modify HS_ADMIN elements.

PERMISSION_REMOVE_ADMIN 256

Spec: Remove_Admin (0x0100) This permission allows an authenticated administrator to remove HS_ADMIN elements.

PERMISSION_ADD_ADMIN 512

Spec: Add_Admin (0x0200) This permission allows an authenticated administrator to add new HS_ADMIN elements.

PERMISSION_AUTHORIZED_READ 1024

Spec: Authorized_Read (0x0400) This permission grants an authenticated administrator read-access to elements with the ADMIN_READ and without PUBLIC_READ permission. Administrators without this permission will not have access to elements that require authentication for read access.

PERMISSION_LIST_IDENTIFIERS 2048

Spec: List_Identifiers (0x0800) This permission allows an authenticated administrator to list all identifiers under a designated prefix, even if such identifiers are managed in a distributed fashion on multiple servers. Identifiers that are based on prefixes derived from the specified prefix are not included in the listing. This is a prefix-wide setting and must be set on the respective prefix identifier record.

PERMISSION_LIST_DERIVED_PREFIXES 4096

Spec: List_Derived_Prefixes (0x1000) This permission allows the administrator to list all prefixes derived from a designated prefix. If such derived prefixes have in turn their own derived prefixes, those further derivatives are also included in the listing as long as such derived prefix records are on the same DO-IRP service on which this listing operation is performed. This is a prefix-wide setting and must be set on a prefix identifier record.

enum Type doirp_v3/v1/element/hs_pubkey.proto

This is for generating consts, won't be used directly in .proto files.

Name Number Description
TYPE_DSA_PUB_KEY 0
TYPE_RSA_PUB_KEY 1

enum Type doirp_v3/v1/element/hs_site.proto

Name Number Description
TYPE_UNSPECIFIED 0
TYPE_ADMINISTRATION 1
TYPE_RESOLUTION 2
TYPE_BOTH 3

enum TransportProtocol doirp_v3/v1/element/hs_site.proto

Name Number Description
TRANSPORT_PROTOCOL_UDP 0
TRANSPORT_PROTOCOL_TCP 1
TRANSPORT_PROTOCOL_HTTP 2
TRANSPORT_PROTOCOL_HTTPS 3
TRANSPORT_PROTOCOL_GRPC 4

enum HashOption doirp_v3/v1/element/hs_site.proto

Name Number Description
HASH_OPTION_HASH_BY_PREFIX 0
HASH_OPTION_HASH_BY_SUFFIX 1
HASH_OPTION_HASH_BY_IDENTIFIER 2