Subject: [Tm-rid] WG Charter: charter-ietf-tmrid-00-01

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 18 Jan 2020 08:31:38 +0000

With Daniel Migault’s and others assistance, here is already a much improved charter:

https://datatracker.ietf.org/doc/charter-ietf-tmrid/

I intend to use this charter to create the WG by submitting it to the internal IESG evaluation (the first step) for the IESG telechat on 6 of February. So, your comments and suggestions will be welcome on this mailing list before the 30th of January.

Thanks again to Daniel, Stu, Adam, Ryan, Gonzalo, and everyone who participated in this charter.

Regards

-éric

From: Tm-rid <[email-masked]> on behalf of Eric Vyncke <[email-masked]>
Date: Friday, 17 January 2020 at 23:39
To: "Card, Stu" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: ryoung <[email-masked]>, Seth Rao <[email-masked]>, Andy Thurling <[email-masked]>, Monica Pearson <[email-masked]>
Subject: Re: [Tm-rid] charter draft v4

Dear TMRID members,

In order to move forward with the creation of the TMRIG WG, I have copied the charter into the IETF ‘datatracker’, this is the first step.

https://datatracker.ietf.org/doc/charter-ietf-tmrid/

I personally find it still difficult to read and it lacks the list of current drafts. May I ask this mailing list to improve this text? I would love to propose it to the IESG internal review in time to potentially be a WG in Vancouver.

Regards

-éric

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Friday, 10 January 2020 at 19:51
To: "[email-masked]" <[email-masked]>
Cc: ryoung <[email-masked]>, Seth Rao <[email-masked]>, Andy Thurling <[email-masked]>, Monica Pearson <[email-masked]>
Subject: [Tm-rid] charter draft v4

all --

I have attempted to address all comments received; see revised charter draft v4 below.

Unfortunately, the lists of milestones, drafts, acronyms and references made it still longer (although the body text of the charter itself is now clearer and more succinct). I generally have not listed all the potentially relevant RFCs as there could be many and presumably anyone reading an IETF Working Group charter knows how to use the datatracker.

While I have identified all the other SDOs of which I am aware with whom we may need liaison, actually getting a liaison agreement is both above my pay grade and difficult before we have a charter (i.e. why would ASTM take us seriously until we have a WG).

I appreciate your reviews of earlier drafts. Your comments made this much better!

Please review this latest draft at your earliest convenience as the need for trustworthy, immediately actionable UAS RID is urgent, the FAA NPRM comment period expires at the end of February, ASTM is resuming work to revise their standard accordingly, and IETF 107 in Vancouver is in March. :-)

Other than updating and substantially expanding my proposed Applicability Statement (draft-card-tmrid-uas-00), what is next to get this moving, specifically through IESG chartering and generally forward?

Thanks all!

==

Trustworthy Multipurpose Remote Identification (TM-RID) Proposed WG Charter v4

CAAs [1] worldwide have initiated rule making for UAS [2] RID [3]. The US FAA [4] has published a NPRM [5].  CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry consensus technical standards as acceptable means of compliance. One key standard is ASTM WK65041 [6].  Network RID defines a set of information for UAS to make available globally indirectly via the Internet. Broadcast RID defines a set of messages for UA [7] to send locally directly one-way over Bluetooth or Wi-Fi. WK65041 addresses how to neither populate/query registries, ensure trustworthiness of information nor make it instantly useful.

TM-RID’s goal is to make RID immediately actionable, in both Internet and local-only connected scenarios, especially emergencies, in severely constrained UAS environments [8], balancing legitimate (e.g. public safety) authorities’ Need To Know trustworthy information with UAS operators’ privacy. To accomplish this, TM-RID will liaise with SDOs [9] and complement their standards with IETF work to meet this urgent need. An Applicability Statement RFC for UAS RID, showing how to use IETF standardized technologies for this purpose, will be a central work product. Technical Specification RFCs will address any necessary enhancements of specific supporting protocols. TM-RID potentially could be applied to verifiably identify other types of registered things reported to be in specified physical locations, but the urgent motivation and clear initial focus is UAS.

One possible approach leverages Internet domain name registration business models, infrastructure and standards, including EPP [10], RDAP [11] and DNS [12], plus the HIP [13] HIT [14], with UTM [15] system USS [16] as registries. This provides stronger privacy and authenticity than other FAA NPRM / ASTM standard UAS ID Types (static manufacturer assigned hardware serial number per [17] or dynamic single-use USS assigned UUID [18]), but would necessitate several HIP enhancements (all with applicability beyond UAS RID); prototypes using DNS to reverse lookup UAS RID information from a broadcast HIT have been successfully flown. Any comprehensive approach should –

