DRIP Entity Tag (DET) Identity Management Architecture

2.1. Supported Scenarios

1. UA using manufacturer generated Serial Number for UAS ID. No additional information provided.¶
2. UA using manufacturer generated Serial Number for UAS ID. Manufacturer using a DIME. Manufacturer MUST provided pointer to additional information via DNS (even if null).¶
3. UA using manufacturer generated Serial Number which is mapped to a DET by manufacturer for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. Manufacturer MUST provide pointer to additional information via DNS (even if null).¶
4. UA using manufacturer generated DRIP enhanced Serial Number for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public information into DNS (i.e. HI) - either directly or as a mapping to a DET. DIME MUST provide pointer to additional information via DNS (even if null).¶
5. UA using manufacturer generated Serial Number for UAS ID. UA using user generated DET for Authentication. User uses DIME with capability to publically map Serial Number to a DET (via a USS). DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. DIME MUST provide pointer to additional information via DNS (even if null).¶
6. UA provisioned with DET (i.e. Session ID) with a DIME (via a USS) for UAS ID and Authentication. DIME MUST place public DET information into DNS (i.e. HI). DIME MUST NOT (unless required) provide mapping of DET to Serial Number in DNS. USS MUST provide pointer to additional information via DNS (even if null).¶

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 [drip-arch], while others (RAA, HDA, etc.) are from [RFC9374].¶

3.3. Role Abbreviation in DETs

On receiver devices a DET can be translated to a more human readable form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4 Characters of DET Hash}. An example of this would be US FAA FE23. To support this DIMEs are RECOMMENDED to have an abbreviation that could be used for this form. These abbreviations SHOULD be a maximum of six characters in length. Spaces MUST NOT be used and be replaced with either underscores (_) or dashes (-).¶

For RAAs allocated in the ISO range Section 4.2.1, the abbreviation MUST be set to the ISO 3166-1 country code (either Alpha-2 or Alpha-3).¶

If a DIME does not have an abbreviation or it can not be looked up then the receiver MUST use the uppercase 4-character hexadecimal encoding of the field it is missing.¶

3.4. 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 contigous 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) is allocated to the DRIP working group itself. 16380 to 16383 are setup by DRIP experts to act as RAAs for potentional HDA users to test against. 16383 is setup to be an RAA to act as a MCA Section 4.2.2 for UAS manufacturers to test their HDAs against and have their Manufacturer Code properly managed. The rest of the range (16376 to 16379) are reserved to be allocate by the DRIP experts to buisnesses that wish to test being an RAA.¶

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 infrastucture (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. The Serial Number SHOULD be encrypted 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.¶

mfr_int = base34_decode(mfr_code)
hid = (4000 << 14) + mfr_int
mfr_code = base34_encode(hid)

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. Serial Number

There are four ways a Serial Number is supported by DRIP:¶

1. As a clear-text string with additional information (Section 6.1.1)¶
2. As a clear-text string mapped to a DET "post" generation by the manufacturer (for use in authentication) and additional information (Section 6.1.2)¶
3. As a clear-text string mapped to a DET "post" generation by the user (via an HDA) (for use in authentication) and additional information (Section 6.1.3)¶
4. As an encoding of an HI and associated DET by the manufacturer (for use in authentication) with additional information (Section 6.1.4)¶

• Note: additional information here refers to any subset of keys defined in Section 11.1.1.¶

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

(a) Serial Number,
    UA Information
(b) Success Code
(c) URI RR
(d) UA Information

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

(a) Serial Number,
    UA Information,
    Self-Endorsement: UA
(b) Success Code,
    Broadcast Endorsement: MAA on UA
(c) DET RR, PTR RR
(d) UA Information

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

(a) Serial Number,
    UA Information,
    Self-Endorsement: UA
(b) Success Code,
    Broadcast Endorsement: DIME on UA
(c) DET RR
(d) UA Information

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

(a) Serial Number,
    UA Information,
    Self-Endorsement: UA
(b) Success Code,
    Broadcast Endorsement: MAA on UA
(c) DET RR
(d) UA Information

6.2. 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) DET 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.3. Session ID

Session IDs are generally handled by HDAs. In Figure 13 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) DET 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 13 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,
    * tstr: any
}

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

6.4. 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,
    CERT RRs
