| Internet-Draft | registries | May 2022 |
| Wiethuechter (Editor), et al. | Expires 12 November 2022 | [Page] |
This document creates the DRIP DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., RAA, HDA, UA, GCS, USS). The registration process will use the Extensible Provisioning Protocol (EPP) and other protocols. The discovery process will leverage DNS and DNSSEC and related technology. The DETs can be registered with as their "raw public keys" or in X.509 certificates.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 November 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Registries are fundamental to RID. Only very limited information can be Broadcast, but extended information is sometimes needed. The most essential element of information sent is the UAS ID itself, the unique key for lookup of extended information in registries.¶
While it is expected that registry functions will be integrated with USS, who will provide them is not yet determined in most, and is expected to vary between, jurisdictions. However this evolves, the essential registry functions, starting with management of identifiers, are expected to remain the same, so are specified herein.¶
While most data to be sent via Broadcast or Network RID is public, much of the extended information in registries will be private. Thus AAA for registries is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose, etc. As specific AAA requirements will vary by jurisdictional regulation, provider philosophy, customer demand, etc., they are left to specification in policies, which should be human readable to facilitate analysis and discussion, and machine readable to enable automated enforcement, using a language amenable to both, e.g., XACML.¶
The intent of the negative and positive access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Mitigation of Denial of Service attacks and refusal to allow database mass scraping would be based on those behaviors, not on identity or role of the party submitting the query per se, but querant identity information might be gathered (by security systems protecting DRIP implementations) on such misbehavior.¶
Registration under DRIP is vital as the worry of collisions in the hash portion of the DET. Forgery of the DET is still possible, but including it as a part of a public registration mitigates a lot of the risk. This document creates the DRIP DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., RAA, HDA, UA, GCS, USS). The registration process will use the Extensible Provisioning Protocol (EPP) and other protocols. The discovery process will leverage DNS and DNSSEC and related technology. The DETs can be registered with as their "raw public keys" or in X.509 certificates.¶
In DRIP each entity (registry, operator and aircraft) is expected to generate a full DRIP Entity ID [drip-rid] on the local device their key is expected to be used. These are registered with a Public Information Registry within the hierarchy along with whatever data is required by the cognizant CAA and the registry. Any PII is stored in a Private Information Registry protected through industry practice AAA or better. In response, the entity will obtain an attestation or certificate from the registry proving such registration.¶
Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID type for their aircraft but also generate a DET then encode it as a Serial Number. This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) could still use DRIP and most of its benefits. Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a registry to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for an aircraft profile to be displayed.¶
Operators are registered with a number of registries or their regional RAA. This acts as a verification check when a user performs other registration operations; such as provisioning an aircraft with a new Session ID. It is an open question if an Operator registers to their CAA (the RAA) or multiple USS's (HDA's). PII of the Operator would vary based on the CAA they are under and the registry.¶
Finally aircraft that support using a DET would provision per flight to a USS, proposing a DET to the registry to generate a binding between the aircraft (Session ID, Serial Number and Operational Intent), operator and registry. Aircraft then follow [drip-auth] to meet various [drip-requirements] during flight.¶
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.¶
See [drip-requirements] for common DRIP terms.¶
Under DRIP there 3 classes of registries, with specific variants in each.¶
+----------+
| Root |
+-o------o-+
| |
******************|******|*****************************
| |
+-----o-+ +-o-----+
RAAs | IRM | | RAA o------.
+---o---+ +---o---+ '
| | |
****************|**********|**********|****************
| | |
+---o---+ +---o---+ +---o---+
HDAs | MRA | | RIDR | | HDA |
+-------+ +-------+ +-------+
This is a special registry holding the RAA value of 0 and HDA value of 0. It delegates out RAA values only to registries that wish to act as an RAA.¶
RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field (16,384 RAAs) of a DET). An RAA is a business or organization that manages a registry of HDAs (Section 3.1.3). Most are contemplated to be Civil Aviation Authorities (CAA), such as the Federal Aviation Authority (FAA), that then delegate HDAs to manage their NAS. This is does not preclude other entities to operate an RAA if the Root server allows it.¶
The ICAO registration process will be available from ICAO. Once ICAO accepts an RAA, it will assign a number and create a zone delegation under the uas.icao.int. DNS zone for the RAA.¶
As HHITs may be used in many different domains, RAA should be allocated in blocks with consideration on the likely size of a particular usage. Alternatively, different prefixes can be used to separate different domains of use of HHITs.¶
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 use an HDA value of 0 and have their RAA value delegated to them by the Root.¶
A special RAA that hands out HDA values to participating Manufacturer's that hold an ICAO Manufacturer Code used in ANSI CTA2063-A Serial Numbers.¶
It is holds the RAA value of 1 and HDA value of 0.¶
An HDA may be an ISP or any third party that takes on the business to provide RVS and other needed services such as those required for HIP-enabled devices.¶
The HDA is an 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.¶
A registry (HDA) run by a manufacturer of UAS systems that participate in Remote ID. Stores UAS Serial Numbers under a specific ICAO Manufacturer Code (assigned to the manufacturer by ICAO).¶
A DET can be encoded into a Serial Number (see [drip-rid]) and this registry would hold a mapping from the Serial Number to the DET and its artifacts.¶
Hold RAA value of 1 and HDA values of 1+.¶
Registry that holds 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 they also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent.¶
Hold RAA values of 2+ and HDA values of 1+.¶
During key rollover the entity MUST inform all children and parents of the change - using best standard practices of a key rollover. At time of writing this is signing over the new key with the previous key in a secure fashion and it being validated by others before changing any links (in DRIPs case the NS RRs in the parent registry).¶
A DET has a natural ability for a single entity 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 of the DET to have different identities could also allow for a single registry to be "federated" across them if they share the same HID value. This method of deployment has not been thoroughly studied at this time.¶
Under DRIP there are a number of FQDN forms used to allow lookups to take place.¶
The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response. A secure connection (e.g., DNS over TLS) to the authoritative zone may be a viable alternative to DNSSEC.¶
Serial Number: 8653FZ2T7B8RA85D19LX ICAO Mfr Code: 8653 Length Code: F ID: FZ2T7B8RA85D19LX FQDN: Z2T7B8RA85D19LX.F.8653.mfr.uas.icao.int¶
The DET reverse lookup can be a standard IPv6 reverse look up, or it can leverage off the HHIT structure. If we assume a prefix of 2001:30::/28:¶
DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e ID: a3ad:1952:0ad0:a69e OGA: 5 HDA: 0014 = 20 RAA: 000a = 10 Prefix: 20010030 FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int¶
When building a DET FQDN the following two things must be done:¶
The prefix is included in the FQDN form to support other potential prefixes being used.¶
$ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR¶
DRIP requires a number of resource records, some specific to certain registries to function.¶
All registries will have their own DET associated with them and their respective DNS server will hold a HIP RR that is pointed to by their DET FQDN.¶
MRA and RIDR servers will also have HIP RRs for their registered parties (aircraft and operators).¶
Most attestations can be placed into DNS. An exception to this is the Attestation Certificate made during Session ID registration. This is as this particular certificate acts similar to a car registration and should be held safe by the operator.¶
Along with their associated "glue" record (A/AAAA) supports the traversal in DNS across the tree.¶
<mfr.remoteid.aero> on Root points to specific DET FQDN of IRM¶
<icao_mfr_code>.mfr.remoteid.aero on IRM points to specific DET FQDN of MRA¶
<raa_value>.det.remoteid.aero on Root pointing to DET FQDN of matching RAA¶
<hda_value>.<raa_value>.det.remoteid.aero on RAA pointing to DET FQDN of matching HDA¶
The SVR RR for DRIP always is populated at the "local" registry level. That is an HDA's DNS would hold the SVR RR that points to that HDAs private registry for all data it manages. This data includes data being stored on its children.¶
The best example of this is RIDR would have a SVR RR that points to a database that contains any extra information of a Session ID it has registered. Another example is the MRA has a SVR RR pointing to where the metadata of a UA registered in the MRA can be located.¶
In all cases the server being pointed to MUST be protected using AAA, specifically using RDAP.¶
As a general rule the following processing performed for any registration operation:¶
DRIP defines two levels of hierarchy maintained by the Registration Assigning Authority (RAA) and HHIT Domain Authority (HDA). The authors anticipate that an RAA is owned and operated by a regional CAA (or a delegated party by an CAA in a specific airspace region) with HDAs being contracted out. As such a chain of trust for registries is required to ensure trustworthiness is not compromised. More information on the registries can be found in [hhit-registries].¶
Both the parent and child generate their own keypairs and self-signed attestations if not generated previously. The child sends to the parent its self-signed attestation to be added into the parent DNS.¶
The parent confirms the attestation received is valid and that no DET collisions occur before adding a NS RR (and CERT RRs) to its DNS for the new child. An attestation, parent on child, is sent as a confirmation that provisioning was successful.¶
The child is now a valid member of the registry tree and uses its keypair and Self-Attestation with all provisioning requests towards it. The HIP RR for the child is populated into the local DNS along with any CERT RRs.¶
Specifically handled by the Root (Section 3.1.1).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| IP Address of RAA | Root: <raa_value>.det.remoteid.aero NS <raa_det_fqdn>
|
Attestation: Root, RAA |
| RAA Self-Attestation | Root: <raa_det_fqdn> AAAA <raa_ip>
|
(Concise Attestation: Root, RAA) |
RAA: <raa_det_fqdn> HIP <hip_rr_data>
|
(Broadcast Attestation: Root, RAA) | |
RAA: <raa_det_fqdn> CERT <raa_self_attestation>
|
||
(Root: <raa_det_fqdn> CERT <attestation_root_raa>) |
||
(Root: <raa_det_fqdn> CERT <concise_attestation_root_raa>) |
||
(Root: <raa_det_fqdn> CERT <broadcast_attestation_root_raa>) |
||
(RAA: <raa_det_fqdn> CERT <attestation_root_raa>) |
||
(RAA: <raa_det_fqdn> CERT <concise_attestation_root_raa>) |
||
(RAA: <raa_det_fqdn> CERT <broadcast_attestation_root_raa>) |
Specifically handled by the Root (Section 3.1.1).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| IP Address of IRM | Root: mfr.remoteid.aero NS <irm_det_fqdn>
|
Attestation: Root, IRM |
| IRM Self-Attestation | Root: 1.det.remoteid.aero NS <irm_det_fqdn>
|
(Concise Attestation: Root, IRM) |
Root: <irm_det_fqdn> AAAA <irm_ip>
|
(Broadcast Attestation: Root, IRM) | |
IRM: <irm_det_fqdn> HIP <hip_rr_data>
|
||
IRM: <irm_det_fqdn> CERT <irm_self_attestation>
|
||
(Root: <irm_det_fqdn> CERT <attestation_root_irm>) |
||
(Root: <irm_det_fqdn> CERT <concise_attestation_root_irm>) |
||
(Root: <irm_det_fqdn> CERT <broadcast_attestation_root_irm>) |
||
(IRM: <irm_det_fqdn> CERT <attestation_root_irm>) |
||
(IRM: <irm_det_fqdn> CERT <concise_attestation_root_irm>) |
||
(IRM: <irm_det_fqdn> CERT <broadcast_attestation_root_irm>) |
Specifically handled by an RAA (Section 3.1.2).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| IP Address of HDA | RAA: <hda_value>.<raa_value>.det.remoteid.aero NS <hda_det_fqdn>
|
Attestation: RAA, HDA |
| HDA Self-Attestation | RAA: <hda_det_fqdn> AAAA <hda_ip>
|
(Concise Attestation: RAA, HDA) |
RAA: <hda_det_fqdn> HIP <hip_rr_data>
|
(Broadcast Attestation: RAA, HDA) | |
HDA: <hda_det_fqdn> CERT <hda_self_attestation>
|
||
(RAA: <hda_det_fqdn> CERT <attestation_raa_hda>) |
||
(RAA: <hda_det_fqdn> CERT <concise_attestation_raa_hda>) |
||
(RAA: <hda_det_fqdn> CERT <broadcast_attestation_raa_hda>) |
||
(HDA: <hda_det_fqdn> CERT <attestation_raa_hda>) |
||
(HDA: <hda_det_fqdn> CERT <concise_attestation_raa_hda>) |
||
(HDA: <hda_det_fqdn> CERT <broadcast_attestation_raa_hda>) |
Specifically handled by the IRM (Section 3.1.2.1).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| IP Address of MRA | IRM: <icao_mfr_code>.mfr.remoteid.aero NS <mra_det_fqdn>
|
Attestation: IRM, MRA |
| MRA Self-Attestation | IRM: <hda_value>.1.det.remoteid.aero NS <mra_det_fqdn>
|
(Concise Attestation: IRM, MRA) |
| ICAO Manufacturer Code | IRM: <mra_det_fqdn> AAAA <mra_ip>
|
(Broadcast Attestation: IRM, MRA) |
MRA: <mra_det_fqdn> HIP <hip_rr_data>
|
||
MRA: <mra_det_fqdn> CERT <mra_self_attestation>
|
||
(IRM: <mra_det_fqdn> CERT <attestation_irm_mra>) |
||
(IRM: <mra_det_fqdn> CERT <concise_attestation_irm_mra>) |
||
(IRM: <mra_det_fqdn> CERT <broadcast_attestation_irm_mra>) |
||
(MRA: <mra_det_fqdn> CERT <attestation_irm_mra>) |
||
(MRA: <mra_det_fqdn> CERT <concise_attestation_irm_mra>) |
||
(MRA: <mra_det_fqdn> CERT <broadcast_attestation_irm_mra>) |
Specifically handled by an MRA (Section 3.1.3.1).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| Serial Number | (<sn_det_fqdn> HIP <hip_rr_data>) |
(Attestation: MRA, UA) |
| (UA Self-Attestation) | (<sn_det_fqdn> CERT <sn_self_attestation>) |
(Broadcast Attestation: MRA, UA |
| UA Metadata | (<sn_det_fqdn> CERT <attestation_mra_sn>) |
(Concise Attestation: MRA, UA) |
(<sn_det_fqdn> CERT <concise_attestation_mra_sn>) |
||
(<sn_det_fqdn> CERT <broadcast_attestation_mra_sn>) |
+--------------+ SA-a0a0 +-----------------+
| Manufacturer | <--------> | Manufacturer CA |
+--------------+ A-ma0 +-----------------+
^ |
| |
| |
SA-a0a0 | | A-ma0
| |
| v
+----------+
| Aircraft |
+----------+
During the initial configuration and production at the factory the Aircraft MUST be configured to have a serial number. ASTM defines this to be an ANSI/CTA-2063A Serial Number for UAS. Under DRIP a DET can be encoded as such to be able to convert back and forth between them. This is covered in [drip-rid].¶
Under DRIP the Manufacturer SHOULD be using DETs and have their own keypair and Self-Attestation: Manufacturer (SA-m). (Ed. Note: some words on aircraft keypair and certs here?).¶
Self-Attestation: Aircraft 0 on Aircraft 0 (SA-a0a0) is extracted by the manufacturer and sent to their Certificate Authority (CA) to be verified and added. A resulting attestation (Attestation: Manufacturer on Aircraft 0 [A-ma0]) SHOULD be a DRIP Attestation - however this could be a X.509 certificate binding the serial number to the manufacturer.¶
Specifically handled by a RIDR (Section 3.1.3.2).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| Operator Self-Attestation |
<op_det_fqdn> HIP <hip_rr_data>
|
Attestation: RIDR, Operator |
| Operator PII | (<op_det_fqdn> CERT <op_self_attestation>) |
Broadcast Attestation: RIDR, Operator |
(<op_det_fqdn> CERT <attestation_ridr_op>) |
(Concise Attestation: RIDR, Operator) | |
(<op_det_fqdn> CERT <concise_attestation_ridr_op>) |
||
(<op_det_fqdn> CERT <broadcast_attestation_ridr_op>) |
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ [HIP RR] +---------+
^ |
| |
| |
Coo | | Aro
| |
| v
+----------+
| Operator |
+----------+
The Operator generates a keypair and DET as specified in DRIP UAS RID. A self-signed attestation (Self-Attestation: Operator on Operator [SA-oo]) is generated and sent to the desired registry (HDA). Other relevant information and possibly personally identifiable information needed may also be required to be sent to the registry (all over a secure channel - the method of which is out of scope for this document).¶
The registry cross checks any personally identifiable information as required. Certificate: Operator on Operator is verified (both using the expiration timestamp and signature). The DET is searched in the Registries database to confirm that no collision occurs. A new attestation is generated (Attestation: Registry on Operator) and sent securely back to the Operator. Optionally the DET/HI pairing can be added to the Registries DNS in to form of a HIP Resource Record (RR). Other RRs, such as CERT and TXT, may also be used to hold public information.¶
With the receipt of Attestation: Registry on Operator (A-ro) the provisioning of an Operator is complete.¶
Specifically handled by a RIDR (Section 3.1.3.2).¶
| Inputs (Optional) | DNS Entries (Optional) | Outputs (Optional) |
|---|---|---|
| Attestation: RIDR, Operator |
<session_det_fqdn> HIP <hip_rr_data>
|
Attestation: RIDR, Operator |
| Attestation: Operator, UA |
<session_det_fqdn> CERT <session_self_attestation>
|
Broadcast Attestation: RIDR, Operator |
| Serial Number |
<session_det_fqdn> CERT <broadcast_attestation_ridr_session>
|
Attestation Certificate: RIDR, Operator, UA |
| (Concise Attestation: Operator, UA) | (<session_det_fqdn> CERT <attestation_ridr_session>) |
(Concise Attestation: RIDR, Operator) |
| (Mutual Attestation: Operator, UA) | (<session_det_fqdn> CERT <concise_attestation_ridr_session>) |
(Mutual Certificate: RIDR, Operator, UA) |
| (Link Attestation: Operator, UA) | (Concise Certificate: RIDR, Operator, UA) | |
| (Operational Intent) | (Link Certificate: RIDR, Operator, UA) | |
| (Broadcast Attestation: RAA, RIDR) | ||
| (Broadcast Attestation: Root, RAA) |
Under standard provisioning the Aircraft has its own connectivity to the registry, the method which is out of scope for this document.¶
+----------+
| Registry |
+----------+
^
|
|
| A-ro, A-oaN
|
|
+----------+ +----------+
| Operator | <--------------------- | Aircraft |
+----------+ A-a0aN +----------+
Through mechanisms not specified in this document the Operator should have methods to instruct the Aircraft onboard systems to generate a keypair and certificate. This certificate is chained to the factory provisioned certificate (Self-Attestation: Aircraft 0 on Aircraft 0 [SA-a0a0]). This new attestation (Attestation: Aircraft 0 on Aircraft N [A-a0aN]) is securely extracted by the Operator.¶
With A-a0aN the sub-attestation (Self-Attestation: Aircraft N on Aircraft N [SA-aNaN]) is used by the Operator to generate Attestation: Operator on Aircraft N (A-oaN). This along with Attestation: Registry on Operator (A-ro) is sent to the registry.¶
+----------+
| Registry |
+----------+
|
|
|
| Token
|
v
+----------+ +----------+
| Operator | ---------------------> | Aircraft |
+----------+ Token +----------+
On the registry, A-ro is verified and used as confirmation that the Operator is already registered. A-oaN also undergoes a validation check and used to generate a token to return to the Operator to continue provisioning.¶
Upon receipt of this token, the Operator injects it into the Aircraft and its used to form a secure connection to the registry. The Aircraft then sends Attestation: Manufacturer on Aircraft 0 (A-ma0) and Attestation: Aircraft 0 to Aircraft N (A-a0aN).¶
+---------+
| HDA DNS |
+---------+
^
|
| HIP RR
|
|
|
+----------+ <----------------------------+
| Registry | |
+----------+ ------------------------+ |
| | |
| | | Token,
| AC-roaN BA-raN | | A-ma0, A-a0aN
| | |
| | |
v v |
+----------+ +----------+
| Operator | | Aircraft |
+----------+ +----------+
The registry uses Attestation: Manufacturer on Aircraft 0 (with an external database if supported) to confirm the validity of the Aircraft. Attestation: Aircraft 0 on Aircraft N is correlated with Attestation: Operator on Aircraft N and Attestation: Manufacturer on Aircraft 0 to see the chain of ownership. The new DET tied to Aircraft N is then checked for collisions in the HDA. With the information the registry generates two items: Attestation Certificate: Registry on Operator on Aircraft N (AC-roaN) and Broadcast Attestation: Registry on Aircraft N (BA-raN). A HIP RR (and other RR types as needed) are generated and inserted into the HDA.¶
AC-roaN is sent via a secure channel back to the Operator to be stored. BA-raN is sent to the Aircraft to be used in Broadcast RID as specified in [drip-auth].¶
This provisioning scheme is for when the Aircraft is unable to connect to the registry itself or does not have the hardware required to generate keypairs and attestations.¶
+----------+ | Registry | +----------+ +----------+ +----------+ | Operator | ---------------------> | Aircraft | +----------+ aN, SA-aNaN +----------+
To start the Operator generates on behalf of the Aircraft a new keypair and Attestation: Aircraft N on Aircraft N (SA-aNaN). This keypair and certificate are injected into the Aircraft for it to generate Attestation: Aircraft 0 on Aircraft N (A-a0aN). After injecting the keypair and certificate, the Operator MUST destroy all copies of the keypair.¶
+----------+
| Registry |
+----------+
^
|
|
| A-ro, A-ma0, A-a0aN, A-oaN
|
|
+----------+ +----------+
| Operator | <--------------------- | Aircraft |
+----------+ A-ma0, A-a0aN +----------+
Attestation: Manufacturer on Aircraft 0 (A-ma0) and Attestation: Aircraft 0 on Aircraft N (A-a0aN) is extracted by the Operator and the following data items are sent to the Registry; Attestation: Registry on Operator (A-ro), Attestation: Manufacturer on Aircraft 0 (A-ma0), Attestation: Aircraft 0 on Aircraft N (A-a0aN), Attestation: Operator on Aircraft N (A-oaN).¶
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ HIP RR +---------+
|
|
|
| AC-roaN, BA-raN
|
v
+----------+ +----------+
| Operator | ---------------------> | Aircraft |
+----------+ BA-raN +----------+
On the registry validation checks are done on all attestations as per the previous sections. Once complete then the registry checks for a DET collision, adding to the HDA if clear and generates Attestation Certificate: Registry on Operator on Aircraft N (AC-roaN) and Broadcast Attestation: Registry on Aircraft N (BA-raN). Both are sent back to the Operator.¶
The Operator securely inject BA-raN and securely stores AC-roaN of Aircraft N.¶
A special form of provisioning is used when the Aircraft is first sold to an Operator. Instead of generating a new keypair, the built in keypair and certificate done by the Manufacturer is used to provision and register the aircraft to the owner.¶
For this either Standard or Operator Assisted methods can be used.¶
There are a number of common attributes between the various EPP commands under DRIP that has specific encoding rules.¶
Transfer semantics do not apply in DRIP, so there is no mapping defined for the EPP <transfer> command.¶
The abbreviation field has a max of 6 characters, and is used by RID receivers to display a short decoded form for display of a received DET in the form of {RAA Abbreviation} {HDA Abbreviation} {Last 4 of DET Hash}. An example of this would be US FAA FE23. If the abbreviation is unknown then the receiver SHOULD use the hexadecimal encoding of the respective RAA/HDA field of the HID as the value in the form. For example if the HDA is unknown and the HDA value is 20 then the decoded display would be: DE 14 FE23. Typically for RAAs the abbreviation is RECOMMENDED to be set to the ISO 3166 country code (either Alpha-2 or Alpha-3) for the CAA. Dashes or underscores should be used in place of spaces.¶
The mfrCode field is only used by an MRA (Section 3.1.3.1) when registering with an IRM (Section 3.1.2.1) and holds the ICAO assigned Manufacturer Code for ANSI CTA2063-A Serial Numbers. It has a max of 4 characters.¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extension>
<dripRegistry:dripRegistry xmlns:dripRegistry="urn:ietf:params:xml:ns:dripRegistry-1.0">
<dripRegistry:det>2001:0030:00a0:0145:a3ad:1952:0ad0:a69e</dripRegistry:det>
<dripRegistry:hi></dripRegistry:hi>
<dripRegistry:selfAttestation>Hex of SelfAttestation(Registry)</dripRegistry:selfAttestation>
<dripRegistry:raa>10</dripRegistry:raa>
<dripRegistry:hda>20</dripRegistry:hda>
<dripRegistry:abbreviation>FAA</dripRegistry:abbreviation>
<dripRegistry:mfrCode>MFR0</dripRegistry:mfrCode>
<dripRegistry:postalInfo type="int">
<dripRegistry:name>Federal Aviation Administration</dripRegistry:name>
<dripRegistry:phys_addr>
<dripRegistry:street1>Orville Wright Federal Building</dripRegistry:street1>
<dripRegistry:street2>800 Independence Avenue SW</dripRegistry:street2>
<dripRegistry:city>Washington</dripRegistry:city>
<dripRegistry:sp>DC</dripRegistry:sp>
<dripRegistry:pc>20591</dripRegistry:pc>
<dripRegistry:cc>US</dripRegistry:cc>
</dripRegistry:phys_addr>
</dripRegistry:postalInfo>
<dripRegistry:voice x="1234">1 (866) 835-5322</dripRegistry:voice>
<dripRegistry:email>stephen.dickson@faa.gov</dripRegistry:email>
</dripRegistry:dripRegistry>
</extension>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extension>
<dripOperator:dripOperator xmlns:dripOperator="urn:ietf:params:xml:ns:dripOperator-1.0">
<dripOperator:postalInfo type="int">
<dripOperator:phys_addr>
<dripOperator:street1>123 Example Dr.</dripOperator:street1>
<dripOperator:street2>Suite 100</dripOperator:street2>
<dripOperator:city>Dulles</dripOperator:city>
<dripOperator:sp>VA</dripOperator:sp>
<dripOperator:pc>20166-6503</dripOperator:pc>
<dripOperator:cc>US</dripOperator:cc>
</dripOperator:phys_addr>
</dripOperator:postalInfo>
<dripOperator:part107_acct_name>some_faa_account</dripOperator:part107_acct_name>
<dripOperator:rec_flyer_id>123456</dripOperator:rec_flyer_id>
<dripOperator:caaId></dripOperator:caaId>
<dripOperator:det></dripOperator:det>
<dripOperator:hi></dripOperator:hi>
<dripOperator:selfAttestation>Hex of SelfAttestation(Operator)</dripOperator:selfAttestation>
<dripOperator:attestation>Hex of Attestation(Registry, Operator)</dripOperator:attestation>
</dripOperator::dripOperator>
</extension>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extension>
<dripSerial:dripSerial xmlns:dripSerial="urn:ietf:params:xml:ns:dripSerial-1.0">
<dripSerial:serial>0000F000000000000000</dripSerial:serial>
<dripSerial:det></dripSerial:det>
<dripSerial:hi></dripSerial:hi>
<dripSerial:selfAttestation>Hex of SelfAttestation(Aircraft)</dripSerial:selfAttestation>
<dripSerial:broadcastAttestation>Hex of BroadcastAttestation(Registry, Aircraft)</dripSerial:broadcastAttestation>
<dripSerial:manufacturer>Drones R Us</dripSerial:manufacturer>
<dripSerial:make>Fast Drone</dripSerial:make>
<dripSerial:model>9000</dripSerial:model>
<dripSerial:color>White</dripSerial:color>
<dripSerial:material>Plastic</dripSerial:material>
<dripSerial:weight>12.0</dripSerial:weight>
<dripSerial:length>5.0</dripSerial:length>
<dripSerial:width>4.0</dripSerial:width>
<dripSerial:height>3.0</dripSerial:height>
<dripSerial:numRotors>4</dripSerial:numRotors>
<dripSerial:propLength>2.0</dripSerial:propLength>
<dripSerial:batteryCapacity>5000</dripSerial:batterCapacity>
<dripSerial:batteryVoltage>12</dripSerial:batteryVoltage>
<dripSerial:batteryWeight>5.2</dripSerial:batteryWeight>
<dripSerial:batteryChemistry>Lithium-Ion</dripSerial:batteryChemistry>
<dripSerial:takeOffWeight>15</dripSerial:takeOffWeight>
<dripSerial:maxTakeOffWeight>25</dripSerial:maxTakeOffWeight>
<dripSerial:maxPayloadWeight>10</dripSerial:maxPayloadWeight>
<dripSerial:maxFlightTime>15</dripSerial:maxFlightTime>
<dripSerial:minOperatingTemp>35</dripSerial:minOperatingTemp>
<dripSerial:maxOperatingTemp>90</dripSerial:maxOperatingTemp>
<dripSerial:ipRating>55</dripSerial:ipRating>
</dripSerial:dripSerial>
</extension>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extension>
<dripSession:dripSession xmlns:dripSession="urn:ietf:params:xml:ns:dripSession-1.0">
<dripSession:serial>0000F000000000000000</dripSession:serial>
<dripSession:uasId></dripSession:uasId>
<dripSession:sessionHi></dripSession:sessionHi>
<dripSession:broadcastAttestation>Hex of BroadcastAttestation(Registry, Aircraft)</dripSession:broadcastAttestation>
<dripSession:attestationCertificate>Hex of AttestationCertificate(Registry, Operator, Aircraft)</dripSession:attestationCertificate>
<dripSession:operationalIntent></dripSession:operationalIntent>
<dripSession:operationalIntentSrc>uss.example.com</dripSession:operationalIntentSrc>
<dripSession:operatorId>NOP123456</dripSession:operatorId>
<dripSession:operatorDet></dripSession:operatorDet>
<dripSession:attestation>Hex of Attestation(Operator, Aircraft)</dripSession:attestation>
<dripSession:mutualAttestation>Hex of MutualAttestation(Registry, Operator)</dripSession:mutualAttestation>
<dripSession:fa3>N1232456</dripSession:fa3>
<dripSession:sessionStart>2022-04-09T15:43:13Z</dripSession:sessionStart>
<dripSession:sessionEnd>2022-04-09T20:43:13Z</dripSession:sessionEnd>
</dripSession:dripSession>
</extension>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<dripRegistry:delete xmlns:dripRegistry="urn:ietf:params:xml:ns:dripRegistry-1.0">
<dripRegistry:det>2001:0030:00a0:0145:a3ad:1952:0ad0:a69e</dripRegistry:det>
</dripRegistry:delete>
</delete>
<clTRID>DEL-REGIS</clTRID>
</command>
</epp>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<dripOperator:delete xmlns:dripOperator="urn:ietf:params:xml:ns:dripOperator-1.0">
<dripOperator:caaId></dripOperator:caaId>
<dripOperator:det></dripOperator:det>
</dripOperator:delete>
</delete>
<clTRID>DEL-OPER</clTRID>
</command>
</epp>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<dripSerial:delete xmlns:dripSerial="urn:ietf:params:xml:ns:dripSerial-1.0">
<dripSerial:serial>0000F000000000000000</dripSerial:serial>
</dripSerial:delete>
</delete>
<clTRID>DEL-AIRCRFT</clTRID>
</command>
</epp>
¶
Example:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<dripSession:delete xmlns:dripSession="urn:ietf:params:xml:ns:dripSession-1.0">
<dripSession:uasId></dripSession:uasId>
</dripSession:delete>
</delete>
<clTRID>DEL-SID</clTRID>
</command>
</epp>
¶
Renewal semantics do not apply in DRIP, so there is no mapping defined for the EPP <renew> command.¶
Transfer semantics do not apply in DRIP, so there is no mapping defined for the EPP <transfer> command.¶
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.¶
Keypairs are expected to be generated on the device hardware it will be used on. Due to hardware limitations (see Section 10) and connectivity it is acceptable under DRIP to generate keypairs for the Aircraft on Operator devices and later securely inject them into the Aircraft (as defined in Section 6.4.2). The methods to securely inject and store keypair information in a "secure element" of the Aircraft is out of scope of this document.¶
In either case the registry must decide on if the HI/DET pairing is valid. This in its simplest form is checking the current registry for a collision on the DET and HI.¶
Upon accepting a HI/DET pair the registry MUST populate the required the DNS serving the HDA with the HIP RR and other relevant RR types (such as TXT and CERT). The registry MUST also generate the appropriate attestations/certificates for the given operation.¶
If the registry denied the HI/DET pair, because there was a DET collision or any other reason, the registry MUST signal back to the device being provisioned that a new HI needs to be generated.¶
See [drip-arch] for definitions of claim, assertion, attestation and certificate as used in this document.¶
All Attestations (Appendix A.2) and Certificates (Appendix A.3) under DRIP share the following format structure:¶
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
+---------------+---------------+---------------+---------------+
| |
. .
. Attestor Identity Information .
. .
| |
+---------------+---------------+---------------+---------------+
| |
. .
. Attestation Data .
. .
| |
+---------------+---------------+---------------+---------------+
| Expiration Timestamp by Attestor |
+---------------+---------------+---------------+---------------+
| Signing Timestamp by Attestor |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by Attestor |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Attestor Identity Information: (0, 16-bytes or 120-bytes)
Field containing Attestor Identity Information in various forms.
Attestation Data:
A field of variable length containing the attestation data.
Expiration Timestamp by Attestor (4 bytes):
Timestamp denoting recommended time to trust data to.
Signing Timestamp by Attestor (4 bytes):
Current time at signing.
Attestor Signature (64 bytes):
Signature over preceding fields using the keypair of
the Attestor.
This can be either of the following:¶
A specific definition of an Attestation (Appendix A.2) or Certificate (Appendix A.3) defines which of these are used.¶
The data being attested to. It can be one of the following forms:¶
This field is variable length with no limit and specific definitions of an Attestation (Appendix A.2) or Certificate (Appendix A.3) indicate the fields, size and ordering of any subfields.¶
A UTC timestamp set some time into the future to indicate a point the Attestation Structure should not be trusted.¶
The time delta into the future is of important concern as replay attacks on during flight could compromise the goals of DRIP. Attestations and certificates intended for public use and lower in the tree (importantly any generated for a Session ID (Section 6.4)).¶
For this reason deltas SHOULD be kept as short as possible for the given use-case to avoid issues with replays.¶
A UTC timestamp set to the time when the Attestation Structure was signed.¶
The only attestation to use a claim (the Host Identity) in the Attestation Data with the DET acting as the Attestor Identity Information.¶
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag | | | +---------------+---------------+---------------+---------------+ | | | | | | | Host Identity | | | | | | | | | +---------------+---------------+---------------+---------------+ | Trust Timestamp | +---------------+---------------+---------------+---------------+ | Signing Timestamp | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 120-bytes
The standard first level DRIP Attestation form using a Self-Attestations of the signer and of the data being signed.¶
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 +---------------+---------------+---------------+---------------+ | | . . . SA-xx . . . | | +---------------+---------------+---------------+---------------+ | | . . . SA-yy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by X | +---------------+---------------+---------------+---------------+ | Signing Timestamp by X | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by X | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 312-bytes
In constrained environments and when there is the guarantee of being able to lookup the DETs to obtain HIs this attestation can be used.¶
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of X | | | +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Y | | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by X | +---------------+---------------+---------------+---------------+ | Signing Timestamp by X | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by X | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 104-bytes
An attestation that perform a sign over an existing Attestation where the signer is the second party of the embedded attestation. The DET of party Y is used as the Attestor Identity Information (Appendix A.1.1).¶
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Y | | | +---------------+---------------+---------------+---------------+ | | . . . A-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Y | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Y | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Y | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 400-bytes
An attestations that perform a sign over an existing Concise Attestation where the signer is the second party of the embedded attestation. The DET of party Y is used as the Attestor Identity Information (Appendix A.1.1).¶
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Y | | | +---------------+---------------+---------------+---------------+ | | . . . CA-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Y | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Y | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Y | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 192-bytes
Required by DRIP Authentication Formats for Broadcast RID ([drip-auth]) to satisfy [drip-requirements] GEN-1 and GEN-3.¶
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of X | | | +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Y | | | +---------------+---------------+---------------+---------------+ | | | | | | | Host Identity of Y | | | | | | | | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by X | +---------------+---------------+---------------+---------------+ | Signing Timestamp by X | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by X | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 136-bytes
In DRIP certificates are signed by a third party that has no stake in the claims/assertions/attestations being attested to.¶
It is analogous to a third party in legal system that signs a document as a "witness" and bears no responsibility in the document.¶
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 +---------------+---------------+---------------+---------------+ | | . . . SA-zz . . . | | +---------------+---------------+---------------+---------------+ | | . . . A-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Z | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Z | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Z | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 504-bytes
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Z | | | +---------------+---------------+---------------+---------------+ | | . . . CA-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Z | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Z | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Z | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 192-bytes
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 +---------------+---------------+---------------+---------------+ | | | DRIP | | Entity Tag of Z | | | +---------------+---------------+---------------+---------------+ | | . . . LA-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Z | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Z | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Z | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 300-bytes
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 +---------------+---------------+---------------+---------------+ | | . . . SA-zz . . . | | +---------------+---------------+---------------+---------------+ | | . . . MA-xy . . . | | +---------------+---------------+---------------+---------------+ | Trust Timestamp by Z | +---------------+---------------+---------------+---------------+ | Signing Timestamp by Z | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature by Z | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Length = 576-bytes
The names of attestation and certificates can become quite long and tedious to write out. As such this section provides a guide to a somewhat standardized way they are written in text.¶
In a long form the name of a particular attestation/certification can be written as follows:¶
Self-Attestation: Unmanned Aircraft¶
Attestation: Operator on Aircraft or Attestation: Operator, Aircraft¶
Attestation Certificate: Registry on Operator on Aircraft or Attestation Certificate: Registry, Operator, Aircraft¶
When multiple entities are listed they can be separated by either on or by ,. These long forms can be shortened:¶
SA(Unmanned Aircraft) or SA-ua¶
A(Operator, Unmanned Aircraft) or A-op.ua¶
AC(Registry, Operator, Aircraft) or AC-reg.op.ua¶
Typical abbreviations for the entity can be used such as Unmanned Aircraft being shorthanded to ua.¶
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 covered in this document will also have certificates to create and manage the necessary PKI structure.¶
Any Certificate Authority (CA) supporting DRIP entities SHOULD adhere to the ICAO's International Aviation Trust Framework (IATF) Certificate Policy [ICAO-IATF-CP-draft]. The CA(s) supporting this CP MUST either be a part of the IATF Bridge PKI or part of the IATF CA Trust List.¶
EEs may use their X.509 certificates, rather than their rawPublicKey (i.e. HI) in authentication protocols (as not all may support rawPublicKey identities). Some EE HI may not be 'worth' supporting the overhead of X.509. 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 notAfterDate will 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.¶
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. This not only generally improves certificate lookups, but also enables use of DANE [RFC6698] for the various servers in the UTM and particularly DRIP registry environment and DANCE [dane-clients] for EEs (e.g. [drip-secure-nrid-c2]). All DRIP certificates MUST be available via RDAP. LDAP/OCSP access for other UTM and ICAO uses SHOULD also be provided.¶
(mostly TBD still)¶
PKIX standard X.509 issuance practices should be used. The certificate request SHOULD be included in the DET registration request (Section 6). A successful DET registration then MUST include certificate creation, store, and return to the DET registrant.¶
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.¶
Details of this are left out, as there are a number of approaches and further research and experience will be needed.¶
(CBOR encoded certs here. TBD)¶
The implementation of the registries and Network Remote Identification (Network RID; identify a UA through the network) in DRIP is yet to be determined. Blockchain, being synonymous with ledger, is a technology that could naturally fulfil the role of a registry, while simultaneously offering its benefits such as auditability, persistency and decentralization. We suggest that blockchain is an ample candidate to be used as registry within DRIP. We also show that it can be used to effectively leverage Network RID in certain scenarios. Thus 1) We propose a novel drone ID architecture based on Hyperledger Iroha and describe its proof-of-concept implementation with DRIP. 2) Its performance and scalability is empirically evaluated. 3) We perform an informal security analysis of the system against various types of attacks [Secure Drone Identification with Hyperledger Iroha].¶
Figure 1: Architecture using blockchain as registry for DRIP¶
The proposed architecture is presented in Fig. 1. It consists of the usual actors in a UAS network, along with the blockchain registry based on Hyperledger Iroha. Key components: o Authorized users (administrators) can register new UAs to the network, and store with them any relevant data such as public keys and certificates.¶
Drones can either send location updates directly to the blockchain, given that they are connected to the Internet, or send location updates to their connected Ground Control Station (GCS) that forwards it on behalf of the drones. o Observers can receive drone messages either through bluetooth and WiFi broadcasts from drones, or by polling the blockchain. They can also fetch the public key associated with a drone in order to validate its messages. o The blockchain network and its nodes are an entirely separate entity, no other actor participates in the consensus of new blocks.¶
Actors within DRIP (except observers) will be registered as accounts on the blockchain network. Each of these accounts will have their DRIP identities, certificates and public keys stored and available so that they can be validated and used for validation by any account on the blockchain. Note that DRIP crypto key-pairs are separate from the blockchain crypto key-pairs. DRIP key-pairs are used to sign, verify and validate DRIP identities and messages, while the blockchain key-pairs are used to sign, verify and validate transactions on the blockchain.¶
The DRIP requirements for a registry are the following: (1) REG-1: Public lookup (2) REG-2: Private lookup (3) REG-3: Provisioning (of static/dynamic data of UAs) (4) REG-4: AAA Policy¶
REG-1 & REG-2. In Hyperledger Iroha, accounts are created on domains. The same account name can be used for multiple domains, and these are seen as separate accounts on Iroha. PII for an account can therefore be stored on a separate account (with the same account name) existing on a separate domain, that only allows certain accounts to view its account details. Accordingly, a registry using Iroha would need at least two domains associated with it for any given account, one for public lookup and one for private lookup.¶
REG-3 & REG-4. The details for an account are set with a key/value pair. Key/value pairs can not be removed once they are set, values can only be modified through the corresponding key. Furthermore, the account that sets a key/value pair is included in the account details as a key/value pair itself, meaning one account can not modify details set by another account. See Listing 1 for clarification. Notice that both accounts have set the same key but contain different values. This sort of implementation supports both non-repudiation, but also trust in the sense that a drone (assuming the drone is not compromised) can always trust its own data, and does not have to interpret data coming from other accounts. Similarly, other accounts accessing another account's data can trust that it is set by the corresponding account (e.g. fetching gps data).¶