Subject: [Tm-rid] charter draft v4

From: "Card, Stu" <[email-masked]>
Date: Fri, 10 Jan 2020 13:50:13 -0500

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/

[22] Hierarchical HIT

[23] Overlay Routable Cryptographic Hash Identifier

[24] Host Identity

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Jan 2020 17:21:55 -0500

I have read the V4 charter, it seems correct to me.
I sent Stu a few edits privately which do not have much public relevance.

---

From: <[email-masked]>
Date: Sun, 12 Jan 2020 13:40:27 -0500

Keep in mind that the International Civil Aviation Organization (ICAO) is the United Nations Organization coordinating body for global aviation standards and recommended practices. 

ICAO has begun to tackle the issue of incorporating unmanned aircraft into a global inter-connected registry network.

ICAO intends to be the responsible authority for assigning a unique MFR Code to UAS manufacturers, based on ANSI/CTA Standard 2063-A: Small Unmanned Aerial Systems Serial Numbers 

“All UAS shall be assigned SN = [4 Character MFR CODE] [1 Character LENGTH CODE] [15 Character MANUFACTURER’S SERIAL NUMBER] “

Note that the original intent of both the ANSI/CTA 2063-A standard and the ASTM UAS Remote ID WK65041/F3411 standard were each to apply to small UAS (sUAS) operating below 500 ft./150 meters.

The seeming intent of both the FAA UAS Remote ID Notice of Proposed Rulemaking (NPRM) issued in December 2019 and the ICAO registry network is to extend application to all unmanned aircraft regardless of size and operating altitude.

All the more reason for the IETF TM-RID charter to get this right!

==

The following links have background on ICAO proposals briefed at an ICAO conference in November 2019:

Presentation on ICAO Aircraft Registry Network

1.02.3 - David Scorer

PDF Presentation

https://www.icao.int/Meetings/DRONEENABLE3/Presentations/1.02.3%20-%20David%20Scorer.pdf
Video Capture 31:59 to 59:37

https://www.youtube.com/watch?v=EXfxqLrbydI <https://www.youtube.com/watch?v=EXfxqLrbydI&list=PLOoOa5RwilZLuA8D5m1WDJPs_amK-mZLZ&index=3&t=0s> &list=PLOoOa5RwilZLuA8D5m1WDJPs_amK-mZLZ&index=3&t=0s

Ray Young, Ph.D. 

New York UAS Test Site

+1.702.525.1562

[email-masked] <mailto:[email-masked]> 

From: Card, Stu <[email-masked]> 
Sent: Friday, January 10, 2020 13:50
To: [email-masked]
Cc: Seth Rao <[email-masked]>; Monica Pearson <[email-masked]>; ryoung <[email-masked]>; Andy Thurling <[email-masked]>
Subject: 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:

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

 <https://datatracker.ietf.org/doc/draft-wiethuechter-tmrid-auth/> draft-wiethuechter-tmrid-auth-04 <https://datatracker.ietf.org/doc/draft-card-tmrid-uas/> 
draft-card-tmrid-uas-00

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.

 <https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/> draft-moskowitz-hip-new-crypto-03 <https://datatracker.ietf.org/doc/draft-moskowitz-orchid-cshake/> 
draft-moskowitz-orchid-cshake-00

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

 <https://datatracker.ietf.org/doc/draft-moskowitz-hip-hierarchical-hit/> draft-moskowitz-hip-hierarchical-hit-03

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

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:

[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

[12] Domain Name System

[14] Host Identity Tag

[17] ANSI/CTA-2063-A https://standards.cta.tech/apps/group_public/project/details.php?project_id=587

[22] Hierarchical HIT

[24] Host Identity

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 15 Jan 2020 10:43:58 -0500

I have been looking for the European equivalent of the FAA NPRM. So far, I
have found
https://www.easa.europa.eu/newsroom-and-events/press-releases/eu-wide-rules-drones-published
which links
to
https://eur-lex.europa.eu/eli/reg_del/2019/945/oj with the basic RID
functional requirements inc. transmitted elements of information, and
https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj where UAS.OPEN.060
(1)(d) &  UAS.SPEC.060 (2)(c) require confirmation RID is working, plus
https://www.easa.europa.eu/easa-and-you/civil-drones-rpas  which promises
forthcoming further helpful information.
I think the 945 & 947 links are the ones to cite in our UAS RID use case
requirements draft [and TM-RID charter], along with the FAA NPRM & ASTM
standard?

BTW, if we go down the HIP path to TM-RID that we have been prototyping, a
manufacturer could generate a HIP Host Identity, derive the corresponding
Hierarchical Host Identity Tag, self-register it (with the MFR CODE mapping
to the manufacturer's in-house HHIT registry), and encode it in the
ANSI/CTA serial number format below. This could be useful in initially
provisioning an UA with RID.

 (On Sun, Jan 12, 2020 at 1:40 PM <[email-masked]> wrote:

> ... the International Civil Aviation Organization (ICAO)... has begun to
> tackle the issue of incorporating unmanned aircraft into a global
> inter-connected registry network.
>
> ICAO intends to be the responsible authority for assigning a unique MFR
> Code to UAS manufacturers, based on ANSI/CTA Standard 2063-A: Small
> Unmanned Aerial Systems Serial Numbers
>
> “All UAS shall be assigned SN = [4 Character MFR CODE] [1 Character LENGTH
> CODE] [15 Character MANUFACTURER’S SERIAL NUMBER] “
>
> Note that the original intent of both the ANSI/CTA 2063-A standard and the
> ASTM UAS Remote ID WK65041/F3411 standard were each to apply to small UAS
> (sUAS) operating below 500 ft./150 meters. The seeming intent of both the
> FAA UAS Remote ID Notice of Proposed Rulemaking (NPRM) issued in December
> 2019 and the ICAO registry network is to extend application to *all
> unmanned aircraft regardless of size and operating altitude*. All the
> more reason for the IETF TM-RID charter to get this right!
>
> ==
>
> https://www.youtube.com/watch?v=EXfxqLrbydI&list=PLOoOa5RwilZLuA8D5m1WDJPs_amK-mZLZ&index=3&t=0s
>
> Ray Young, Ph.D.
>
> New York UAS Test Site
>
> +1.702.525.1562
>
> [email-masked]
>

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 15 Jan 2020 12:05:45 -0500

A HIP Host Identity (HI) itself is a public key, preferably self-generated,
typically considerably longer than a MAC address, usable for strong
authentication (and encryption key establishment).
The HI is cryptographically hashed and combined with some other fields to
yield a [Hierarchichal] Host Identity Tag ([H]HIT), which is a valid 128
bit IPv6 address (overlay routable & link-locally usable).
We cannot fit 128 bits into the ANSI/CTA format, but...
The first 28 bits are a fixed IANA prefix designating the IPv6 address as
an Overlay Routable Cryptographic Hash Identifier (ORCHID), so need not be
encoded.
The next 4 bits (the OGA) say what kind of ORCHID it is, which in our case
would always be a HHIT, so need not be encoded.
The next 32 bits of a HHIT are the [2 level] registry ID, which could be
looked up from the 4 character MFR code in a table no larger than ~1M
entries (probably much smaller).
Leaving only 64 bits, and we can encode 5 bits per character times 15
characters in the ANSI/CTA format, so we can fit with 2 characters to spare!
I would recommend using them to encode the last 4 bits of the IANA prefix
and the OGA, for future address space expansion and general flexibility.

This is not what privacy-conscious UAS operators would want to use in
operations: for that, they want the FAA one-time use USS assigned Session
ID = ASTM UAS ID Type 3 UTM assigned UUIDv4.

However, it could be used:
- in operations, by less privacy conscious UAS operators;
- perhaps in operations in Europe (where the serial number is thus far the
only allowed UAS ID Type);
- in the US, for initial provisioning/registration of the UA, that would
subsequently operate with single-use session IDs (for which we also hope to
get HHITs a UAS ID Type).

I find it exciting that we can use clever encodings to leverage IETF
protocols to complement the ASTM standard and comply with anticipated US
and European regs, improving trustworthiness and enabling instant Observer
to Operator or Pilot or Proxy secure communications, without needing any
change to any of the existing specifications external to IETF. Of course,
we can get only some of the potential benefit that way; to maximize the
value of leveraged IETF protocols, we need ASTM to specify a HHIT as a UAS
ID Type, and the regulators to allow the use of that UAS ID Type.

On Wed, Jan 15, 2020 at 10:52 AM Seth Rao <[email-masked]> wrote:

> Stu,
>
> When you say “a manufacturer could generate a HIP Host Identity” , are you
> thinking a something along the lines of a MAC address? If so what length
> hex?
>
>
>
>
>
> Seth Rao
> Founder and CTO | SecReliant LLC
> 800 3rd Avenue, Suite 2700
> New York, NY 10022
> Office: (212) 231-8477 | Cell: (212) 920-7074 www.SecReliant.com
> https://www.linkedin.com/in/sethraoakabatman
>
> SecReliant LLC is a Certified Woman-owned Business www.SecReliant.com
>
> CONFIDENTIAL COMMUNICATION
> Notice:  This e-mail is covered by the Electronic Communications Privacy
> Act, 18 U.S.C. Sec.2510-2521, is confidential and may be legally
> privileged.  If you are not the intended recipient, you are hereby notified
> that any retention, dissemination, distribution, or copying of this
> communication is strictly prohibited.  Please reply to the sender that you
> have received the message in error, then delete it. Thank you.
>
> The Sender believes this email and any attachment to be free from viruses
> and Trojan Horses etc.  Recipient assumes all risk by opening this email
> and any attachment(s). If you have received this electronic transmission in
> error, please notify us immediately at (212)231-8477.
>
>
>
> *From:* Card, Stu <[email-masked]>
> *Sent:* Wednesday, January 15, 2020 10:44 AM
> *To:* [email-masked]
> *Cc:* Seth Rao <[email-masked]>; Monica Pearson <
> [email-masked]>; Andy Thurling <[email-masked]>;
> ryoung <[email-masked]>
> *Subject:* Re: charter draft v4
>
>
>
> https://www.easa.europa.eu/newsroom-and-events/press-releases/eu-wide-rules-drones-published which links
> to
>
> https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj where *UAS.OPEN.060
> (1)(d) & * *UAS.SPEC.060 (2)(c) *require confirmation RID is working, plus
>

---

From: Seth Rao <[email-masked]>
Date: Wed, 15 Jan 2020 15:52:27 +0000

Stu,
When you say “a manufacturer could generate a HIP Host Identity” , are you thinking a something along the lines of a MAC address? If so what length hex?

Seth Rao
Founder and CTO | SecReliant LLC
800 3rd Avenue, Suite 2700
New York, NY 10022
Office: (212) 231-8477 | Cell: (212) 920-7074 www.SecReliant.com<http://www.SecReliant.com>
https://www.linkedin.com/in/sethraoakabatman

SecReliant LLC is a Certified Woman-owned Business www.SecReliant.com<http://www.SecReliant.com>

CONFIDENTIAL COMMUNICATION
Notice:  This e-mail is covered by the Electronic Communications Privacy Act, 18 U.S.C. Sec.2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it. Thank you.

The Sender believes this email and any attachment to be free from viruses and Trojan Horses etc.  Recipient assumes all risk by opening this email and any attachment(s). If you have received this electronic transmission in error, please notify us immediately at (212)231-8477.

From: Card, Stu <[email-masked]>
Sent: Wednesday, January 15, 2020 10:44 AM
To: [email-masked]
Cc: Seth Rao <[email-masked]>; Monica Pearson <[email-masked]>; Andy Thurling <[email-masked]>; ryoung <[email-masked]>
Subject: Re: charter draft v4

I have been looking for the European equivalent of the FAA NPRM. So far, I have found
https://www.easa.europa.eu/newsroom-and-events/press-releases/eu-wide-rules-drones-published which links to
https://eur-lex.europa.eu/eli/reg_del/2019/945/oj with the basic RID functional requirements inc. transmitted elements of information, and
https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj where UAS.OPEN.060 (1)(d) &  UAS.SPEC.060 (2)(c) require confirmation RID is working, plus
https://www.easa.europa.eu/easa-and-you/civil-drones-rpas  which promises forthcoming further helpful information.
I think the 945 & 947 links are the ones to cite in our UAS RID use case requirements draft [and TM-RID charter], along with the FAA NPRM & ASTM standard?

BTW, if we go down the HIP path to TM-RID that we have been prototyping, a manufacturer could generate a HIP Host Identity, derive the corresponding Hierarchical Host Identity Tag, self-register it (with the MFR CODE mapping to the manufacturer's in-house HHIT registry), and encode it in the ANSI/CTA serial number format below. This could be useful in initially provisioning an UA with RID.

 (On Sun, Jan 12, 2020 at 1:40 PM <[email-masked]<mailto:[email-masked]>> wrote:

... the International Civil Aviation Organization (ICAO)... has begun to tackle the issue of incorporating unmanned aircraft into a global inter-connected registry network.

Note that the original intent of both the ANSI/CTA 2063-A standard and the ASTM UAS Remote ID WK65041/F3411 standard were each to apply to small UAS (sUAS) operating below 500 ft./150 meters. The seeming intent of both the FAA UAS Remote ID Notice of Proposed Rulemaking (NPRM) issued in December 2019 and the ICAO registry network is to extend application to all unmanned aircraft regardless of size and operating altitude. All the more reason for the IETF TM-RID charter to get this right!
==

1.02.3 - David Scorer

PDF Presentation

https://www.youtube.com/watch?v=EXfxqLrbydI&list=PLOoOa5RwilZLuA8D5m1WDJPs_amK-mZLZ&index=3&t=0s
Ray Young, Ph.D.
New York UAS Test Site
+1.702.525.1562
[email-masked]<mailto:[email-masked]>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 Jan 2020 22:38:48 +0000

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

Thanks all!

==

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

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/>

Acronyms and references:

[21] https://www.arin..net/resources/registry/whois/rdap/<https://www.arin.net/resources/registry/whois/rdap/>