(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 an DET RRtype and not a PTR RRtype.¶

<domain> DET IN ( OGAID DET HI RVS HID [SN] URI Endorsement )

OGAID = Integer value of OGA ID -- taken from HIP RR
DET = Base16 DET -- taken from HIP RR
HI = Base64 Host Identity -- taken from HIP RR
RVS = List of Rendevous Server addresses -- taken from HIP RR
HID = HID Abbreviation
SN = Serial Number
URI = URI to associated DIA
Endorsement = Broadcast Endorsements in CBOR encoding

8.2. Serial Numbers & Other UAS ID Types

• Author Note: There MUST be an entry point in DNS for the lookup of UAS Serial Numbers. This section is very much a shot in the dark.¶

This document specifies the creation and delegation to ICAO of the subdomain uas.icao.arpa. To enable lookup of Serial Numbers a subdomains of sn.uas.icao.arpa is maintained. All entries under sn.uas.icao.arpa are to follow the convention found in Appendix A.2. This is to enable a singular lookup point for Serial Numbers for UAS.¶

Note that other subdomains under uas.icao.arpa can be made to support other identifiers in UAS. The creation and use of other such other subdomains are out of scope for this document. The further use and creation of items under icao.arpa is the authority of ICAO (which has been delegated control).¶

DETs MUST not have a subdomain in uas.icao.arpa (such as det.uas.icao.arpa) as they fit within the predefined ip6.arpa as they are IPv6 addresses.¶

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 general aviation certificates as discussed below.¶

A Certificate Authority (CA) supporting DRIP entities MAY adhere to the ICAO's Aviation Common Certificate Policy (ACCP) [ICAO-IATF-CP-draft]. 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.¶

• 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 a 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.¶

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

TBD¶

10.4. Alternative Certificate Encoding

(CBOR encoded certs here. TBD)¶

11.1. 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.4 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.¶

A.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: .det.uas.icao.arpa.
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.det.uas.icao.arpa.

A.2. UAS Serial Number

• {id}.{length}.{manufacturer-code}.{apex}.¶

Apex: .sn.uas.icao.arpa.
Serial: MFR0ADR1P1SC00L
Manufacturer Code: MFR0
Length: A
ID: DR1P1SC00L
FQDN: dr1p1sc00l.a.mfr0.sn.uas.icao.arpa.

B.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.¶

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

B.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 concatination of a child entities (e.g. a UA) 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

C.1. Serial Method 1

@ORIGIN mfr0.uas-sn.arpa
example1.8 IN URI ( https://example.com/sn/EXAMPLE1 )

C.2. Serial Method 2

@ORIGIN mfr0.uas-sn.arpa
example2.8 IN DET ( 5 20010033e872f705f3ce91124b677d65 ... "MFR MFR0" MFR08EXAMPLE2 https://example.com/sn/EXAMPLE2 ... active )

@ORIGIN 3.2.f.7.0.f.a.1.3.0.0.1.0.0.2.ip6.arpa
6.5.d.7.7.6.b.4.2.1.1.9.e.c.3.f.5.0 IN PTR example2.8.mfr0.uas-sn.arpa

C.3. Serial Method 3

@ORIGIN mfr0.uas-sn.arpa
example3.8 IN DET ( 5 20010033e872f70584b1fa2b70421112 ... "MFR MFR0" MFR08EXAMPLE3 https://example.com/sn/EXAMPLE3 ... active )

@ORIGIN 3.2.f.7.0.f.a.1.3.0.0.1.0.0.2.ip6.arpa
2.1.1.1.2.4.0.7.b.2.a.f.1.b.4.8.5.0 IN PTR example3.8.mfr0.uas-sn.arpa

C.4. Serial Method 4

@ORIGIN mfr0.uas-sn.arpa
example4.8 IN DET ( 5 20010033e872f705ba8af5252a35030e ... "MFR MFR0" MFR08EXAMPLE4 https://example.com/sn/EXAMPLE4 ... active )

@ORIGIN 3.2.f.7.0.f.a.1.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 PTR example4.8.mfr0.uas-sn.arpa

C.5. Operator

@ORIGIN 0000.3ffe.2001003.hhit.arpa
ba8af5252a35030e.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff800005ba8af5252a35030e ... "TEST DRIP" null https://example.com/operator/* ... active )

@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 PTR ba8af5252a35030e.05.0000.3ffe.2001003.hhit.arpa

C.6. Session ID

@ORIGIN 0000.3ffe.2001003.hhit.arpa
b6ce935b616306d4.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff800005b6ce935b616306d4 ... "TEST DRIP" null https://example.com/session/* ... active )

@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 PTR b6ce935b616306d4.05.0000.3ffe.2001003.hhit.arpa

C.7. 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 PTR 4e486394a60bb669.05.0000.3ffe.2001003.hhit.arpa

@ORIGIN 0000.3ffe.2001003.hhit.arpa
4e486394a60bb669.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff8000054e486394a60bb669 ... "TEST DRIP" null https://example.com/session/* ... active )