Subject: Re: [Tm-rid] Proposed WG Charter v2

From: "Card, Stu" <[email-masked]>
Date: Thu, 2 Jan 2020 17:00:57 -0500

Week turned into month but here's my attempt. All please review and comment.

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

Civil Aviation Authorities (CAAs) worldwide (e.g. United States Federal
Aviation Administration, FAA), have initiated rule making for Unmanned
Aircraft Systems (UAS) Remote Identification (RID).  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 here is ASTM International
F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID
and Tracking”.  ASTM Network RID defines a set of information for UAS to
make available globally indirectly via the Internet. ASTM Broadcast RID
defines a set of messages for Unmanned Aircraft (UA) to send locally
directly one-way over Bluetooth or IEEE 802.11. WK65041 addresses neither
how to ensure trustworthiness of RID information nor how to 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, balancing legitimate (e.g. public safety)
authorities’ Need To Know *trustworthy* information with UAS operators’
*privacy*. To accomplish this, TM-RID will liaise with ASTM, CTA, ICAO,
RTCA, *et al* 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. Other Technical Specification RFCs will address enhancements of
specific supporting protocols. Prototypes using the contemplated technical
approach have already been successfully flown.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is uniquely
ideally suited to serving as an UAS ID Type. A  HIT, an Overlay Routable
Cryptographic Hash Identifier (ORCHID), is derived from and compactly (as
an IPv6 address) represents a Host Identity (HI), a [self-generated] public
key. HITs can verifiably identify all entities in the UAS Traffic
Management (UTM) ecosystem: UA, Ground Control Stations (GCS), observer
devices, registries, etc. TM-RID will specify how to leverage HITs –

- Provide strong RID authentication by using the HI in public key
operations to:

= prove ownership of the claimed ID (HIT);

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

- Use DNS to enable observers to use a received HIT to look up minimal
public ID information.

- Use access controlled RDAP to enable authorized observers to look up more
extensive private information (including operator Personally Identifiable
Information, PII) needed for legitimate (e.g. public safety or security)
purposes from an Internet domain name (Whois) or similar registry.

This provides stronger privacy than other FAA Notice of Proposed Rulemaking
(NPRM) / ASTM standard UAS ID Types, while providing greater assurance of
authenticity to authorized observers, but necessitates several HIP
enhancements –

- Hierarchical HIT (HHIT): Enable scalable and trustable UA registration
and information retrieval (e.g. with DNS and RDAP) by adding optional
structure to the (currently flat) HIT/ORCHID space.

- registration extensions:  Prevent registration of duplicate HHITs,
populate registries with IDs and associated data, update DNS, support
Rendez-Vous Servers (RVS) and provide proof of authenticity.

- proxies: Enable any party observing an UA to contact a RVS or other
intermediary that will either deny or facilitate secure communications with
the party controlling the UA, while maintaining the privacy of the latter’s
identity, location and other information to all but authorized parties, per
policy.

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

- new cryptographic algorithms: Extremely compact keys and signatures (such
as are enabled by EdDSA and Keccak functions) are needed for severely
constrained [UAS] environments.

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. TM-RID enhancements to
HIP will be generic: of these, only HHITs with their associated
registration procedures and compact crypto are vital to support UAS RID;
HIP proxies and HIP multicast are stretch goals. Some UTM concepts envision
using OAuth for GCS and personnel; HIP as an OAuth method also will be
investigated. The Applicability Statement and the Technical Specifications
initially essential for UAS RID will be published within one year of the
2019 DEC 31 FAA NPRM.

On Mon, Dec 2, 2019 at 12:31 PM Card, Stu <[email-masked]> wrote:

> I will try wordsmithing this week.
>
> On Mon, Dec 2, 2019, 09:04 Michael Richardson <[email-masked]>
> wrote:
>
>>
>> I am enthusiatic about this work, although I don't anticipate being able
>> to
>> be more than a bystandard on this.
>>
>> Robert Moskowitz <[email-masked]> wrote:
>>     > TM-RID will build upon the Host Identity Tag (HIT) from the Host
>> Identity
>>     > Protocol (HIP) as an RID and augment it and supporting HIP and
>> other IETF
>>     > technologies to add trustworthiness to the ASTM messaging suite.
>>
>> I think that this sentence needs editing.  Too many ".. and"
>>
>>     > The goal is
>>     > to provide trustworthiness both in an Internet connected
>> environment and
>>     > emergency, unconnected situations within the highly constrained
>> environment
>>     > of UAS.
>>
>> I think that a reference for the nature of the constrained environment
>> might
>> be in order.
>>
>>     > The Host Identity Tag (HIT) is ideally, in fact uniquely, suited to
>> work
>>     > within this RID effort.  The Host Identity (HI) behind the HIT can
>> be used to
>>     > sign Broadcast Authentication Messages, thus proving ownership of
>> the RID
>>     > (HIT) and signed messages.  HITs provide significantly superior
>> privacy
>>     > compared to other allowed RID types while providing greater
>> assurance to
>>     > authorized observers that they are accessing the proper PII for the
>> UA.
>>
>> This wanders into solution space, and I think it would be better to omit
>> this.
>>
>>     > TM-RID will create specifications for HIP-augmented ASTM RID
>> messages..
>>     > Initially this will consist of additional RID Authentication
>> Messages that
>>     > use the HI in public key signing operations: to prove UAS ownership
>> of a
>>     > Hierarchical HIT (HHIT); to authenticate other claims made via RID,
>> such as
>>     > position and velocity, as having been made by the owner of that
>> HHIT; and to
>>     > provide observers lacking current Internet connectivity with locally
>>     > verifiable UAS proof-of-registration objects.
>>
>> removing some of the solutions, leaving the requirements:
>>
>> TM-RID will create specifications to prove UAS ownership of a
>> Hierarchical HIT (HHIT); providing a framework to authenticate other
>> claims, such as
>> position and velocity, as having been made by the owner of that HHIT; and
>> to
>> provide observers lacking current Internet connectivity with locally
>> verifiable UAS proof-of-registration objects.
>>
>> I would have written this as numbered points.
>>
>>     > For this, HIP would be amended to be used effectively in this
>> environment:
>>
>> I think you could put a period instead of : and omit the next three
>> paragraphs.
>>
>>     > HHITs are envisioned to identify all components in the UAS/UTM (UAS
>> Traffic
>>     > Management) environment: UA, Command Consoles, Observer devices, and
>>     > Registries.  This will entail further work as experience is gained
>> in using
>>     > HIP for UAS RID.  For example, some (UTM) systems envision using
>> OAuth for
>>     > Ground Control Systems (GCS) and authorized safety personnel.  HIP
>> as an
>>     > OAuth method may help in merging HIP into these systems.
>>
>>     > The workgroup will need to liaison with the various SDOs working in
>> the UAS
>>     > regulation space.
>>
>> Please if you could list those SDOs?
>> Do we need to do liason agreements with them?  I would be happier if that
>> was
>> part of the plan.
>>
>> How will we engage with implementers?  I.e. how are we going to get
>> running-code?
>>
>>
>>
>> --
>> Michael Richardson <[email-masked]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>> --
>> Tm-rid mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tm-rid
>>
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 3 Jan 2020 16:34:12 +0000

Happy New Year all

Stu, exactly one month ;-)

This TM-RID community needs to work more and faster around this chartering. A liaison statement from FAA or other CAA or ICAO or ASTM (not exclusive) on this work could also help a lot.

About the charter itself, it is difficult to parse as there are many acronyms + their expansion. Unsure how to solve this issue though (except like this trick[1]).

The charter flow does not follow the usual one. E.g., it would benefit a lot of clearly identifying the work items (or at least clearly the WG scope). Having milestones (i.e. dates) is also helpful for chartering a WG, milestones are outside of the charter itself but can be enumerated, for now, as bullets after the charter.

Citing the existing Internet draft is also typical in a charter.

To be direct, I am afraid that statement like “HIP HIT is uniquely ideally suited to serving as an UAS ID Type” will be attract consensus in a charter. I would suggest to have a work item to check the adequacy of HIP to the problem statement than trying to defend this assumption in the charter itself.

Please continue this good work and let’s try to have more interactivity around this topic

-eric

[1] I believe that footnotes can be added to charters ;-)

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Thursday, 2 January 2020 at 23:01
To: "[email-masked]" <[email-masked]>
Cc: ryoung <[email-masked]>
Subject: Re: [Tm-rid] Proposed WG Charter v2

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

Civil Aviation Authorities (CAAs) worldwide (e.g. United States Federal Aviation Administration, FAA), have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID).  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 here is ASTM International F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID and Tracking”.  ASTM Network RID defines a set of information for UAS to make available globally indirectly via the Internet. ASTM Broadcast RID defines a set of messages for Unmanned Aircraft (UA) to send locally directly one-way over Bluetooth or IEEE 802.11. WK65041 addresses neither how to ensure trustworthiness of RID information nor how to 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, balancing legitimate (e.g. public safety) authorities’ Need To Know trustworthy information with UAS operators’ privacy. To accomplish this, TM-RID will liaise with ASTM, CTA, ICAO, RTCA, et al 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. Other Technical Specification RFCs will address enhancements of specific supporting protocols. Prototypes using the contemplated technical approach have already been successfully flown.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is uniquely ideally suited to serving as an UAS ID Type. A  HIT, an Overlay Routable Cryptographic Hash Identifier (ORCHID), is derived from and compactly (as an IPv6 address) represents a Host Identity (HI), a [self-generated] public key. HITs can verifiably identify all entities in the UAS Traffic Management (UTM) ecosystem: UA, Ground Control Stations (GCS), observer devices, registries, etc. TM-RID will specify how to leverage HITs –

