[Drip] Re: Trustworthy Air Domain Awareness Document & Paths Forwards

[Adam Wiethuechter <[e-mail]>]

Hi Andrei,

The Endorsement structure defined in Section 4.2 of RFC9575 is a generalized form, meant to have the Evidence (i.e. "child") and Endorser (i.e. "parent") filled in. In a typical deployment there will be at least four of these "Links" to be broadcast. Appendix B goes into detail with an example on including broadcast of all the Links.

Child (DET + HI) = Evidence
Parent (DET) = Endorser
RAA Authorizer
RAA Authorizer
HDA Authorizer
RAA Authorizer
HDA Issuer
HDA Authorizer
UA
HDA Issuer

Note that this is following the model proposed by Bob in the DKI [2] where there are the roles of "Authorizer" and "Issuer" that are added. It might be wise for the DKI to add to its content the explicit Endorsement contents being issued as a given role. This should be reinforced in both the Interfaces (where DKI is referenced) and CONOPS (where both Interfaces and DKI are referenced at a high level for aviation use) documents being proposed as the breakdown of the TADA document.
--------
73,
Adam T. Wiethuechter
Trustworthy Systems Engineer // AX Enterprize, LLC
________________________________
From: Andrei Gurtov <andrei.gurtov=[e-mail]>
Sent: Monday, November 24, 2025 2:15 PM
To: [e-mail] <[e-mail]>
Subject: [Drip] Re: Trustworthy Air Domain Awareness Document & Paths Forwards


Hi, Adam

My students implementing Auth draft were confused what means Parent or Child DET in auth messages. Could not find any references to child in TADA document?

br Andrei

On 11/6/2025 4:33 AM, Adam Wiethuechter wrote:
All,

[1] is the TADA document  mentioned during IETF 124 meeting during my presentation.
It covers a wide scope broken into four major areas in the following order:

  *
UAS-specific ecosystem players and their responsibilities
  *
Registration (Web Token/HTTPS)
  *
Query (RDAP)
  *
DKIX (extracted and reformatted from DKI [2])

What I propose to the WG, and solicit comments and feedback on is if this document should be broken apart as follows.

"Registration & Query Interfaces for a DRIP Identity Management Entity (DIME)" — an extraction and reorganization of Section 4 of TADA, this is standards track document. I have attached a working copy of this document that I believe is fairly mature but needs feedback, another author (I have a potential candidate that I will query tomorrow at IETF) and needs to be properly implemented and interop tested. The DKIX appendix would be removed once decision on DKI is made.

"CONOPS for using a DRIP Entity Tag (DET) in an [Aviation/]UAS Ecosystem" — an extraction and expansion, to maybe include AAM/UAM concepts, of Section 3 of TADA, maybe some DKI (?). This is most likely a standards track, informational document instead of a BCP as discussed in the meeting - will continue to solicit feedback at IETF the rest of the week on this as well as here on the list.

This document would be reworked to include relevant DronesQuad criteria and submitted to them once a mature draft is reached to solicit their feedback on if the document when publish would be endorsed or not. I have attached my working copy of this document after the sections were extracted from TADA to make it standalone. I have at least another author in mind (will be discussing that this week in person), but solicit input and invitation for more contributors.

"DRIP Key Infrastructure (DKI) & [Aviation] X.509 Profiles (DKIX)" — Bob's existing DKI document, Appendix D of TADA re-added as is to replace Section 4 of DKI [3]. I have largely stayed out of Bob's way on this document as PKI is not exactly my expertise but did lend Bob a hand in building an implementation [4] to create the X.509s (and C509 validation test).

As a slight variation of above, the group could merge the CONOPS and DKI into a single document. I would think it be wise to keep the X.509 profiles out of the CONOPS and just be a reference, as a lot of the DKIX requires context of the DKI to understand the profiles, while DKI gets very specific about Certificate Authority (CA) operation and requirements to run the variant of PKIX in an aviation envirornment. So the above layout is my suggestion to the group. This also explains my "[Aviation]" notation as the DKIX profiles are not just for UAS but built for general avaiation use for ICAO as referrenced in the Doc 10169.

Most, if not all of the DKI work is done IMO and just needs review under the IETF.
The majority of the Interfaces document is complete and needs to be sanity checked and reviewed/implemented to find any holes or issues. The basic design of the registration is IMO sound. The data models should be looked at carefully and aviation/UAS specific keys should be identified and added as an appendix.
CONOPS is probably the least mature document of these three proposed but also probably the most susceptible to outside influence due to its intended scope and use. The test present in the CONOPS has gone through numerous private rewrites over the months as I struggled with trying to find the best path to scope and be useful.

I hope this gives some better context than my presentation on what is currently being worked on that is most needed to be considered for adoption and continued work.

[1]  https://datatracker.ietf.org/doc/draft-wiethuechter-drip-det-tada/
[2]  https://datatracker.ietf.org/doc/draft-ietf-drip-dki/
[3] with this merge I would request that the formatting of sections (and their ordering) from TADA of the DKIX appendix be kept as for me personally it felt easier to follow. Review of Bob's draft and direct comparison would be good for this.
[4]  https://github.com/ietf-wg-drip/drip-scripts
--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC