DRIP Entity Tag (DET) Identity Management Architecture

3.1. Required 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.¶

3.2. Additional Definitions

This document makes use of the terms (PII, USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374].¶

3.3. Text Conventions

When talking about a DIME in documents it should be referred to as the role it is serving. For example a CAA level DIME running services both as an RAA (its primary role in the hierarchy) and as an HDA (optionally) would be be referred to "RAA" when performing its RAA duties and "HDA" when performing its HDA duties. The rest of the document will follow this convention unless verbosity or clarity is needed.¶

4.1. Apex

The Apex is a special DIME role that holds the values of RAA=0-3 and HDA=0. It serves as the branch point from the larger DNS system in which DETs are defined. The Apex is the owner of the IPv6 prefix portion of the DET associated with it (2001:30/28) which is assigned by IANA from the special IPv6 address space for ORCHIDs.¶

The Apex manages all delegations and allocations of the DET's RAA to various parties. Allocations of RAAs SHOULD be done in contiguous groups of 4.¶

• Note: that the first column of this table is decimal values not hexadecimal.¶

RAA values of 0 (0x0000) to 3 (0x0003) are reserved to the Apex exclusively.¶

The Experimental range of 16376 (0x3FF8) to 16383 (0x3FFF), eight (8) RAAs, is allocated to the DRIP working group itself. 16376 to 16379 are setup by DRIP experts to act as RAAs for potential HDA users to test against. RAA 16376 is already "in use" with driptesting.org. The rest of the range (16377 to 16383) are reserved to be allocate by the DRIP experts to agencies that wish to test.¶

4.2. Registered Assigning Authority (RAA)

RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field, i.e. 16,384 RAAs, of an DET). An RAA is a business or organization that manages a DIME of HDAs (Section 4.3). Most are contemplated to be Civil Aviation Authorities (CAA), such as the Federal Aviation Authority (FAA), that then delegate HDAs to manage their National Air Space (NAS). This is does not preclude other entities to operate an RAA if the Apex allows it.¶

An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. It must maintain a DNS zone minimally for discovering HID RVS servers. All RAA's have a single reserved HDA value: 0 (0x0000) for itself to support various functions or services. Other HDA values can be allocated or reserved per RAA policy.¶

4.3. Hierarchial HIT Domain Authority (HDA)

An HDA may be an USS, ISP, or any third party that takes on the business to register the actual entities that need DETs. This includes, but is not limited to UA, GCS, UAS Operators and infrastructure (such as Supplemental Data Service Providers). It should also provide needed UAS services including those required for HIP-enabled devices (e.g. RVS).¶

A primary function of HDAs for DRIP, in the context of UAS RID is the binding between a UAS Session ID (for DRIP the DET) and the UA Serial Number. The Serial Number MUST have its access protected to allow only authorized parties to obtain it. The Serial Number MUST be protected in a way only the authorized party can decrypt. As part of the UTM system HDAs can also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent. They may either be a direct logical part of a UAS Service Supplier (USS) or be a UTM wide service to USS's.¶

The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by an RAA. An HDA should maintain a set of RVS servers for UAS clients that may use HIP. How this is done and scales to the potentially millions of customers are outside the scope of this document. This service should be discoverable through the DNS zone maintained by the HDA's RAA.¶

An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such policy is out of scope.¶

5.1. DRIP Provisioning Agent (DPA)

The DPA performs the important task of vetting information coming from clients wishing to register and then delegate (internally or externally) various items to other components in the DIME.¶

A standard interface MUST be provided for clients to access. An HTTPS based interface is RECOMMENDED. This interface specification is out of scope for this document.¶

There MUST be an interface from the DPA to a Registry (Section 5.2) component which handles the DNS specific requirements of the DIME as defined by the Registry. There MAY also be interface from the DPA to a DRIP Information Agent (Section 5.4) as defined by the DIA.¶

+-------------+
| Registering |
|   Client    |
+------o------+
       |
       | HTTPS
       |
       |
    +--o--+           +-----+
    | DPA o-----------o DIA |
    +--o--+    TBD    +-----+
       |
       |
       | HTTPS or EPP
       |
+------o---+
| Registry |
+----------+

5.2. Registry

The Registry component handles all the required DNS based requirements of the DIME to function for DRIP. This includes the registration and maintenance of various DNS Resource Records.¶

A standardized interface MUST be implemented for interactions with the DPA (Section 5.1). This interface MAY be over HTTPS using JSON/CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP) [RFC5730]. The detailed specification of either of these interfaces is out of scope for this document.¶

There MAY be interface from the Registry to a DRIP Information Agent (Section 5.4) as defined by the DIA.¶

    +-----+
    | DPA |
    +--o--+
       |
       | HTTPS or EPP
       |
       |
+------o---+           +-----+
| Registry o-----------o DIA |
+-----o----+    TBD    +-----+
      |
      |
      | TBD
      |
  +---o--+
  |  NS  |
  +------+

5.3. Name Server (NS)

The interface of the Name Server to any component (nominally the Registry) in a DIME is out of scope as typically they are implementation specific.¶

• Author Note: This may be very important here as we should not preclude a USS from running his own Name Server but they are not DNS experts and will need guidance or at least pointers to it to not mess it up. Such as SOA and NS formats to allow delegation if acting as an RAA.¶

+----------+
| Registry |
+-----o----+
      |
      |
      | TBD
      |
  +---o--+
  |  NS  |
  +--o---+
     |
     |
     | DNS Query/Response
     |
+----o----------+
| Lookup Client |
+---------------+

5.4. DRIP Information Agent (DIA)

The DIA is the main component handling requests for information from entities outside of the DIME. Typically this is when an Observer looks up a Session ID from an UA and gets pointed to the DIA to obtain information not available publicly (i.e. via DNS).¶

The information contained in the DIA is generally more oriented around the Operator of a given UAS and is thus classified as Personally Identifiable Information (PII). To protect the privacy of an Operator of the UAS this information is not publicly accessible and is only available behind policy driven differentiated access mechanisms (see Section 7).¶

For DRIP, the Registration Data Access Protocol (RDAP) ([RFC7480], [RFC9082] and [RFC9083]) is the selected protocol to provide policy driven differentiated access for queries of information from clients.¶

There MUST be a standardized interface for the DPA or Registry to add, update or delete information into the DIA. Specific details for these interfaces are out of scope for this document.¶

An interface defined by the Registration Data Directory Service (RDDS) (Section 5.5) is also required as specified by the RDDS.¶

                         +-----+
                         | DPA |
                         +--o--+
                            |
                            |
                            | TBD
                            |
  +----------+    TBD    +--o--+             +------+
  | Registry o-----------o DIA o-------------o RDDS |
  +----------+           +--o--+     TBD     +------+
                            |
                            |
                       RDAP |
                            |
                    +-------o-------+
                    | Lookup Client |
                    +---------------+

5.5. Registration Data Directory Service (RDDS)

This is the primary information database for the DIA. An interface MUST be provided to the DIA but its specification is out of scope for this document.¶

   +-----+
   | DIA |
   +--o--+
      |
      |
      | TBD
      |
  +---o--+
  | RDDS |
  +--o---+
     |
     |
     | RDAP
     |
+----o----------+
| Lookup Client |
+---------------+

6.1. Operator

Provided either by USS or CAA run HDAs. Regulation might require interaction between them. An Operator can request that certain information normally generated and provisioned into DNS be omitted due to privacy concerns.¶

    +----------+
    | Operator |
    +--o---o---+
       |   ^
   (a) |   | (b)
       |   |
*******|***|*****************************
*      |   |    DIME:HDA                *
*      |   |                            *
*      v   |             +----------+   *
*   +--o---o--+          |          |   *
*   |   DPA   o--------->o          |   *
*   +----o----+   (d)    |          |   *
*        |               |          |   *
*        | (c)           | DIA/RDDS |   *
*        v               |          |   *
*   +----o--------+      |          |   *
*   | Registry/NS |      |          |   *
*   +-------------+      |          |   *
*                        +----------+   *
*                                       *
*****************************************

(a) Operator Information,
    Operator Self-Endorsement
(b) Success Code,
    Generic Endorsement: HDA on Operator