- Verifiably identify all entities in the UTM ecosystem – UA, GCS [19], observer devices, registries, USS, et al – presumably using public key operations to:
= prove ownership of the claimed ID;
= authenticate other claims made via RID (e.g. location) as signed by the owner of that ID; and
= provide observers [w/o Internet connectivity] locally verifiable proof that ID is in a known registry.

- Enable all observers to use a received ID to look up minimal public information.

- Enable only strongly authenticated, policy authorized observers to look up more extensive private information (including operator PII [20]) needed for legitimate (e.g. public safety or security) purposes in access controlled registries (e.g. as with Internet domain names [21]).

Proposed milestones, accelerated to meet urgent UAS RID safety/security need –

2020 MAR: Present contemplated technical approach and solicit alternative approaches.
draft-wiethuechter-tmrid-auth-04<https://datatracker.ietf.org/doc/draft-wiethuechter-tmrid-auth/>
draft-card-tmrid-uas-00<https://datatracker.ietf.org/doc/draft-card-tmrid-uas/>
2020 JUL: Select technical approach from those proposed in sufficient detail to enable assessment.
2020 NOV: Drafts initially essential for UAS RID to IESG (within one year of the FAA NPRM).

Potential milestones in collaboration with the HIP WG, supporting UAS RID and other applications –

2020 MAR new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed for severely constrained [UAS] environments.
draft-moskowitz-hip-new-crypto-03<https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/>
draft-moskowitz-orchid-cshake-00<https://datatracker.ietf.org/doc/draft-moskowitz-orchid-cshake/>

2020 MAR HHIT [22]: Enable scalable trustable [UA] registration and information retrieval (e.g. RDAP, DNS) by adding optional structure to the currently flat space of HITs / ORCHIDs [23] derived from and compactly (as IPv6 addresses) representing HIs [24] ([self-generated] public keys).
draft-moskowitz-hip-hierarchical-hit-03<https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/>

2020 JUL registration extensions:  Prevent registration of duplicate HHITs, populate registries with IDs and associated data, update DNS and provide proof of authenticity.
draft-moskowitz-hip-hhit-registries-01<https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/>

2020 JUL OAuth investigation: Explore and if feasible document, HIP as an OAuth method [for UTM].

2021 MAR proxies: Enable any observer of a [UA] “thing” to contact an intermediary that will either deny or facilitate secure communications with the operator of the thing, while maintaining the privacy of the operator’s location and PII to all but authorized parties, per policy.

2021 JUL multicast: To securely and efficiently communicate with a group, multicast to their ephemeral (and likely multiple per host) IP addresses, starting from individual and/or group HITs.

Acronyms and references:

[1] Civil Aviation Authority
[2] Unmanned Aircraft System[s]
[3] Remote Identification
[4] United States Federal Aviation Administration
[5] Notice of Proposed Rule-Making https://www.federalregister.gov/documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems
[6] ASTM International F38 Committee Work Item WK65041 “Standard Specification for UAS Remote ID and Tracking” https://www.astm.org/DATABASE.CART/WORKITEMS/WK65041.htm
[7] Unmanned Aircraft
[8] UAS Identification and Tracking Aviation Rulemaking Committee Recommendations Final Report 2017 SEP 30 https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf
[9] Standards Development Organizations including American National Standards Institute (ANSI), ASTM International (formerly American Society for Testing and Materials), Consumer Technology Association (CTA), International Civil Aviation Organization (ICAO), RTCA (formerly Radio Technical Commission for Aeronautics), et al
[10] Extensible Provisioning Protocol
[11] Registry Data Access Protocol
[12] Domain Name System
[13] Host Identity Protocol
[14] Host Identity Tag
[15] UAS Traffic Management
[16] UAS Service Supplier[s]
[17] ANSI/CTA-2063-A https://standards.cta.tech/apps/group_public/project/details.php?project_id=587
[18] Universally Unique Identifier, e.g. RFC 4122
[19] Ground Control Station[s]
[20] Personally Identifiable Information
[21] https://www.arin..net/resources/registry/whois/rdap/<https://www.arin.net/resources/registry/whois/rdap/>
[22] Hierarchical HIT
[23] Overlay Routable Cryptographic Hash Identifier
[24] Host Identity