- Provide strong RID authentication by using the HI in public key operations to:
= prove ownership of the claimed ID (HIT);
= 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.

- Use DNS to enable observers to use a received HIT to look up minimal public ID information.

- Use access controlled RDAP to enable authorized observers to look up more extensive private information (including operator Personally Identifiable Information, PII) needed for legitimate (e.g. public safety or security) purposes from an Internet domain name (Whois) or similar registry.

This provides stronger privacy than other FAA Notice of Proposed Rulemaking (NPRM) / ASTM standard UAS ID Types, while providing greater assurance of authenticity to authorized observers, but necessitates several HIP enhancements –

- Hierarchical HIT (HHIT): Enable scalable and trustable UA registration and information retrieval (e.g. with DNS and RDAP) by adding optional structure to the (currently flat) HIT/ORCHID space.

- registration extensions:  Prevent registration of duplicate HHITs, populate registries with IDs and associated data, update DNS, support Rendez-Vous Servers (RVS) and provide proof of authenticity.

- proxies: Enable any party observing an UA to contact a RVS or other intermediary that will either deny or facilitate secure communications with the party controlling the UA, while maintaining the privacy of the latter’s identity, location and other information to all but authorized parties, per policy.

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

- new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed for severely constrained [UAS] environments.

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. TM-RID enhancements to HIP will be generic: of these, only HHITs with their associated registration procedures and compact crypto are vital to support UAS RID; HIP proxies and HIP multicast are stretch goals. Some UTM concepts envision using OAuth for GCS and personnel; HIP as an OAuth method also will be investigated. The Applicability Statement and the Technical Specifications initially essential for UAS RID will be published within one year of the 2019 DEC 31 FAA NPRM.

On Mon, Dec 2, 2019 at 12:31 PM Card, Stu <[email-masked]<mailto:[email-masked]>> wrote:
I will try wordsmithing this week.

On Mon, Dec 2, 2019, 09:04 Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

I am enthusiatic about this work, although I don't anticipate being able to
be more than a bystandard on this.

Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:
    > TM-RID will build upon the Host Identity Tag (HIT) from the Host Identity
    > Protocol (HIP) as an RID and augment it and supporting HIP and other IETF

    > The goal is
    > to provide trustworthiness both in an Internet connected environment and
    > emergency, unconnected situations within the highly constrained environment
    > of UAS.

I think that a reference for the nature of the constrained environment might
be in order.

    > The Host Identity Tag (HIT) is ideally, in fact uniquely, suited to work
    > within this RID effort.  The Host Identity (HI) behind the HIT can be used to
    > sign Broadcast Authentication Messages, thus proving ownership of the RID
    > (HIT) and signed messages.  HITs provide significantly superior privacy
    > compared to other allowed RID types while providing greater assurance to
    > authorized observers that they are accessing the proper PII for the UA.

This wanders into solution space, and I think it would be better to omit this.

    > TM-RID will create specifications for HIP-augmented ASTM RID messages..
    > Initially this will consist of additional RID Authentication Messages that
    > use the HI in public key signing operations: to prove UAS ownership of a
    > Hierarchical HIT (HHIT); to authenticate other claims made via RID, such as
    > position and velocity, as having been made by the owner of that HHIT; and to

TM-RID will create specifications to prove UAS ownership of a
Hierarchical HIT (HHIT); providing a framework to authenticate other claims, such as
position and velocity, as having been made by the owner of that HHIT; and to
provide observers lacking current Internet connectivity with locally
verifiable UAS proof-of-registration objects.

    > For this, HIP would be amended to be used effectively in this environment:

I think you could put a period instead of : and omit the next three paragraphs.

    > HHITs are envisioned to identify all components in the UAS/UTM (UAS Traffic
    > Registries.  This will entail further work as experience is gained in using
    > HIP for UAS RID.  For example, some (UTM) systems envision using OAuth for
    > Ground Control Systems (GCS) and authorized safety personnel.  HIP as an

    > The workgroup will need to liaison with the various SDOs working in the UAS
    > regulation space.

Please if you could list those SDOs?
Do we need to do liason agreements with them?  I would be happier if that was
part of the plan.

How will we engage with implementers?  I.e. how are we going to get running-code?

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Jan 2020 12:00:04 -0500

> Aircraft Systems (UAS) Remote Identification (RID). 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 here is ASTM International F38 Committee Work
    > Item WK65041, “Standard Specification for UAS Remote ID and Tracking”. ASTM
    > Network RID defines a set of information for UAS to make available globally
    > indirectly via the Internet. ASTM Broadcast RID defines a set of messages for
    > Unmanned Aircraft (UA) to send locally directly one-way over Bluetooth or
    > IEEE 802.11. WK65041 addresses neither how to ensure trustworthiness of RID
    > information nor how to make it instantly useful.

    > TM-RID’s goal is to make RID immediately actionable, in both Internet and
    > authorities’ Need To Know trustworthy information with UAS operators’
    > privacy. To accomplish this, TM-RID will liaise with ASTM, CTA, ICAO, RTCA,
    > et al 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.
    > Other Technical Specification RFCs will address enhancements of specific
    > supporting protocols. Prototypes using the contemplated technical approach
    > have already been successfully flown.

I'm good up to here.

At this point, you are getting into solution space and requirements.

    > - Use access controlled RDAP to enable authorized observers to look up

Probably need to include a pointer to a glossary of acronyms, both for IETF
people to understsand ASTM,CTA,ICOA, and VV.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 10 Jan 2020 10:01:08 +0000

Stu, Adam, Bob and other,

The clock is starting to click towards IETF-107 and it takes several weeks to create a WG. In short, it becomes really important that the TM-RID community rally around a draft charter that can be reviewed by the IESG as a first step. IMHO, the v2 will have difficulties to go through the evaluation if my comments below are not taken into account.

Regards

-éric

From: Eric Vyncke <[email-masked]>
Date: Friday, 3 January 2020 at 17:34
To: "Card, Stu" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: ryoung <[email-masked]>
Subject: Re: [Tm-rid] Proposed WG Charter v2

Happy New Year all

Citing the existing Internet drafts is also typical in a charter.

To be direct, I am afraid that statement like “HIP HIT is uniquely ideally suited to serving as an UAS ID Type” will NOT attract consensus in a charter. I would suggest to have a work item to check the adequacy of HIP to the problem statement than trying to defend this assumption in the charter itself.

-eric

---

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

I will have a V4 draft charter out today, addressing all comments received.

On Fri, Jan 10, 2020, 05:01 Eric Vyncke (evyncke) <[email-masked]> wrote:

> The clock is starting to click towards IETF-107 and it takes several weeks
> to create a WG. In short, it becomes really important that the TM-RID
> community rally around a draft charter that can be reviewed by the IESG as
> a first step. IMHO, the v2 will have difficulties to go through the
> evaluation if my comments below are not taken into account.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Eric Vyncke <[email-masked]>
> *Date: *Friday, 3 January 2020 at 17:34
> *To: *"Card, Stu" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *ryoung <[email-masked]>
> *Subject: *Re: [Tm-rid] Proposed WG Charter v2
>
>
>
> Happy New Year all
>
>
>
> This TM-RID community needs to work more and faster around this
> chartering. A liaison statement from FAA or other CAA or ICAO or ASTM (not
> exclusive) on this work could also help a lot.
>
>
>
> About the charter itself, it is difficult to parse as there are many
> acronyms + their expansion. Unsure how to solve this issue though (except
> like this trick[1]).
>
>
>
> The charter flow does not follow the usual one. E.g., it would benefit a
> lot of clearly identifying the work items (or at least clearly the WG
> scope). Having milestones (i.e. dates) is also helpful for chartering a WG,
> milestones are outside of the charter itself but can be enumerated, for
> now, as bullets after the charter.
>
>
>
> To be direct, I am afraid that statement like “HIP HIT is uniquely ideally
> suited to serving as an UAS ID Type” will NOT attract consensus in a
> charter. I would suggest to have a work item to check the adequacy of HIP
> to the problem statement than trying to defend this assumption in the
> charter itself.
>
>
>
> *From: *Tm-rid <[email-masked]> on behalf of "Card, Stu" <
> [email-masked]>
> *Date: *Thursday, 2 January 2020 at 23:01
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *ryoung <[email-masked]>
> *Subject: *Re: [Tm-rid] Proposed WG Charter v2
>
>
>
> TM-RID’s goal is to make RID *immediately actionable*, in both Internet
> and local-only connected scenarios, especially emergencies, in severely
> - Use access controlled RDAP to enable authorized observers to look up
> more extensive private information (including operator Personally
> Identifiable Information, PII) needed for legitimate (e.g. public safety or
> security) purposes from an Internet domain name (Whois) or similar registry.
>
>
>
> This provides stronger privacy than other FAA Notice of Proposed
> Rulemaking (NPRM) / ASTM standard UAS ID Types, while providing greater
> assurance of authenticity to authorized observers, but necessitates several
> HIP enhancements –
>
>
>
> - new cryptographic algorithms: Extremely compact keys and signatures
> (such as are enabled by EdDSA and Keccak functions) are needed for severely