(c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR
(d) Operator Information

Note: (c) MAY be requested by the Operator
      to be omitted due to PII concerns.

The definition of Operator Information is out of scope of this document and left to local regulations (both in its format and contents).¶

6.2. Session ID

Session IDs are generally handled by HDAs. In Figure 9 the UAS comprises of an unmanned aircraft and a Ground Control Station (GCS). Both parties are involved in the registration process.¶

    +---------+
    |   UAS   |
    +--o---o--+
       |   ^
   (a) |   | (b)
       |   |
*******|***|*****************************
*      |   |    DIME: HDA               *
*      |   |                            *
*      v   |             +----------+   *
*   +--o---o--+          |          |   *
*   |   DPA   o--------->o          |   *
*   +----o----+   (d)    |          |   *
*        |               |          |   *
*        | (c)           | DIA/RDDS |   *
*        v               |          |   *
*   +----o--------+      |          |   *
*   | Registry/NS |      |          |   *
*   +-------------+      |          |   *
*                        +----------+   *
*                                       *
*****************************************

(a) Mutual Endorsement: HDA on GCS,
    Generic Endorsement: GCS on UA,
    Session ID Information
(b) Success Code,
    Broadcast Endorsement: HDA on UA,
    Generic Endorsement: HDA on UAS
(c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR
(d) Session ID Information

Through mechanisms not specified in this document the Operator should have methods (via the GCS) to instruct the unmanned aircraft onboard systems to generate a keypair, DET and Self-Endorsement: UA. The Self-Endorsement: UA is extracted by the Operator onto the GCS.¶

The GCS is already pre-provisioned and registered to the DIME with its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement: HDA on GCS. The GCS creates a new Generic Endorsement: GCS on UA and also creates Mutual Endorsement: HDA on GCS. These new endorsements along with Session ID Information are sent to the DIME via a secure channel.¶

The GCS injects the Broadcast Endorsement: HDA on UA securely into the unmanned aircraft. Endorsement: HDA on GCS is securely stored by the GCS.¶

• Note: in Figure 9 the Session ID Information is expected to contain the Serial Number along with other PII specific information (such as UTM data) related to the Session ID.¶

Session ID Information is defined as the current model:¶

sessionid_info = {
    serial: tstr .size 20,
    session_id: tstr,
    operational_intent: tstr,
    intent_src: tstr,
    operator_id: tstr,
    session_context: tstr,
    * tstr: any
}

Future standards or implementations MAY add other keys to this list (for local features and/or local regulation).¶

6.3. Child DIME

Handled by the Apex and RAA's. This is an endpoint that handles dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to Apex and HDAs to RAAs) in the hierarchy.¶

    +---------------+
    |   DIME: HDA   |
    +--o---o--------+
       |   ^
   (a) |   | (b)
       |   |
*******|***|*****************************
*      |   |    DIME: RAA               *
*      |   |                            *
*      v   |             +----------+   *
*   +--o---o--+          |          |   *
*   |   DPA   o--------->o          |   *
*   +----o----+   (d)    |          |   *
*        |               |          |   *
*        | (c)           | DIA/RDDS |   *
*        v               |          |   *
*   +----o--------+      |          |   *
*   | Registry/NS |      |          |   *
*   +-------------+      |          |   *
*                        +----------+   *
*                                       *
*****************************************

(a) Self-Endorsement: HDA,
    HDA Information or
    Generic Endorsement: old HDA, new HDA
(b) Success Code,
    Broadcast Endorsement: RAA on HDA
(c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR
(d) HDA Information

It should be noted that this endpoint DOES NOT hand out dynamically RAA/HDA values to systems that hit the endpoint. This is done out-of-band through processes specified by local regulations and performed by cognizant authorities. The endpoint MUST NOT accept queries it is not previously informed of being expected via mechanisms not defined in this document.¶

It is OPTIONAL to implement this endpoint. This MAY be used to handle lower-level DIME key roll-over.¶

8.1. DRIP Entity Tags

The REQUIRED mechanism is to place any information into ip6.arpa when using a DET. Since the DET is an IPv6 address it can be nibble-reversed and used in the zone, per standard conventions.¶

The prefix 2001:30/28 is registered with IANA [RFC9374] and 3.0.0.1.0.0.2.ip6.arpa - the corresponding reverse domain - SHOULD be under the administrative control of the Apex. In addition to the DNS infrastructure for 3.0.0.1.0.0.2.ip6.arpa, the Apex SHOULD be responsible for the allocation of IPv6 addresses in this prefix. An addressing plan will need to be developed.¶

Distribution of HHIT (IPv6 address) blocks SHOULD be done using the 14-bit RAA space as a framework. The Apex SHOULD allocate blocks to each entity who can then assign them to HDAs in accordance with local law and policy. All HDAs MUST have an IPv6 address in 2001:30/28. A discrete zone SHOULD be delegated for each HDA. These MUST contain an DET resource record (Section 8.1.1) for itself.¶

Reverse lookups of these IPv6 addresses will translate the address into a domain name in the manner defined in [RFC1886]. However, these lookups will query for, depending on what is required: HIP, DET, TLSA, URI, or PTR RRTypes.¶

<domain> DET IN ( DET TYPE STATUS HID SN Endorsement )

DET = Base16 DET
TYPE = enumeration of Type of DET
STATUS = enumeration of Status of DET
HID = HID Abbreviation
SN = Serial Number
Endorsement = Broadcast Endorsement

9.1. Endorsement Structure

endorsement = {
    ; TODO: add tag for self-describing type or leave up to cbor?
    scope: {
        vnb: number,
        vna: number,
        * tstr => any
    },
    evidence: bstr,
    endorser: {
        identity: {
            hhit: bstr .size 16, ? hi: bstr // * tstr => any
        },
        signature: {
            sig: bstr,
            * tstr => any
        }
    }
}

10.1. Certificate Policy and Certificate Stores

X.509 certificates are optional for the DRIP entities covered in this document. DRIP endpoint entities (EE) (i.e., UA, GCS, and Operators) may benefit from having X.509 certificates. Most of these certificates will be for their DET and some will be for other UAS identities. To provide for these certificates, some of the other entities (e.g. USS) covered in this document will also have certificates to create and manage the necessary PKI structure.¶

Three certificate profiles are defined, with examples, and explained in [drip-dki]. Each has a specific role to play and an EE may have its DET enrolled in all of them. There is a 'Lite' profile that would work well enough on constrained communication links for those instances where various issues push the use of X.509. There is a 'Basic; profile that is more in line with [RFC5280] recommendations, but is still small enough for many constrained environments. Finally there is a profile to directly add DET support into the civil/general aviation certificates as discussed below.¶

A Certificate Authority (CA) supporting DRIP entities MAY adhere to the ICAO's Aviation Common Certificate Policy (ACCP). The CA(s) supporting this CP MUST either be a part of the ACCP cross-certification or part of the ACCP CA Trust List. It is possible that future versions of the ACCP will directly support the DRIP Basic profile.¶

• Authors Note: ACCP is ICAO Doc 10169 Aviation Common Certificate Policy (ACCP). I can't get a url for that, but so far these is no changes from v 0.93 of the old IATF CP; changes are in the works then will be posted, so continue to reference IATF CP¶

EEs may use their X.509 certificates, rather than their rawPublicKey (i.e. HI) in authentication protocols (as not all may support rawPublicKey identities). Short lived DETs like those used for a single operation or even for a day's operations may not benefit from X.509. Creating then almost immediately revoking these certificates is a considerable burden on all parts of the system. Even using a short notAfter date will not completely mitigate the burden of managing these certificates. That said, many EEs will benefit to offset the effort. It may also be a regulator requirement to have these certificates. Finally, certificates can provide the context of use for a DET (via policy constraint OIDs).¶

Typically an HDA either does or does not issue a certificate for all its DETs. An RAA may specifically have some HDAs for DETs that do not want/need certificates and other HDAs for DETs that do need them. These types of HDAs could be managed by a single entity thus providing both environments for its customers.¶

It is recommended that DRIP X.509 certificates be stored as DNS TLSA Resource Records, using the DET as the lookup key. This not only generally improves certificate lookups, but also enables use of DANE [RFC6698] for the various servers in the UTM and particularly DIME environment and DANCE [dane-clients] for EEs (e.g. [drip-secure-nrid-c2]). All DRIP certificates MAY alternatively be available via RDAP. LDAP/OCSP access for other UTM and ICAO uses SHOULD also be provided.¶

10.2. Certificate Management

PKIX standard X.509 issuance practices should be used. The certificate request SHOULD be included in the DET registration request. A successful DET registration then MUST include certificate creation, store, and return to the DET registrant. It is possible that the DET registration is actually an X.509 registration. For example, PKIX CSR may be directly used and the DET registration and Endorsement creation are a addition to this process. Further ACME may be directly extendable to provide the DET registration.¶

Note that CSRs do not include the certificate validityDate; adding that is done by the CA. If in the registration process, the EE is the source of notBefore and notAfter dates, they need to be sent along with the CSR.¶

Certificate revocation will parallel DET revocation. TLSA RR MUST be deleted from DNS and RDAP, LDAP, and OCSP return revoked responses. CRLs SHOULD be maintained per the CP.¶

10.3. Examples

For full examples of X.509 Certificates and the process to use them see [drip-dki].¶

10.4. Alternative Certificate Encoding

The CBOR Encoded X.509 Certificates (C509 Certificates) [cbor-cert] provides a standards-based approach to reduce the size of X.509 certificates both on-the-wire and in storage. The PKI-Lite RAA certificate example in Appendix B.2 is 331 bytes. The matching C509 certificate is 183 bytes. This sort of difference may have significant impact both on UAS storage requirements and over-the-air transmission impact.¶

C509 provides two approaches for encoding X.509:¶

1. An invertible CBOR re-encoding of DER encoded X.509 certificates [RFC5280], which can be reversed to obtain the original DER encoded X.509 certificate.¶
2. Natively signed C509 certificates, where the signature is calculated over the CBOR encoding instead of over the DER encoding as in 1. This removes the need for ASN.1 and DER parsing and the associated complexity but they are not backwards compatible with implementations requiring DER encoded X.509.¶

The invertible CBOR encoding may be sufficient for most needs. The CBOR objects clearly indicate which approach was used, so that the receiver can properly process the C509 object. For interoperability in DRIP, it is recommended that invertible CBOR encoding be used.¶

Using the invertible CBOR encoding is achieved through in-line libraries that convert in the desired direction. Since it is not expected that DNS protocols to implement this conversion, the DET RR SHOULD contain the normal X.509 DER encoding. The CBOR encoding MAY be used, but operational experience will be needed to see if there are measurable gains in doing so.¶

11.1. Delegation of Nibble Reversed IPv6 Prefix

For DRIP to function in a interoperable way the easiest way to allow look up of DETs is through the already existing ip6.arpa domain structure (as defined in this document). Here IPv6 addresses are nibble reversed and usually have PTR records.¶

With DRIP the prefix 2001:30/28 has been allocated by IANA already for DRIP use. However its representative reverse domain in ip6.arpa has not.¶

There are a number of questions in this area for DRIP:¶

1. What organization would have administrative control over the nibble-reversed ip6.arpa block for 2001:30/28?¶

   • How do they obtain this and from whom?¶
   • What is the SLA between IANA/ICANN and the administrative organization for nibble-reversed 2001:30/28?¶
2. What organization would have technical control (i.e. day to day operations) over the nibble-reversed ip6.arpa block for 2001:30/28?¶

3. How are delegation/allocation of further nibble-reversed sub-blocks from 2001:30/28 handled by the administrative organization?¶

   • This is partly covered in this document already (Apex->RAA->HDA)¶
   • What is the SLA between the administrative organization and sub-organizations given delegations/allocations? This might be more general guidelines than an actual SLA?¶
4. What goes into a nibble-reversed ip6.arpa domain for DRIP at each level?¶

This is not an exhaustive list of questions, this is more to get discussion going.¶

11.2. IANA DRIP Registry

12.1. Key Rollover & Federation

During key rollover the DIME MUST inform all children and parents of the change - using best standard practices of a key rollover.¶

A DET has a natural ability for a single DIME to hold different cryptographic identities under the same HID values. This is due to the lower 64-bits of the DET being a hash of the public key and the HID of the DET being generated. As such during key rollover, only the lower 64-bits would change and a check for a collision would be required.¶

This attribute could also allow for a single DIME to be "federated" across multiple DETs sharing the same HID value. This method of deployment has not been thoroughly studied at this time. An endpoint such as in Section 6.3 is a possible place to have these functions.¶

12.2. DET Generation

• Author Note: is this section valid anymore? Perhaps we hard specify that devices ONLY generate on their own hardware instead of "out-sourcing" as this section implies.¶

Under the FAA [NPRM], it is expecting that IDs for UAS are assigned by the UTM and are generally one-time use. The methods for this however are unspecified leaving two options.¶

Option 1:¶

• The entity generates its own DET, discovering and using the RAA and HDA for the target DIME. The method for discovering a DIME's RAA and HDA is out of scope here. This allows for the device to generate an DET to send to the DIME to be accepted (thus generating the required Self-Endorsement) or denied.¶

Option 2:¶

• The entity sends to the DIME its HI for it to be hashed and result in the DET. The DIME would then either accept (returning the DET to the device) or deny this pairing.¶

Keypairs are expected to be generated on the device hardware it will be used on. Due to hardware limitations and connectivity it is acceptable, though not recommended, under DRIP to generate keypairs for the Aircraft on Operator devices and later securely inject them into the Aircraft. The methods to securely inject and store keypair information in a "secure element" of the Aircraft is out of scope of this document.¶

B.1. DRIP Entity Tag

• {hash}.{oga_id}.{hda}.{raa}.{prefix}.{apex}.¶

When building a DET FQDN it MUST must be built using the exploded (all padding present) form of the IPv6 address.¶

Apex: .example.com
DET: 2001:0030:0280:1405:c465:1542:a33f:dc26
ID: c4651542a33fdc26
OGA: 05
HID: 0028014
HDA: 0014
RAA: 000a
Prefix: 2001003
FQDN: c4651542a33fdc26.05.0014.000a.2001003.example.com

C.1. Generic Endorsement

generic_endorsement = {
    scope: {
        vnb: number,
        vna: number
    },
    evidence: bstr,
    endorser: {
        identity: {
            hhit: bstr .size 16
        },
        signature: {
            sig: bstr
        }
    }
}

evidence is a binary string with specified contents (in format and ordering) by specific use-cases. As an example this format is used by [drip-auth] to support Authentication over F3411 constrained links. evidence data is defined by [drip-auth] for DRIP Wrapper, Manifest and Frame formats.¶

C.2. Self Endorsement

self_endorsement = {
    scope: {

        vnb: number,
        vna: number
    },
    evidence: bstr,
    endorser: {
        identity: {
            hhit: bstr .size 16
        },
        signature: {
            sig: bstr
        }
    }
}

Used during registration process as an input. evidence is filled with the corresponding HI of the hhit.¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                              VNB                              |
+---------------+---------------+---------------+---------------+
|                              VNA                              |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                              HI                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                             HHIT                              |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                           Signature                           |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

TODO

C.3. Broadcast Endorsement

broadcast_endorsement = {
    scope: {
        vnb: number,
        vna: number
    },
    evidence: bstr,
    endorser: {
        identity: {
            hhit: bstr .size 16
        },
        signature: {
            sig: bstr
        }
    }
}

Defined by [drip-auth] in a binary format to support Authentication over F3411 constrained links. Used in the DRIP Link format. A required output of registration to a DIME at any level. evidence is a binary string of the concatenation of a child entities (e.g. a UA) DET/HHIT and its associated HI. hhit is of the parent entity (e.g. a DIME).¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                              VNB                              |
+---------------+---------------+---------------+---------------+
|                              VNA                              |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                             Child                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                             HI of                             |
|                             Child                             |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                            Parent                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                           Signature                           |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

TODO

D.1. Operator

@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN DET
( 2001003fff800005ba8af5252a35030e 0 1 "TEST DRIP" "" ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN HIP
( 5 2001003fff800005ba8af5252a35030e ... )
e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN URI
( https://example.com/operator/* )

D.2. Session ID

@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN DET
( 2001003fff800005b6ce935b616306d4 0 1 "TEST DRIP" "" ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN HIP
( 5 2001003fff800005b6ce935b616306d4 ... )
4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN URI
( https://example.com/session/* )

D.3. Child DIME

RAA:
@ORIGIN 8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
0.0.0 IN NS 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa

HDA:
@ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN DET
( 2001003fff8000054e486394a60bb669 0 1 "TEST DRIP" "" ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN HIP
( 5 2001003fff8000054e486394a60bb669 ... )
9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN URI
( https://example.com/dime/* )