[Tm-rid] Proposed WG Charter v2
Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 27 November 2019 21:28 UTC
Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7F120A79 for <tm-rid@ietfa.amsl.com>; Wed, 27 Nov 2019 13:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QWJhgR-ALoA for <tm-rid@ietfa.amsl.com>; Wed, 27 Nov 2019 13:28:37 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5549F120ABA for <tm-rid@ietf.org>; Wed, 27 Nov 2019 13:28:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B53126211A for <tm-rid@ietf.org>; Wed, 27 Nov 2019 16:28:35 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W295K6kAMk6f for <tm-rid@ietf.org>; Wed, 27 Nov 2019 16:28:27 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0B74262117 for <tm-rid@ietf.org>; Wed, 27 Nov 2019 16:28:27 -0500 (EST)
From: Robert Moskowitz <rgm@labs.htt-consult.com>
To: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <579d29aa-e3d7-9886-91b6-46641eb1f944@labs.htt-consult.com>
Message-ID: <5feb3288-b366-3580-0b1d-1134769bb305@labs.htt-consult.com>
Date: Wed, 27 Nov 2019 16:28:19 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <579d29aa-e3d7-9886-91b6-46641eb1f944@labs.htt-consult.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/XPKS7zzP7v6icQIc22ZJ2W8ngNs>
Subject: [Tm-rid] Proposed WG Charter v2
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 21:28:40 -0000
I have expanded the end of the charter. Don't think I have it yet. There is PKI buried in here. The ICAO seems to expect everything to work via certs, and for parts of the environment that does make sense. Bootstrapping the PKI via HHITs could be a way to meet in the middle, so to speak. I have this in part in the current Registry draft, but it is not yet clear in the charter. Plus this is TMRID, and I am dipping into aspects of USS here. Where does the workgroup stop? Anyway, comments and writing help! ============================================== Trustworthy Multipurpose Remote Identification (TM-RID) Proposed WG Governmental agencies worldwide, including the United States Federal Aviation Administration (FAA), are embarking on rule making processes to define Remote Identification (RID) requirements for Unmanned Aircraft Systems (UAS). ASTM International (formerly the American Society for Testing and Materials) F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID and Tracking”, addresses such anticipated requirements. Broadcast RID defines a set of messages for UAS to send one-way over Bluetooth or IEEE 802.11. Network RID defines how the same information (and potentially more) can be made available via the Internet. The ASTM draft does not address how to ensure or at least assess trustworthiness of information communicated via RID. 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. The goal is to provide trustworthiness both in an Internet connected environment and emergency, unconnected situations within the highly constrained environment of UAS. 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. 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. For this, HIP would be amended to be used effectively in this environment: - Hierarchical HITs (HHIT) enabling scalable and trustable UA registration and information retrieval: HHIT was part of the original design of HIP, but was dropped for lack of a clear use case. RID messages containing HHITs will enable use of DNS and potentially RDAP to access information about the UAS. - expanded HIP Registration for HHITs: This registration process will provide proof of authenticity and prevent duplicate HHITs from occurring. Further, these Registries will provide the UAS DNS information and other services (e.g. RDAP and support of RVS for Network RID and related applications). - new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed to meet the severely constrained UAS environment. 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. The goal is to complete these updates to HIP and publish the TMRID RFCs by the end of 2020.
- [Tm-rid] Proposed WG Charter Robert Moskowitz
- [Tm-rid] Proposed WG Charter v2 Robert Moskowitz
- Re: [Tm-rid] Proposed WG Charter v2 Michael Richardson
- Re: [Tm-rid] Proposed WG Charter v2 Card, Stu
- Re: [Tm-rid] Proposed WG Charter v2 Card, Stu
- Re: [Tm-rid] Proposed WG Charter v2 Eric Vyncke (evyncke)
- Re: [Tm-rid] Proposed WG Charter v2 Michael Richardson
- Re: [Tm-rid] Proposed WG Charter v2 Eric Vyncke (evyncke)
- Re: [Tm-rid] Proposed WG Charter v2 Card, Stu