idnits 2.17.1 draft-card-drip-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 March 2020) is 1493 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-04 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP S. Card 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 25 September 2020 R. Moskowitz 6 HTT Consulting 7 24 March 2020 9 Drone Remote Identification Protocol (DRIP) Architecture 10 draft-card-drip-arch-01 12 Abstract 14 This document defines an architecture for Drone Remote Identification 15 Protocol (DRIP) Working Group protocols and services to support 16 Unmanned Aircraft System Remote Identification (UAS RID), including 17 its building blocks and their interfaces, all to be standardized. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 25 September 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 55 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Entities and their Interfaces . . . . . . . . . . . . . . . . 8 57 3.1. Private Information Registry . . . . . . . . . . . . . . 9 58 3.2. Public Information Registry . . . . . . . . . . . . . . . 9 59 3.3. CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.4. CS-RID Finder . . . . . . . . . . . . . . . . . . . . . . 10 61 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 9.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Many safety and other considerations dictate that UAS be remotely 74 identifiable. Civil Aviation Authorities (CAAs) worldwide are 75 mandating UAS RID. The European Union Aviation Safety Agency (EASA) 76 has published [Delegated] and [Implementing] Regulations. The United 77 States (US) Federal Aviation Administration (FAA) has published a 78 Notice of Proposed Rule Making ([NPRM]). CAAs currently promulgate 79 performance-based regulations that do not specify techniques, but 80 rather cite industry consensus technical standards as acceptable 81 means of compliance. 83 ASTM International, Technical Committee F38 (UAS), Subcommittee 84 F38.02 (Aircraft Operations), Work Item WK65041, developed new ASTM 85 F3411-19 [F3411-19] Standard Specification for Remote ID and 86 Tracking. It defines 2 means of UAS RID. Network RID defines a set 87 of information for UAS to make available globally indirectly via the 88 Internet. Broadcast RID defines a set of messages for Unmanned 89 Aircraft (UA) to transmit locally directly one-way over Bluetooth or 90 Wi-Fi. Network RID depends upon Internet connectivity, in several 91 segments, from the UAS to the observer. Broadcast RID should need 92 Internet (or other Wide Area Network) connectivity only for UAS 93 registry information lookup using the directly locally received UAS 94 ID as a key. 96 [F3411-19] specifies 3 UAS ID types. Type 1 is a static, 97 manufacturer assigned, hardware serial number per ANSI/CTA-2063-A 98 "Small Unmanned Aerial System Serial Numbers" [CTA2063A]. Type 2 is 99 a CAA assigned (presumably static) ID. Type 3 is a UAS Traffic 100 Management (UTM) system assigned UUID [RFC4122], which can but need 101 not be dynamic. The EU allows only Type 1; the US allows Types 1 and 102 3, but requires Type 3 IDs (if used) each to be used only once. 103 [F3411-19] Broadcast RID transmits all information in the clear as 104 plaintext, so Type 1 static IDs enable trivial correlation of 105 patterns of use, unacceptable in many applications, e.g. package 106 delivery routes of competitors. 108 An ID is not an end in itself; it exists to enable lookups and 109 provision of services complementing mere identification. 111 Minimal specified information must be made available to the public; 112 access to other data, e.g. UAS operator Personally Identifiable 113 Information (PII), must be limited to strongly authenticated 114 personnel, properly authorized per policy. [F3411-19] specifies only 115 how to get the UAS ID to the observer; how the observer can perform 116 these lookups, and how the registries first can be populated with 117 information, is unspecified. 119 Although using UAS RID to facilitate related services, such as Detect 120 And Avoid (DAA) and other applications of Vehicle to Vehicle or 121 Vehicle to Infrastructure (V2V, V2I, collectively V2X) 122 communications, is an obvious application (explicitly contemplated in 123 the FAA NPRM), it has been omitted from [F3411-19] (explicitly 124 declared out of scope in the ASTM working group discussions based on 125 a distinction between RID as a security standard vs DAA as a safety 126 application). Although dynamic establishment of secure 127 communications between the observer and the UAS pilot seems to have 128 been contemplated by the FAA UAS ID and Tracking Aviation Rulemaking 129 Committee (ARC) in their [Recommendations], it is not addressed in 130 any of the subsequent proposed regulations or technical 131 specifications. 133 The need for near-universal deployment of UAS RID is pressing. This 134 implies the need to support use by observers of already ubiquitous 135 mobile devices (smartphones and tablets). UA onboard RID devices are 136 severely constrained in Size, Weight and Power (SWaP). Cost is a 137 significant impediment to the necessary near-universal adoption of 138 UAS send and observer receive RID capabilities. To accommodate the 139 most severely constrained cases, all these conspire to motivate 140 system design decisions, especially for the Broadcast RID data link, 141 which complicate the protocol design problem: one-way links; 142 extremely short packets; and Internet-disconnected operation of UA 143 onboard devices. Internet-disconnected operation of observer devices 144 has been deemed by ASTM F38.02 too infrequent to address, but for 145 some users is important and presents further challenges. Heavyweight 146 security protocols are infeasible, yet trustworthiness of UAS RID 147 information is essential. Under [F3411-19], even the most basic 148 datum, the UAS ID string (typically number) itself can be merely an 149 unsubstantiated claim. 151 IETF can help by providing expertise as well as mature and evolving 152 standards. Existing Internet resources (business models, 153 infrastructure and protocol standards) should be leveraged. Host 154 Identity Protocol (HIPv2) [RFC7401] and its Domain Name System (DNS) 155 extensions [RFC8005], together with the Registry Data Access Protocol 156 (RDAP) and the Extensible Provisioning Protocol (EPP), can complement 157 emerging external standards for UAS RID. This will facilitate 158 utilization of existing and provision of enhanced network services, 159 and enable verification that UAS RID information is trustworthy (to 160 some extent, even in the absence of Internet connectivity at the 161 receiving node). The natural Internet architecture for DRIP 162 described herein addresses requirements defined in a companion DRIP 163 Requirements document. 165 2. Terms and Definitions 167 2.1. Requirements Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 2.2. Definitions 177 $SWaP 178 Cost, Size, Weight and Power. 180 AAA 181 Attestation, Authentication, Authorization, Access Control, 182 Accounting, Attribution, Audit. 184 ABDAA 185 AirBorne DAA. Also known as "self-separation". 187 AGL 188 Above Ground Level. Relative altitude, above the variously 189 defined local ground level, typically of an UA, typically measured 190 in feet. 192 CAA 193 Civil Aviation Authority. An example is the Federal Aviation 194 Administration (FAA) in the United States of America. 196 C2 197 Command and Control. A set of organizational and technical 198 attributes and processes that employs human, physical, and 199 information resources to solve problems and accomplish missions. 200 Mainly used in military contexts. 202 CS-RID 203 Crowd Sourced Remote Identification. An optional DRIP WG service 204 that gateways Broadcast RID to Network RID, and supports 205 verification of RID positon/velocity claims with independent 206 measurements (e.g. by multilateration), via a SDSP. 208 DAA 209 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 210 keeping aircraft "well clear" of each other for safety. 212 E2E 213 End to End. 215 GBDAA 216 Ground Based DAA. 218 GCS 219 Ground Control Station. The part of the UAS that the remote pilot 220 uses to exercise C2 over the UA, whether by remotely exercising UA 221 flight controls to fly the UA, by setting GPS waypoints, or 222 otherwise directing its flight. 224 GPS 225 Global Positioning System. In this context, misused in place of 226 Global Navigation Satellite System (GNSS) or more generally SATNAV 227 to refer generically to satellite based timing and/or positioning. 229 HI 230 Host Identity. The public key portion of an asymmetric keypair 231 from HIP. In this document it is assumed that the HI is based on 232 an EdDSA25519 keypair. This is supported by new crypto defined in 233 [I-D.moskowitz-hip-new-crypto]. 235 HIP 236 Host Identity Protocol. The origin of HI, HIT, and HHIT, required 237 for DRIP. Optional full use of HIP enables additional DRIP 238 functionality. 240 HHIT 241 Hierarchical Host Identity Tag. A HIT with extra information not 242 found in a standard HIT. Defined in 243 [I-D.moskowitz-hip-hierarchical-hit]. 245 HIT 246 Host Identity Tag. A 128 bit handle on the HI. Defined in HIPv2 247 [RFC7401]. 249 Limited RID 250 Per the FAA NPRM, a mode of operation that must use Network RID, 251 must not use Broadcast RID, and must provide pilot/GCS location 252 only (not UA location). This mode is only allowed for UA that 253 neither require (due to e.g. size) nor are equipped for Standard 254 RID, operated within V-LOS and within 400 feet of the pilot, below 255 400 feet AGL, etc. 257 LOS 258 Line Of Sight. An adjectival phrase describing any information 259 transfer that travels in a nearly straight line (e.g. 260 electromagnetic energy, whether in the visual light, RF or other 261 frequency range) and is subject to blockage. A term to be avoided 262 due to ambiguity, in this context, between RF-LOS and V-LOS. 264 MSL 265 Mean Sea Level. Relative altitude, above the variously defined 266 mean sea level, typically of an UA (but in FAA NPRM Limited RID 267 for a GCS), typically measured in feet. 269 NETDP 270 UAS RID Display Provider. System component that requests data 271 from one or more NETSP and aggregates them to display to a user 272 application on a device. Often an USS. 274 NETSP 275 UAS RID Service Provider. System component that compiles 276 information from various sources (and methods) in its given 277 service area. Usually an USS. 279 Observer 280 Referred to in other UAS RID documents as a "user", but there are 281 also other classes of UAS RID users, so we prefer "observer" to 282 denote an individual who has observed an UA and wishes to know 283 something about it, starting with its ID. 285 PII 286 Personally Identifiable Information. In this context, typically 287 of the UAS operator, Pilot In Command (PIC) or remote pilot, but 288 possibly of an observer or other party. 290 RF 291 Radio Frequency. May be used as an adjective or as a noun; in the 292 latter case, typically means Radio Frequency energy. 294 RF-LOS 295 RF LOS. Typically used in describing operation of a direct radio 296 link between a GCS and the UA under its control, potentially 297 subject to blockage by foliage, structures, terrain or other 298 vehicles, but less so than V-LOS. 300 SDSP 301 Supplemental Data Service Provider. Entity that provides data 302 allowed and presumed useful but neither required nor standardized 303 as an option in UTM, such as weather. Here used to enable CS-RID. 305 Standard RID 306 Per the FAA NPRM, a mode of operation that must use both Network 307 RID (if Internet connectivity is available at the time in the 308 operating area) and Broadcast RID (always and everywhere), and 309 must provide both pilot/GCS location and UA location. This mode 310 is required for UAS that exceed the allowed envelope (e.g. size, 311 range) of Limited RID and for all UAS equipped for Standard RID 312 (even if operated within parameters that would otherwise permit 313 Limited RID). 315 UA 316 Unmanned Aircraft. Typically a military or commercial "drone" but 317 can include any and all aircraft that are unmanned. 319 UAS 320 Unmanned Aircraft System. Composed of UA, all required on-board 321 subsystems, payload, control station, other required off-board 322 subsystems, any required launch and recovery equipment, all 323 required crew members, and C2 links between UA and control 324 station. 326 UAS ID 327 Unique UAS identifier. Per [F3411-19], maximum length of 20 328 bytes. 330 UAS ID Type 331 Identifier type index. Per [F3411-19], 4 bits, values 0-3 already 332 specified. 334 UAS RID 335 UAS Remote Identification. System for identifying UA during 336 flight by other parties. 338 UAS RID Verification Service 339 System component designed to handle the authentication 340 requirements of RID by offloading verification to a web hosted 341 service. 343 USS 344 UAS Service Supplier. Provide UTM services to support the UAS 345 community, to connect Operators and other entities to enable 346 information flow across the USS network, and to promote shared 347 situational awareness among UTM participants. (From FAA UTM 348 ConOps V1, May 2018). 350 UTM 351 UAS Traffic Management. A "traffic management" ecosystem for 352 "uncontrolled" UAS operations separate from, but complementary to, 353 the FAA's Air Traffic Management (ATM) system for "controlled" 354 operations of manned aircraft. 356 V-LOS 357 Visual LOS. Typically used in describing operation of an UA by a 358 "remote" pilot who can clearly directly (without video cameras or 359 any other aids other than glasses or under some rules binoculars) 360 see the UA and its immediate flight environment. Potentially 361 subject to blockage by foliage, structures, terrain or other 362 vehicles, more so than RF-LOS. 364 3. Entities and their Interfaces 366 Any DRIP WG solutions for UAS RID must fit into the UTM system. This 367 implies interaction with entities including UA, GCS, USS, NETSP, 368 NETDP, Observers, Operators, Pilots In Command, Remote Pilots, etc. 369 The only additional entities introduced by DRIP WG are registries, 370 required but not specified by the regulations and [RFC7401], and 371 optionally CS-RID SDSP and Finder nodes. 373 UAS RID registries hold both public and private information. The 374 public information is primarily pointers to the repositories of, and 375 keys for looking up, the private information. Given these different 376 uses, and to improve scalability, security and simplicity of 377 administration, the public and private information can be stored in 378 different registries, indeed different types of registry. 380 3.1. Private Information Registry 382 The private information required for UAS RID is similar to that 383 required for Internet domain name registration. This facilitates 384 leveraging existing Internet resources, including domain name 385 registration protocols, infrastructure and business models. This 386 implies a further derived requirement: a DRIP UAS ID MUST be amenable 387 to handling as an Internet domain name (at an arbitrary level in the 388 hierarchy), MUST be registered in at least a pseudo-domain (e.g. .ip6 389 for reverse lookup), and MAY be registered as a sub-domain (for 390 forward lookup). 392 A DRIP private information registry MUST support essential Internet 393 domain name registry operations (e.g. add, delete, update, query) 394 using interoperable open standard protocols. It SHOULD support the 395 Extensible Provisioning Protocol (EPP) and the Registry Data Access 396 Protocol (RDAP) with access controls. It MAY use XACML to specify 397 those access controls. It MUST be listed in a DNS: that DNS MAY be 398 private; but absent any compelling reasons for use of private DNS, 399 SHOULD be the definitive public Internet DNS hierarchy. The DRIP 400 private information registry in which a given UAS is registered MUST 401 be locatable, starting from the UAS ID, using the methods specified 402 in [RFC7484]. 404 3.2. Public Information Registry 406 The public information required to be made available by UAS RID is 407 transmitted as clear plaintext to local observers in Broadcast RID 408 and is served to a client by a NETDP in Network RID. Therefore, 409 while IETF can offer e.g. [RFC6280] as one way to implement Network 410 RID, the only public information required to support essential DRIP 411 functions for UAS RID is that required to look up Internet domain 412 hosts, services, etc. 414 A DRIP public information registry MUST be a standard DNS server, in 415 the definitive public Internet DNS hierarchy. It MUST support NS, 416 MX, SRV, TXT, AAAA, PTR, CNAME and HIP RR types. 418 3.3. CS-RID SDSP 420 A CS-RID SDSP MUST appear (i.e. present the same interface) to a 421 NETSP as a NETDP. A CS-RID SDSP MUST appear to a NETDP as a NETSP. 422 A CS-RID SDSP MUST NOT present a standard GCS-facing interface as if 423 it were a NETSP. A CS-RID SDSP MUST NOT present a standard client- 424 facing interface as if it were a NETDP. A CS-RID SDSP MUST present a 425 TBD interface to a CS-RID Finder; this interface SHOULD be based upon 426 but readily distinguishable from that between a GCS and a NETSP. 428 3.4. CS-RID Finder 430 A CS-RID Finder MUST present a TBD interface to a CS-RID SDSP; this 431 interface SHOULD be based upon but readily distinguishable from that 432 between a GCS and a NETSP. A CS-RID Finder must implement, integrate 433 or accept outputs from a Broadcast RID receiver. A CS-RID Finder 434 MUST NOT interface directly with a GCS, NETSP, NETDP or Network RID 435 client. 437 4. Identifiers 439 A DRIP UAS ID MUST be a HHIT. It SHOULD be self-generated by the UAS 440 (either UA or GCS) and MUST be registered with the Private 441 Information Registry identified in its hierarchy fields. Each UAS ID 442 HHIT MUST NOT be used more than once, with one exception as follows. 444 Each UA MAY be assigned, by its manufacturer, a single HI and derived 445 HHIT encoded as a hardware serial number per [CTA2063A]. Such a 446 static HHIT SHOULD be used only to bind one-time use UAS IDs (other 447 HHITs) to the unique UA. Depending upon implementation, this may 448 leave a HI private key in the possession of the manufacturer (see 449 Security Considerations). 451 Each UA equipped for Broadcast RID MUST be provisioned not only with 452 its HHIT but also with the HI public key from which the HHIT was 453 derived and the corresponding private key, to enable message 454 signature. Each UAS equipped for Network RID MUST be provisioned 455 likewise; the private key SHOULD reside only in the ultimate source 456 of Network RID messages (i.e. on the UA itself if the GCS is merely 457 relaying rather than sourcing Network RID messages). Each observer 458 device MUST be provisioned with public keys of the UAS RID root 459 registries and MAY be provisioned with public keys or certificates 460 for subordinate registries. 462 Operators and Private Information Registries MUST possess and other 463 UTM entities MAY possess UAS ID style HHITs. When present, such 464 HHITs SHOULD be used with HIP to strongly mutually authenticate and 465 optionally encrypt communications. 467 5. Transactions 469 Each Operator MUST generate a "HIo" and derived "HHITo", register 470 them with a Private Information Registry along with whatever Operator 471 data (inc. PII) is required by the cognizant CAA and the registry, 472 and obtain a certificate "Cro" signed with "HIr(priv)" proving such 473 registration. 475 To add an UA, an Operator MUST generate a "HIa" and derived "HHITa", 476 create a certificate "Coa" signed with "HIo(priv)" to associate the 477 UA with its Operator, register them with a Private Information 478 Registry along with whatever UAS data is required by the cognizant 479 CAA and the registry, obtain a certificate "Croa" signed with 480 "HIr(priv)" proving such registration, and obtain a certificate "Cra" 481 signed with "HIr(priv)" proving UA registration in that specific 482 registry while preserving Operator privacy. The operator then MUST 483 provision the UA with "HIa", "HIa(priv)", "HHITa" and "Cra". 485 UA engaging in Broadcast RID MUST use "HIa(priv)" to sign Auth 486 Messages and MUST periodically broadcast "Cra". UAS engaging in 487 Network RID MUST use "HIa(priv)" to sign Auth Messages. Observers 488 MUST use "HIa" from received "Cra" to verify received Broadcast RID 489 Auth messages. Observers without Internet connectivity MAY use "Cra" 490 to identify the trust class of the UAS based on known registry 491 vetting. Observers with Internet connectivity MAY use "HHITa" to 492 perform lookups in the Public Information Registry and MAY then query 493 the Private Information Registry, which MUST enforce access control 494 policy on Operator PII and other sensitive information. 496 6. IANA Considerations 498 It is likely that an IPv6 prefix will be needed for the HHIT (or 499 other identifier) space; this will be specified in other drafts. 501 7. Security Considerations 503 DRIP is all about safety and security, so content pertaining to such 504 is not limited to this section. The security provided by asymmetric 505 cryptographic techniques depends upon protection of the private keys. 506 A manufacturer that embeds a private key in an UA may have retained a 507 copy. A manufacturer whose UA are configured by a closed source 508 application on the GCS which communicates over the Internet with the 509 factory may be sending a copy of a UA or GCS self-generated key back 510 to the factory. Compromise of a registry private key could do 511 widespread harm. Key revocation procedures are as yet to be 512 determined. These risks are in addition to those involving Operator 513 key management practices. 515 8. Acknowledgments 517 The work of the FAA's UAS Identification and Tracking (UAS ID) 518 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 519 and proposed IETF DRIP WG efforts. The work of ASTM F38.02 in 520 balancing the interests of diverse stakeholders is essential to the 521 necessary rapid and widespread deployment of UAS RID. 523 9. References 525 9.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 533 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 534 RFC 7401, DOI 10.17487/RFC7401, April 2015, 535 . 537 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 538 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 539 2015, . 541 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 542 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 543 October 2016, . 545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 547 May 2017, . 549 9.2. Informative References 551 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 552 September 2019. 554 [Delegated] 555 European Union Aviation Safety Agency (EASA), "EU 556 Commission Delegated Regulation 2019/945 of 12 March 2019 557 on unmanned aircraft systems and on third-country 558 operators of unmanned aircraft systems", March 2019. 560 [F3411-19] ASTM, "Standard Specification for Remote ID and Tracking", 561 December 2019. 563 [I-D.moskowitz-hip-hierarchical-hit] 564 Moskowitz, R., Card, S., and A. Wiethuechter, 565 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 566 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 567 2020, . 570 [I-D.moskowitz-hip-new-crypto] 571 Moskowitz, R., Card, S., and A. Wiethuechter, "New 572 Cryptographic Algorithms for HIP", Work in Progress, 573 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 574 January 2020, . 577 [Implementing] 578 European Union Aviation Safety Agency (EASA), "EU 579 Commission Implementing Regulation 2019/947 of 24 May 2019 580 on the rules and procedures for the operation of unmanned 581 aircraft", May 2019. 583 [NPRM] United States Federal Aviation Administration (FAA), 584 "Notice of Proposed Rule Making on Remote Identification 585 of Unmanned Aircraft Systems", December 2019. 587 [Recommendations] 588 FAA UAS Identification and Tracking Aviation Rulemaking 589 Committee, "UAS ID and Tracking ARC Recommendations Final 590 Report", September 2017. 592 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 593 Unique IDentifier (UUID) URN Namespace", RFC 4122, 594 DOI 10.17487/RFC4122, July 2005, 595 . 597 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 598 Tschofenig, H., and H. Schulzrinne, "An Architecture for 599 Location and Location Privacy in Internet Applications", 600 BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, 601 . 603 Authors' Addresses 605 Stuart W. Card 606 AX Enterprize 607 4947 Commercial Drive 608 Yorkville, NY 13495 609 United States of America 611 Email: stu.card@axenterprize.com 613 Adam Wiethuechter 614 AX Enterprize 615 4947 Commercial Drive 616 Yorkville, NY 13495 617 United States of America 619 Email: adam.wiethuechter@axenterprize.com 621 Robert Moskowitz 622 HTT Consulting 623 Oak Park, MI 48237 624 United States of America 626 Email: rgm@labs.htt-consult.com