Means of Compliance for DRIP Entity Tags as UAS RID Identifiers
draft-wiethuechter-drip-det-moc-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Adam Wiethuechter | ||
| Last updated | 2024-11-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wiethuechter-drip-det-moc-00
drip Working Group A. Wiethuechter
Internet-Draft AX Enterprize, LLC
Intended status: Standards Track 4 November 2024
Expires: 8 May 2025
Means of Compliance for DRIP Entity Tags as UAS RID Identifiers
draft-wiethuechter-drip-det-moc-00
Abstract
This document is intended for Civil Aviation Authorities (CAAs) as a
Means of Compliance (MOC) for using Drone Remote Identification
Protocol (DRIP) Entity Tags (DETs) for Unmanned Aircraft System (UAS)
Remote ID (RID) identifiers. This enables Session IDs,
Authentication Key IDs for accountability, and encryption key IDs for
confidentiality.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Wiethuechter Expires 8 May 2025 [Page 1]
Internet-Draft det-moc November 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Additional Definitions . . . . . . . . . . . . . . . . . 4
3. Interactions & Responsibilities . . . . . . . . . . . . . . . 5
3.1. UAS Observers . . . . . . . . . . . . . . . . . . . . . . 5
3.2. UAS Operators . . . . . . . . . . . . . . . . . . . . . . 5
3.3. UAS Manufacturers . . . . . . . . . . . . . . . . . . . . 6
3.4. HDA Operators . . . . . . . . . . . . . . . . . . . . . . 6
3.5. RAA Operators . . . . . . . . . . . . . . . . . . . . . . 7
4. DRIP Service Options . . . . . . . . . . . . . . . . . . . . 7
5. Requirements for DIME Operation . . . . . . . . . . . . . . . 7
5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Public Information Registries . . . . . . . . . . . . 7
5.1.2. Private Information Registries . . . . . . . . . . . 8
5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Cross Cutting . . . . . . . . . . . . . . . . . . . . . . 8
6. Compliance Testing . . . . . . . . . . . . . . . . . . . . . 9
6.1. Registration Interface . . . . . . . . . . . . . . . . . 10
6.2. Public Query Interface . . . . . . . . . . . . . . . . . 10
6.3. Private Query Interface . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. DETs as a Locator . . . . . . . . . . . . . . . . . . . . 11
9. Privacy & Transparency Considerations . . . . . . . . . . . . 11
9.1. DETs as Session ID and Authentication Key ID . . . . . . 11
9.2. Selective Encryption . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. HID Abbreviation . . . . . . . . . . . . . . . . . . 14
Appendix B. Compliance Submission Forms . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1.1. Purpose
This document is written to reference other documents, thus acting as
an introduction for Civil Aviation Authorities (CAAs) and their
Operators attempting to comply within a given jurisdiction. A CAA
MAY override any requirement in this document, but MUST provide the
reason and an alternative for their operators to implement. This
document offers technical options, with recommendations of defaults
Wiethuechter Expires 8 May 2025 [Page 2]
Internet-Draft det-moc November 2024
for international interoperability.
1.2. Background
A registry function including Hierarchical Host Identity Tag (HHIT)
Domain Authority (HDA) is required to support Session IDs that can be
used by CAAs and other lawfully authorized parties to look up
essential safety and security information associated with UAS and
their Operators.
In the Unmanned Aerial System (UAS) Traffic Management (UTM) context,
it is expected that the HDA function will be provided by each UAS
Service Supplier (USS). This can be in-house or out-sourced to a
service bureau more specialized in cryptographically verifiable
identifiers usable to access data and systems on networks. Outside
the UTM context, each Operator must still obtain this function from
some provider.
The HDA function also can support other services related to Session
IDs. The DRIP Entity Tag (DET) can act as a Session ID and/or
Authentication Key ID, thus HDA functionality in this document
assumes both are being provided to registrants (see Section 9.1 for
more details). The use of Authentication is mandated in some (e.g.
Japan) but not all regions.
Each DET is tied to a longer term identifier by its HDA. Typically
this identifier is expected to be the UAS Serial Number, however a
CAA MAY choose another long term identifier of significance to them.
1.3. Scope
Any entity involved in UAS Broadcast RID as per this document:
* if that entity uses a Session ID (some participating entities,
e.g. HDAs, may not have Session IDs), MUST use a DET for that
Session ID.
* if that entity participates in DRIP protocol interactions (even if
not needing a Session ID), MUST use a DET for the DRIP public key
ID.
* if that entity requires a strongly cryptographically verifiable IP
compatible identifier, MAY use a DET for any other legal purpose.
* SHOULD NOT use DET as a locator in physical or logical space (e.g.
as a globally routable IPv6 address outside of an overlay
network). See Section 8.1 for further details.
Wiethuechter Expires 8 May 2025 [Page 3]
Internet-Draft det-moc November 2024
The archetypal case is a UAS for which the DET serves as both the UAS
ID (e.g. in the ASTM [F3411] Basic ID Message as a Type 4, Subtype 1
Specific Session ID) and the Authentication Key ID.
DRIP builds upon existing UAS RID standards (ASTM [F3411]) and
baseline Means of Compliance (ASTM [F3586]). This document acts as a
further Means of Compliance for DETs to be used as Session IDs and/or
Authentication Key IDs. This document is intended to be
internationally applicable but at the time of first writing the
authors have only confirmed compatibility with ASTM [F3586] (and thus
US FAA rules).
2. 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.
2.1. Additional Definitions
This document makes use of terms (PII, USS, etc.) defined in
[RFC9153], [RFC9434] and [RFC9374]. For convenience of the reader,
some of the major definitions are restated here.
TODO: find good accurate definitions of these terms & order them
UAS RID identifier: a term used in this document to encompass the
use of a DET to be used as any combination of the following: UAS
Specific Session ID, Authentication Key ID and Encryption Key ID.
DRIP Identity Management Entity (DIME): Originally defined in
[RFC9434] and expanded technically in [DET-DNS]. An entity
providing registrar and registry services specifically for DETs.
Attestation: i.e. secure boot of a device
Authentication: of the individual (essential)
Authorization: the admin action of defining roles and what access is
permitted for them & the subsequent reference to these roles in
policy based determination to grant or deny specific access
requests
Access Control: i.e. zero trust. Fine grained near real time access
control
Wiethuechter Expires 8 May 2025 [Page 4]
Internet-Draft det-moc November 2024
Attribution: every action needs to attributable to who took it
Accounting: resource use MUST be tracked
Audit: look back at any of the above after the fact
3. Interactions & Responsibilities
This section outlines the various players in the ecosystem. For
each, it outlines relevant motivations for using DRIP, as well as the
interactions and responsibilities they have in doing so.
3.1. UAS Observers
An Observer has many motivations for detecting Broadcast RID.
Regardless of their motivation the authenticity of the data presented
is important for them to make decisions on their next actions. This
is accomplished by the use of Authentication of the Broadcast RID,
something DRIP provides. Observers also may need additional
information, beyond what is sent over Broadcast RID. While the use
of a Session ID provides a level of privacy, the use of DRIP allows
this privacy while also enabling authorized queries for additional
data.
An Observer device is expected to be able to process messages
compliant with [F3586] and [F3411] Broadcast RID including:
1. Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific
Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag).
The UAS ID SHOULD be displayed either in the style of an IPv6
address per [RFC5952] or as described in Appendix A.
2. Authentication Messages (Message Type 0x2), Authentication Type
0x5 (Specific Authentication Method (SAM)), SAM Types 0x01 (DRIP
Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest) and optionally
0x04 (DRIP Frame). The details of these SAM Types are described
in [RFC9575]. Observer devices MUST follow the requirements of
Section 6.4.2 of [RFC9575]. Appendix A of [RFC9575] is
RECOMMENDED for visualization of the trustworthiness assessment.
3.2. UAS Operators
UAS Operators may want to protect the privacy of their details (such
as Operator Location) and their reputation. Reputation can be gained
or lost with observation and reports of behavior backed by
Authentication. They MAY decide for which UAS RID identifier
purposes they will use DETs. This choice may be constrained by the
jurisdiction's RID regulations.
Wiethuechter Expires 8 May 2025 [Page 5]
Internet-Draft det-moc November 2024
Author: move to Definitions: whether to use DRIP for an
Authentication Key ID only, Single Use Session ID only, or both.
The last of these is the natural approach providing the greatest
benefits and thus the primary focus of this document.
3.3. UAS Manufacturers
Manufacturers typically wish to maintain good reputation of their
brands and are often driven by market forces. Such forces include
requirements and preferences of both UAS Observers and Operators.
To satisfy CAA requirements, a UA MUST transmit whatever [F3411]
messages are needed to carry at least the minimal elements of
information required by the regulator. In the US, under the current
FAA RID rule, these are Basic ID, Location/Vector, and System as
specified in [F3586]. If the content of these messages is to be
trusted, the UA MUST also sign those messages, using the DRIP Wrapper
and/or DRIP Manifest methods, as described in [RFC9575].
Author: add reference to US RID rule
The UAS MUST provide mechanisms and interfaces to enable DET support
for UAS Operator selected purposes. For DRIP this requires at
minimum the UAS Operator to be able to select DRIP options and start
the process of generating and registering a DET with a selected HDA.
3.4. HDA Operators
An HDA Operator must fullfil the requirements of their jurisdiction.
They must also satisfy the desires of UAS Operators.
The HDA MUST provide, upon successful registration of a DET, the four
Broadcast Endorsement objects for use in [RFC9575]. These are:
* Broadcast Endorsement: RAA:A on RAA:I
* Broadcast Endorsement: RAA:I on HDA:A
* Broadcast Endorsement: HDA:A on HDA:I
* Broadcast Endorsement: HDA:I on Registrant
The HDA must also place certain essential information into the
Internet Domain Name System (DNS) and maintain that information as
operations are activated, completed, etc. All the information to be
placed into the DNS is public as it is either needed to make the DET
based systems work or because it is a high-availability replica of
information transmitted in clear-text via Broadcast RID. The DNS
Wiethuechter Expires 8 May 2025 [Page 6]
Internet-Draft det-moc November 2024
records also MUST point to the private registry in which additional
information, required by the HDA/USS itself or the CAA, must be
placed and maintained, for query by authorized parties only.
3.5. RAA Operators
RAAs in this document are scoped to be operated by a State. Each
State is allocated four RAAs, and may decide on their usage.
Each RAA MUST register HDAs within its scope. Each RAA MUST provide
both widely supported "long form" X.509 certificates and DRIP-
specific "short form" endorsements of its HDAs.
The RAA MAY provide services to HDAs for verification of data
pertaining to UAS Operators. For example an HDA registering a UAS
Session ID may query the RAA to verify a previously RAA-registered
UAS Serial Number.
The RAA Operator MUST obtain valid DNS delegation. See Section 7 for
more details.
4. DRIP Service Options
TODO: selection options matrix
5. Requirements for DIME Operation
The requirements below apply to both RAA and HDA operators with a
focus on how HDA operators provide registration and related services
for their clients (i.e. UAS Operators and their UAS).
5.1. Query
A DIME has two query interfaces it MUST support. One interface is
used for public information query and another (identified and using
data found via public queries) is for private information.
5.1.1. Public Information Registries
The information found in these registries has been designated as
public (explicitly or implicitly) by cognizant authority and/or the
information owner. Such information includes public cryptographic
keys needed for authentication in [RFC9575], static Broadcast RID
data and trustworthy pointers to additional information.
These registries are Authoritative Name Servers of DNS. See
[DET-DNS] for operational requirements, query mechanism and response
models.
Wiethuechter Expires 8 May 2025 [Page 7]
Internet-Draft det-moc November 2024
5.1.2. Private Information Registries
The information found in these registries is considered Personally
Identifiable Information (PII) and/or is stored for potential future
audit of registration.
Private information queries MUST follow [DET-DIFF-ACCESS]. This
specifies the use of Registration Data Access Protocol (RDAP) data
models and query formats as the primary query mechanisms. The
specific access control policies are to be defined by the CAA. A CAA
MAY require additional query mechanisms for their jurisdiction.
5.2. Registration
There are several registration functions essential to achieving the
purposes to which this document is directed. Likewise there are
several viable technical approaches to performing these functions.
The only approaches fully specified in [DET-REGISTRATION] are the
Constrained Application Protocol (CoAP) [RFC7252] and/or Concise
Binary Object Representation (CBOR) Web Tokens (CWT) [RFC8392].
DRIP does NOT provide protection against incorrect (e.g. fraudulent)
data entered during registration or asserted subsequently. DRIP does
protect against alteration (intentional or unintentional) of data
subsequent to its assertion by the cryptographic signer. The signer
might be the proximate sender (e.g. UA transmitting Broadcast RID)
or might be an attestor far away and long ago (e.g. root Certificate
Authority). It is the duty of the operator of each DIME, or the
party on whose behalf the DIME is being operated, to validate the
registration data.
5.3. Cross Cutting
DIMEs use and provide various methods to protect data as described
below under seven categories: Attestation, Authentication,
Authorization, Access Control, Attribution, Accounting and Audit.
DRIP refers to these categories collectively as AAA. The definitions
of the seven categories are provided in Section 2.1.
All data, handled under DRIP, MUST be protected by AAA. All private
data MUST also be protected by strong encryption where permitted by
law. These requirements apply to data at rest and in transit in all
phases of the process, i.e. registration and query.
Attestation: MAY be mandated by CAAs for devices (such as UA).
Remote ATtestation ProcedureS (RATS) [RFC9334] is RECOMMENDED by
DRIP. The specific attestation mechanisms in a given jurisdiction
are out of scope for this document.
Wiethuechter Expires 8 May 2025 [Page 8]
Internet-Draft det-moc November 2024
Authentication: SHOULD be provided by DIMEs for entities
participating in Broadcast RID and if provided MUST follow
[RFC9575]
Authorization: TODO
Access Control: MUST be enforced by the DIME to access data from
Section 5.1.2. The eXtensible Access Control Markup Language
(XACML) MUST be used. The policies to be enforced by XACML MUST
be provided by the CAA and are out of scope for this document.
Attribution: TODO
Accounting: TODO
Audit: TODO
6. Compliance Testing
Author: This section is a work in progress.
All interfaces MUST be tested on valid and invalid data (such as
being malformed). When policy is required on an interface all
defined permutations of the policy MUST be tested. The policy engine
MUST be evoked to validate proper decisions and actions are being
made. All data returned from an interface MUST be tested to check
that it conforms with specifications.
The DRIP WG is allocated eight RAA values for experimentation and
testing purposes. These can be delegated to parties, for a limited
period of time at the behest of the DRIP WG, to test DIME
interoperability (e.g. HDA to RAA interactions) in any of the below
subsections. The IANA Considerations section of [DET-DNS] contains
more information on how these delegations are to be handled.
Appendix B provides a set of forms to be filled out and submitted as
part of a CAA compliance process for using DRIP.
+-----+ +-----+
| | | |
| o----(1)--->o |
| A | | B |
| o<---(2)----o |
| | | |
+-----+ +-----+
Figure 1: System Interface Test Diagram
Wiethuechter Expires 8 May 2025 [Page 9]
Internet-Draft det-moc November 2024
6.1. Registration Interface
A, B pairs: (registrant, HDA), (HDA, RAA)
1: Ensure that CoAP endpoints on B can be accessed according to B's
policy by A. Ensure that the endpoints conform to the normative
requirements of [DET-REGISTRATION] Test that B interface properly
handles valid and malformed data. Test that B securely generates
proper artifacts and stores them.
2: Ensure that the CoAP interactions for (1) properly returns data to
A from B. This data MUST include the Broadcast Endorsements, X.509s
and any other data elements required.
6.2. Public Query Interface
A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
(RAA, HDA), (HDA, HDA'), (RAA, RAA')
1: Ensure that B has a properly configured and publicly accessible
Authoritative Name Server for its delegated ip6.arpa domain.
2: Ensure that B returns the valid RRTypes defined in [DET-DNS] to A
based on an ip6.arpa query via standard DNS methods (i.e. using UDP
on port 53). Ensure that the HHIT RRType contains the correct
Certificate with an URI.
6.3. Private Query Interface
A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
(RAA, HDA), (HDA, HDA'), (RAA, RAA')
1: Ensure that the provide URI from the public query interface points
to a valid URI. Ensure that the endpoint on B has proper AAA
mechanisms as defined in this document and enforces the proper policy
options.
2: Ensure that the B endpoint securely returns the data expected
according to policy (matrix of authorized, valid request,
unauthorized and invalid request) to A.
Wiethuechter Expires 8 May 2025 [Page 10]
Internet-Draft det-moc November 2024
7. IANA Considerations
This document requires no new or modified actions by IANA. It does
depend on actions IANA has already undertaken to perform in support
of DRIP [DET-DNS]. It also informs other parties of interactions
they must have with IANA to achieve the intended purposes of this
document; e.g. Nation states MUST request IANA delegation of the DNS
zone under ip6.arpa corresponding to their allocated RAA values.
8. Security Considerations
The considerations discussed in [RFC9153], [RFC9434], [RFC9374],
[RFC9575] and [DET-DNS] apply.
8.1. DETs as a Locator
TODO
9. Privacy & Transparency Considerations
The considerations discussed in [RFC9153] apply.
9.1. DETs as Session ID and Authentication Key ID
The properties of a DET allow it to be used as a Session ID and/or an
Authentication Key ID. There may be scenarios in which Session IDs
are desired for privacy but Authentication is not; although this may
reduce transparency and security, a DET MAY be used exclusively as a
Session ID in such. There are scenarios in which Authentication is
desired but Session IDs are not (e.g. where a CAA does not allow
Session IDs); a DET MAY be used exclusively as an Authentication Key
ID in such. In the scenario expected to be most common, both Session
IDs and Authentication are desired; the same DET SHOULD be used as
both the Session ID and Authentication Key ID in such.
9.2. Selective Encryption
The DET, in its capacity as a Session ID, already acts as a query key
for various data elements (both public and private). Selective
encryption MAY be allowed when using a Session ID to allow authorized
parties to obtain decryption as a service (under UTM, from the USS
under which the observed UA is flying) or access decryption key
material (under UTM or not, from the HDA) via a private lookup. This
enables the encryption of selected data elements in Broadcast RID to
provide a layer of privacy for operators (e.g. their position)
without compromising transparency to entities (e.g.public safety /
law enforcement personnel) that need to know.
Wiethuechter Expires 8 May 2025 [Page 11]
Internet-Draft det-moc November 2024
Selective encryption typically requires network connectivity of the
Observer to perform the private query to obtain the decryption
service or key material. CAAs should consider the expected Observer
environment and prohibit encryption wherever and whenever Observers
cannot reasonably be expected to have connectivity. For example
selective encryption, per CAA regulations, MAY be allowed in dense
urban areas but prohibited in rural areas.
The issue of Observer network connectivity MAY be mitigated with the
use of a shared key, for encryption/decryption, used by multiple
Session IDs in a given HDA over a period of time, that is preloaded
onto the Observer before connectivity is lost. For example Observers
MAY query HDAs for flight volumes in which they are interested to
preload their decryption key(s) for the registrations that day.
10. References
10.1. Normative References
[DET-DIFF-ACCESS]
Wiethuechter, A., "DRIP Entity Tag (DET) Differentiated
Access using RDAP", Work in Progress, Internet-Draft,
draft-wiethuechter-drip-det-diff-access-rdap-00, 27
September 2024, <https://datatracker.ietf.org/doc/html/
draft-wiethuechter-drip-det-diff-access-rdap-00>.
[DET-DNS] Wiethuechter, A. and J. Reid, "DRIP Entity Tags (DET) in
the Domain Name System (DNS)", Work in Progress, Internet-
Draft, draft-ietf-drip-registries-19, 4 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
registries-19>.
[DET-REGISTRATION]
Wiethuechter, A., "DRIP Entity Tag (DET) Registration
using CoAP & CWTs", Work in Progress, Internet-Draft,
draft-wiethuechter-drip-det-registration-coap-cwt-00, 27
September 2024, <https://datatracker.ietf.org/doc/html/
draft-wiethuechter-drip-det-registration-coap-cwt-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Wiethuechter Expires 8 May 2025 [Page 12]
Internet-Draft det-moc November 2024
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
2023, <https://www.rfc-editor.org/info/rfc9434>.
[RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag (DET) Authentication Formats and Protocols for
Broadcast Remote Identification (RID)", RFC 9575,
DOI 10.17487/RFC9575, June 2024,
<https://www.rfc-editor.org/info/rfc9575>.
10.2. Informative References
[F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>.
[F3586] ASTM International, "Standard Practice for Remote ID Means
of Compliance to Federal Aviation Administration
Regulation 14 CFR Part 89", ASTM F3586-22,
DOI 10.1520/F3586-22, July 2022,
<https://www.astm.org/f3411-22a.html>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Wiethuechter Expires 8 May 2025 [Page 13]
Internet-Draft det-moc November 2024
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
Appendix A. HID Abbreviation
The DET MAY be abbreviated. This is useful for display application
with limited screen real-estate as the display of the entire 128-bit
(32-character in hexadecimal) IPv6 address can be costly.
Abbreviations SHOULD follow the following format rules.
Hierarchy Level: Each hierarchy level (RAA/HDA) is represented by a
maximum of four alphanumeric characters. This abbreviation SHOULD
NOT be a single character in length, for obvious reasons of not
being very useful. The decimal representation does fit into the 4
character restriction but is NOT RECOMMENDED. The RECOMMENDED
abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
code for nations. This abbreviation MAY be found in DNS under a
HHIT RRType of the entity or its parents. If there is no
abbreviation hint display devices SHOULD use a fixed size four
character hexadecimal representation of the value. It is
RECOMMENDED that display applications specify a default RAA value,
and only display the RAA abbreviation explicitly when it does not
match the default.
Entity Hash: The entity is represented by a fixed size four
character hexadecimal string using the last four characters of the
DET. If a collision (within the same HID space) on display
occurs, the four characters SHOULD shift to the left by one
hexadecimal character until the collision is resolved. This
window MUST stay within the last sixteen hexadecimal characters of
the DET. The : character found in an IPv6 address string is
ignored.
Delimiter: Each section is delimited by a single character. This
can be any whitespace character (except newline and tab) or any
non-alphanumeric character (period, comma, semicolon, etc.). It
is RECOMMENDED that the delimiter is consistent between
components. The RECOMMENDED delimiter is the space character.
For example a DET with the values of RAA 16383 and HDA 1 without any
abbreviation hint from DNS is represented by the string 3FFF 0001
xxxx with xxxx representing a entity hash. If an abbreviation for
the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
the DET can be represented with the string of DRIP01 TEST xxxx.
Wiethuechter Expires 8 May 2025 [Page 14]
Internet-Draft det-moc November 2024
For an example of the entity hash, let's assume there are two DETs
with the following hashes in the same HID: 0000:1111:2222:3333 and
0000:2222:1111:3333. At first both DETs are represented with the
same abbreviation: RAA HDA 3333. One of these DETs is selected by
the display application to shift the display hash one character to
avoid the collision resulting in the following two abbreviations: RAA
HDA 3333 and RAA HDA 1333.
Appendix B. Compliance Submission Forms
TODO
Author's Address
Adam Wiethuechter
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Wiethuechter Expires 8 May 2025 [Page 15]