idnits 2.17.1 draft-wiethuechter-drip-identity-claims-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HIP RR' is mentioned on line 543, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'F3411-19' ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 drip Working Group A. Wiethuechter 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize, LLC 5 Expires: 6 May 2021 R. Moskowitz 6 HTT Consulting 7 2 November 2020 9 DRIP Identity Claims 10 draft-wiethuechter-drip-identity-claims-03 12 Abstract 14 This document describes the Identity Proofs (in the form of Claims, 15 Certificates and Attestations) for use in various Drone Remote ID 16 Protocols (DRIP) and the wider Unmanned Traffic Management (UTM) 17 system. 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 6 May 2021. 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 1.1. Claims, Assertions, Attestations, and Certificates . . . 2 54 1.1.1. Claims . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1.2. Assertions . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.3. Attestations . . . . . . . . . . . . . . . . . . . . 3 57 1.1.4. Certificates . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 3 60 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. DRIP Proofs . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Certificate: X on X (Cxx Form) . . . . . . . . . . . . . 4 63 3.1.1. Certificate: X on X (Short Form) . . . . . . . . . . 6 64 3.2. Attestation: X on Y (Axy Form) . . . . . . . . . . . . . 6 65 3.2.1. Attestation: X on Y (Short Form) . . . . . . . . . . 8 66 3.2.2. Attestation: X on Y (Offline Form) . . . . . . . . . 9 67 3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.4. Signatures . . . . . . . . . . . . . . . . . . . . . . . 11 69 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. HHIT Delegation . . . . . . . . . . . . . . . . . . . . . 11 71 4.2. Manufacturer . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. Registry . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Operator . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.5. Aircraft . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.5.1. Standard Provisioning . . . . . . . . . . . . . . . . 14 76 4.5.2. Operator Assisted Provisioning . . . . . . . . . . . 16 77 4.5.3. Initial Provisioning . . . . . . . . . . . . . . . . 18 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 6.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 DRIP Proofs are the backbone of trust in DRIP UAS RID, consisting of 87 a chain of special certificates/attestations that results in a 88 something useful in Broadcast RID. Some of the certificates are 89 stored in and are generated by the Registries (defined in 90 [hhit-registries]) and allow a user to confirm the trustworthiness of 91 an Unmanned Aircraft (herein referred to as Aircraft) even in the 92 scenario that the Observer is disconnected from the Internet. 94 1.1. Claims, Assertions, Attestations, and Certificates 96 The authors wish to make a clear distinction on exactly what these 97 terms mean in the context of DRIP. 99 This is due to the term "certificate" having significant technologic 100 and legal baggage associated with it, specifically around X.509 101 certificates. These type of certificates and Public Key 102 Infrastructure invokes more legal and public policy considerations 103 than probably any other electronic communication sector. It emerged 104 as a governmental platform for trusted identity management and was 105 pursued in intergovernmental bodies with links into treaty 106 instruments. 108 As such much discussion has been made around the terms being used. 110 1.1.1. Claims 112 For DRIP claims are used in the form of a predicate (X is Y, X has 113 property Y, and most importantly X owns Y). The basic form of a 114 claim is an entity using a HHIT as an identifier in the DRIP UAS 115 system. 117 1.1.2. Assertions 119 Assertions, under DRIP, are defined as being a set of one or more 120 claims. This definition is borrowed from JWT/CWT. An HHIT in of 121 itself is a set of assertions. First that the identifier is unique 122 and is a handle to an asymmetric keypair owned by the entity and that 123 it also is part of the given registry (specified by the HID). 125 1.1.3. Attestations 127 An attestation is a signed claim. The signee may be the claimant 128 themselves or a third party. Under DRIP this is normally used when a 129 set of entities asserts a relationship between them along with other 130 information. 132 1.1.4. Certificates 134 Certificates in DRIP have a narrow definition of being signed 135 exclusively by a third party and are only over identities. 137 2. Terminology 139 2.1. Required Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2.2. Definitions 149 See [drip-requirements] for common DRIP terms. 151 HDA: Hierarchial HIT Domain Authority. The 16 bit field identifying 152 the HIT Domain Authority under a RAA. 154 HID: Hierarchy ID. The 32 bit field providing the HIT Hierarchy ID. 156 RAA: Registered Assigning Authority. The 16 bit field identifying 157 the Hierarchical HIT Assigning Authority. 159 3. DRIP Proofs 161 The DRIP Proofs is a set of custom structures to be used in the USS/ 162 UTM system. They are created during the provision of an Aircraft and 163 are tied to the UAS ID (expected to be a HHIT, see [drip-rid] for 164 details). 166 These structures when chained together can create a root of trust all 167 the way back to the manufacturer itself during the initial production 168 of a given Aircraft. The chain can also be used by authorized 169 entities to trace an Aircraft through all owners and flights in the 170 Aircraft's lifetime (something of interest to ICAO). 172 The rest of this section will define the formats of proofs in DRIP as 173 forms of certificates and attestations and their common uses. 175 3.1. Certificate: X on X (Cxx Form) 177 The Cxx Form of DRIP Proofs is a self-signed certificate (by an 178 entity known as 'X') staking an unverified claim on a HHIT/HI pairing 179 until an expiration date/time. 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +---------------+---------------+---------------+---------------+ 184 | | 185 | Hierarchical | 186 | Host Identity Tag | 187 | | 188 +---------------+---------------+---------------+---------------+ 189 | | 190 | | 191 | | 192 | Host | 193 | Identity | 194 | | 195 | | 196 | | 197 +---------------+---------------+---------------+---------------+ 198 | Expiration Timestamp | 199 +---------------+---------------+---------------+---------------+ 200 | | 201 | | 202 | | 203 | | 204 | | 205 | | 206 | | 207 | Signature | 208 | | 209 | | 210 | | 211 | | 212 | | 213 | | 214 | | 215 | | 216 +---------------+---------------+---------------+---------------+ 218 Figure 1: Certificate: X on X 220 Certificates of the Cxx Form are 116 bytes. The offset of the 221 Expiration Timestamp SHOULD be of significant length (possibly 222 years). 224 These are 5 (five) Cxx Certificates that can be created in a standard 225 DRIP UAS RID system: Manufacturer on Manufacturer, RAA on RAA, HDA on 226 HDA (Registry on Registry), Operator on Operator, and Aircraft on 227 Aircraft. This is not an exhaustive list as any entity with the DRIP 228 UAS system SHOULD have a Cxx for itself. 230 3.1.1. Certificate: X on X (Short Form) 232 A smaller version of Certificate: X on X exists where the Host 233 Identity is removed allowing a claim to be made in 84 bytes. 235 0 1 2 3 236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 237 +---------------+---------------+---------------+---------------+ 238 | | 239 | Hierarchical | 240 | Host Identity Tag | 241 | | 242 +---------------+---------------+---------------+---------------+ 243 | Expiration Timestamp | 244 +---------------+---------------+---------------+---------------+ 245 | | 246 | | 247 | | 248 | | 249 | | 250 | | 251 | | 252 | Signature | 253 | | 254 | | 255 | | 256 | | 257 | | 258 | | 259 | | 260 | | 261 +---------------+---------------+---------------+---------------+ 263 Figure 2: Certificate: X on X (Short Form) 265 3.2. Attestation: X on Y (Axy Form) 267 This DRIP Proof is an attestation where Entity X asserts trust in the 268 binding claimed by Entity Y (in Cyy) and signs this asserting with a 269 timestamp and an expiration of when the binding is no longer asserted 270 by Entity X. 272 0 1 2 3 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 274 +---------------+---------------+---------------+---------------+ 275 | | 276 . . 277 . Cxx . 278 . . 279 | | 280 +---------------+---------------+---------------+---------------+ 281 | | 282 . . 283 . Cyy . 284 . . 285 | | 286 +---------------+---------------+---------------+---------------+ 287 | Timestamp | 288 +---------------+---------------+---------------+---------------+ 289 | Expiration Timestamp | 290 +---------------+---------------+---------------+---------------+ 291 | | 292 | | 293 | | 294 | | 295 | | 296 | | 297 | | 298 | Signature | 299 | | 300 | | 301 | | 302 | | 303 | | 304 | | 305 | | 306 | | 307 +---------------+---------------+---------------+---------------+ 309 Figure 3: Attestation: X on Y 311 Axy Form wraps both self-signed certificates of the entities and is 312 signed by Entity X. Two timestamps, one taken at the time of signing 313 and one as an expiration time are used to set boundaries to the 314 assertion. Care should be given to how far into the future the 315 Expiration Timestamp is set, but is left up to system policy. 317 Most attestations of this form have a length of 304 bytes. 318 Attestation: Registry on Operator on Aircraft is unique in that is 319 680 bytes long, binding of two Axy forms (in this specific case 320 Attestation: Registry on Operator with Attestation: Operator on 321 Aircraft). 323 3.2.1. Attestation: X on Y (Short Form) 325 0 1 2 3 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 327 +---------------+---------------+---------------+---------------+ 328 | | 329 | Hierarchical Host Identity Tag | 330 | of Entity X | 331 | | 332 +---------------+---------------+---------------+---------------+ 333 | | 334 . . 335 . Cyy . 336 . . 337 | | 338 +---------------+---------------+---------------+---------------+ 339 | Expiration Timestamp | 340 +---------------+---------------+---------------+---------------+ 341 | | 342 | | 343 | | 344 | | 345 | | 346 | | 347 | | 348 | Signature | 349 | | 350 | | 351 | | 352 | | 353 | | 354 | | 355 | | 356 | | 357 +---------------+---------------+---------------+---------------+ 359 Figure 4: Attestation: X on Y (Short Form) 361 The short form of the Axy this attestation is 200 bytes long and is 362 designed to fit inside the framing of the ASTM F3411 Authentication 363 Message. The HHIT of Entity X is used in place of the full Cxx (see 364 Section 5 for comments). The timestamp is removed and only an 365 expiration timestamp is present. 367 During creation the Expiration Timestamp MUST be no later than the 368 Expiration Timestamp found in Cyy. 370 3.2.2. Attestation: X on Y (Offline Form) 372 A special attestation that is the basis for a certificate finalized 373 onboard the aircraft during flight. It is used in Broadcast RID to 374 provide the trustworthiness of the Aircraft without the need of the 375 Observer to be connected to the Internet. 377 0 1 2 3 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 379 +---------------+---------------+---------------+---------------+ 380 | | 381 | Hierarchical Host Identity Tag | 382 | of Entity X | 383 | | 384 +---------------+---------------+---------------+---------------+ 385 | | 386 | Hierarchical Host Identity Tag | 387 | of Entity Y | 388 | | 389 +---------------+---------------+---------------+---------------+ 390 | | 391 | | 392 | | 393 | Host Identity of Entity Y | 394 | | 395 | | 396 | | 397 | | 398 +---------------+---------------+---------------+---------------+ 399 | Expiration Timestamp | 400 +---------------+---------------+---------------+---------------+ 401 | | 402 | | 403 | | 404 | | 405 | | 406 | | 407 | | 408 | Signature | 409 | | 410 | | 411 | | 412 | | 413 | | 414 | | 415 | | 416 | | 417 +---------------+---------------+---------------+---------------+ 419 Figure 5: Attestation: X on Y (Offline Form) 421 The signature is generated using Entity X's keypair. 423 3.3. Timestamps 425 Timestamps MAY be the standard UNIX time or a protocol specific 426 timestamp, to avoid programming complexities. For example [F3411-19] 427 uses a 00:00:00 01/01/2019 offset. When a Expiration Timestamp is 428 required a desired offset is added, setting the timestamp into the 429 future. The amount of offset for specific timestamps is left to best 430 practice. 432 3.4. Signatures 434 Signatures are ALWAYS taken over the preceding fields in the 435 certificate/attestation. For DRIP the EdDSA25519 algorithm from 436 [RFC8032] is used. 438 4. Provisioning 440 Under DRIP UAS RID a special provisioning procedure is required to 441 properly generate and distribute the certificates and attestations to 442 all parties in the USS/UTM ecosystem using DRIP RID. 444 Keypairs are expected to be generated on the device hardware it will 445 be used on. Due to hardware limitations (see Section 5) and 446 connectivity it is acceptable under DRIP RID to generate keypairs for 447 the Aircraft on Operator devices and later securely inject them into 448 the Aircraft (as defined in Section 4.5.2). The methods to securely 449 inject and store keypair information in a "secure element" of the 450 Aircraft is out of scope of this document. 452 4.1. HHIT Delegation 454 Under the FAA [NPRM], it is expecting that IDs for UAS are assigned 455 by the UTM and are generally one-time use. The methods for this 456 however are unspecified leaving two options. 458 1 The entity generates its own HHIT, discovering and using thr RAA 459 and HDA for the target Registry. The method for discovering a 460 Registry's RAA and HDA is out of scope here. This allows for the 461 device to generate an HHIT to send to the Registry to be accepted 462 (thus generating the required Host Identity Claim) or denied. 464 2 The entity sends to the Registry its HI for it to be hashed and 465 result in the HHIT. The Registry would then either accept 466 (returning the HHIT to the device) or deny this pairing. 468 In either case the Registry must decide on if the HI/HHIT pairing is 469 valid. This in its simplest form is checking the current Registry 470 for a collision on the HHIT. 472 Upon accepting a HI/HHIT pair the Registry MUST populate the required 473 the DNS serving the HDA with the HIP RR and other relevant RR types 474 (such as TXT and CERT). The Registry MUST also generate the 475 appropriate Host Identity Claim for the given operation. 477 If the Registry denied the HI/HHIT pair, because there was a HHIT 478 collision or any other reason, the Registry MUST signal back to the 479 device being provisioned that a new HI needs to be generated. 481 4.2. Manufacturer 483 +--------------+ Ca0a0 +-----------------+ 484 | Manufacturer | <--------> | Manufacturer CA | 485 +--------------+ Ama0 +-----------------+ 486 ^ | 487 | | 488 | | 489 Ca0a0 | | Ama0 490 | | 491 | v 492 +----------+ 493 | Aircraft | 494 +----------+ 496 During the initial configuration and production at the factory the 497 Aircraft MUST be configured to have a serial number. ASTM defines 498 this to be an ANSI/CTA-2063A. Under DRIP a HHIT can be encoded as 499 such to be able to convert back and forth between them. This is out 500 of scope for this document. 502 Under DRIP the Manufacturer SHOULD be using HHITs and have their own 503 keypair and Cxx (Certificate: Manufacturer on Manufacturer). (Ed. 504 Note: some words on aircraft keypair and certs here?). 506 Certificate: Aircraft 0 on Aircraft 0 (Ca0a0) is extracted by the 507 manufacturer and send to their Certificate Authority (CA) to be 508 verified and added. A resulting certificate (Attestation: 509 Manufacturer on Aircraft 0) SHOULD be a DRIP Attestation in the Axy 510 Form - however this could be a X.509 certificate binding the serial 511 number to the manufacturer. 513 4.3. Registry 515 TODO 517 DRIP UAS RID defines two levels of hierarchy maintained by the 518 Registration Assigning Authority (RAA) and HHIT Domain Authority 519 (HDA). The authors anticipate that an RAA is owned and operated by a 520 regional CAA (or a delegated party by an CAA in a specific airspace 521 region) with HDAs being contracted out. As such a chain of trust for 522 registries is required to ensure trustworthiness is not compromised. 523 More information on the registries can be found in [hhit-registries]. 525 Both the RAA and HDA generate their own keypairs and self-signed 526 certificates (Certificate: RAA on RAA and Certificate: HDA on HDA 527 respectively). The HDA sends to the RAA its self-signed certificate 528 to be added into the RAA DNS. 530 The RAA confirms the certificate received is valid and that no HHIT 531 collisions occur before added a HIP RR to its DNS for the new HDA. 532 An Attestation: RAA on HDA is sent as a confirmation that 533 provisioning was successful. 535 The HDA is now a valid "Registry" and uses its keypair and 536 Certificate: HDA on HDA with all provisioning requests from 537 downstream. 539 4.4. Operator 541 +----------+ +---------+ 542 | Registry | ---------> | HDA DNS | 543 +----------+ [HIP RR] +---------+ 544 ^ | 545 | | 546 | | 547 Coo | | Aro 548 | | 549 | v 550 +----------+ 551 | Operator | 552 +----------+ 554 The Operator generates a keypair and HHIT as specified in DRIP UAS 555 RID. A self-signed certificate (Certificate: Operator on Operator) 556 is generated and sent to the desired Registry (HDA). Other relevant 557 information and possibly personally identifiable information needed 558 may also be required to be sent to the Registry (all over a secure 559 channel - the method of which is out of scope for this document). 561 The Registry cross checks any personally identifiable information as 562 required. Certificate: Operator on Operator is verified (both using 563 the expiration timestamp and signature). The HHIT is searched in the 564 Registries database to confirm that no collision occurs. A new 565 attestation is generated (Attestation: Registry on Operator) and sent 566 securely back to the Operator. Optionally the HHIT/HI pairing can be 567 added to the Registries DNS in to form of a HIP Resource Record (RR). 569 Other RRs, such as CERT and TXT, may also be used to hold public 570 information. 572 With the receipt of Attestation: Registry on Operator the 573 provisioning of an Operator is complete. 575 4.5. Aircraft 577 4.5.1. Standard Provisioning 579 Under standard provisioning the Aircraft has its own connectivity to 580 the Registry, the method which is out of scope for this document. 582 +----------+ 583 | Registry | 584 +----------+ 585 ^ 586 | 587 | 588 | Cro, CoaN 589 | 590 | 591 +----------+ +----------+ 592 | Operator | <--------------------- | Aircraft | 593 +----------+ Ca0aN +----------+ 595 Figure 6: Standard Provision: Step 1 597 Through mechanisms not specified in this document the Aircraft should 598 have methods to instruct the Aircrafts onboard systems to generate a 599 keypair and certificate. This certificate is chained to the factory 600 provisioned certificate (Certificate: Aircraft 0 on Aircraft 0). 601 This new attestation (Attestation: Aircraft 0 on Aircraft N) is 602 securely extracted by the Operator. 604 With Attestation: Aircraft 0 on Aircraft N the sub certificate 605 (Certificate: Aircraft N on Aircraft N) is used by the Operator to 606 generate Attestation: Operator on Aircraft N. This along with 607 Attestation: Registry on Operator is sent to the Registry. 609 +----------+ 610 | Registry | 611 +----------+ 612 | 613 | 614 | 615 | Token 616 | 617 v 618 +----------+ +----------+ 619 | Operator | ---------------------> | Aircraft | 620 +----------+ Token +----------+ 622 Figure 7: Standard Provision: Step 2 624 On the Registry, Attestation: Registry on Operator is verified and 625 used as confirmation that the Operator is already registered. 626 Attestation: Operator on Aircraft N also undergoes a validation check 627 and used to generate a token to return to the Operator to continue 628 provisioning. 630 Upon receipt of this token, the Operator injects it into the Aircraft 631 and its used to form a secure connection to the Registry. The 632 Aircraft then sends Attestation: Manufacturer on Aircraft 0 and 633 Attestation: Aircraft 0 to Aircraft N. 635 +---------+ 636 | HDA DNS | 637 +---------+ 638 ^ 639 | 640 | HIP RR 641 | 642 | 643 | 644 +----------+ <----------------------------+ 645 | Registry | | 646 +----------+ ------------------------+ | 647 | | | 648 | | | Token, 649 | CroaN CraN | | Cma0, Ca0aN 650 | | | 651 | | | 652 v v | 653 +----------+ +----------+ 654 | Operator | | Aircraft | 655 +----------+ +----------+ 656 Figure 8: Standard Provision: Step 3 658 The Registry uses Attestation: Manufacturer on Aircraft 0 (with an 659 external database if supported) to confirm the validity of the 660 Aircraft. Attestation: Aircraft 0 on Aircraft N is correlated with 661 Attestation: Operator on Aircraft N and Attestation: Manufacturer on 662 Aircraft 0 to see the chain of ownership. The new HHIT tied to 663 Aircraft N is then checked for collisions in the HDA. With the 664 information the Registry generates two certificates: Attestation: 665 Registry on Operator on Aircraft N and Attestation: Registry on 666 Aircraft N (Offline Form). A HIP RR (and other RR types as needed) 667 are generated and inserted into the HDA. 669 Attestation: Registry on Operator on Aircraft N is sent via a secure 670 channel back to the Operator to be stored. Attestation: Registry on 671 Aircraft N (Offline Form) is sent to the Aircraft to be used in 672 Broadcast RID. 674 4.5.2. Operator Assisted Provisioning 676 This provisioning scheme is for when the Aircraft is unable to 677 connect to the Registry itself or does not have the hardware required 678 to generate keypairs and certificates. 680 +----------+ 681 | Registry | 682 +----------+ 684 +----------+ +----------+ 685 | Operator | ---------------------> | Aircraft | 686 +----------+ aN, CaNaN +----------+ 688 Figure 9: Operator Assisted Provision: Step 1 690 To start the Operator generates on behalf of the Aircraft a new 691 keypair and Certificate: Aircraft N on Aircraft N. This keypair and 692 certificate are injected into the Aircraft for it to generate 693 Attestation: Aircraft 0 on Aircraft N. After injecting the keypair 694 and certificate, the Operator MUST destroy all copies of the keypair. 696 +----------+ 697 | Registry | 698 +----------+ 699 ^ 700 | 701 | 702 | Cro, Cma0, Ca0aN, CoaN 703 | 704 | 705 +----------+ +----------+ 706 | Operator | <--------------------- | Aircraft | 707 +----------+ Cma0, Ca0aN +----------+ 709 Figure 10: Operator Assisted Provision: Step 2 711 Attestation: Manufacturer on Aircraft 0 and Attestation: Aircraft 0 712 on Aircraft N is extracted by the Operator and the following data 713 items are sent to the Registry; Attestation: Registry on Operator, 714 Attestation: Manufacturer on Aircraft 0, Attestation: Aircraft 0 on 715 Aircraft N, Attestation: Operator on Aircraft N. 717 +----------+ +---------+ 718 | Registry | ---------> | HDA DNS | 719 +----------+ HIP RR +---------+ 720 | 721 | 722 | 723 | CroaN, CraN 724 | 725 v 726 +----------+ +----------+ 727 | Operator | ---------------------> | Aircraft | 728 +----------+ CraN +----------+ 730 Figure 11: Operator Assisted Provision: Step 3 732 On the Registry validation checks are done on all attestations as per 733 the previous sections. Once complete then the Registry checks for a 734 HHIT collision, adding to the HDA if clear and generates Attestation: 735 Registry on Operator on Aircraft N and Attestation: Registry on 736 Aircraft N (Offline Form). Both are sent back to the Operator. 738 The Operator securely inject Attestation: Registry on Aircraft N 739 (Offline Form) and securely stores Attestation: Registry on Operator 740 on Aircraft N. 742 4.5.3. Initial Provisioning 744 A special form of provisioning is used when the Aircraft is first 745 sold to an Operator. Instead of generating a new keypair, the built 746 in keypair and certificate done by the Manufacturer is used to 747 provision and register the aircraft to the owner. 749 For this either Standard or Operator Assisted methods can be used. 751 5. Security Considerations 753 A major consideration is the optimization done in Attestation: X on Y 754 (Short Form) to get its length down to 200 bytes. The truncation of 755 Certificate: HDA on HDA down to just its HHIT is one that could be 756 used against the system to act as a false Registry. For this to 757 occur an attacker would need to find a hash collision on that 758 Registry HHIT and then manage to spoof all of DNS being used in the 759 system. 761 The authors believe that the probability of such an attack is low 762 when Registry operators are using best practices in security. If 763 such an attack can occur (especially in the time frame of "one-time 764 use IDs") then there are more serious issues present in the system. 766 6. References 768 6.1. Normative References 770 [F3411-19] "Standard Specification for Remote ID and Tracking", 771 February 2020. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 779 Signature Algorithm (EdDSA)", RFC 8032, 780 DOI 10.17487/RFC8032, January 2017, 781 . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 6.2. Informative References 789 [drip-requirements] 790 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 791 "Drone Remote Identification Protocol (DRIP) 792 Requirements", Work in Progress, Internet-Draft, draft- 793 ietf-drip-reqs-06, 1 November 2020, . 796 [drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 797 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 798 ietf-drip-uas-rid-01, 9 September 2020, 799 . 802 [hhit-registries] 803 Moskowitz, R., Card, S., and A. Wiethuechter, 804 "Hierarchical HIT Registries", Work in Progress, Internet- 805 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 806 2020, . 809 [NPRM] "Notice of Proposed Rule Making on Remote Identification 810 of Unmanned Aircraft Systems", December 2019. 812 Authors' Addresses 814 Adam Wiethuechter 815 AX Enterprize, LLC 816 4947 Commercial Drive 817 Yorkville, NY 13495 818 United States of America 820 Email: adam.wiethuechter@axenterprize.com 822 Stuart Card 823 AX Enterprize, LLC 824 4947 Commercial Drive 825 Yorkville, NY 13495 826 United States of America 828 Email: stu.card@axenterprize.com 830 Robert Moskowitz 831 HTT Consulting 832 Oak Park, MI 48237 833 United States of America 834 Email: rgm@labs.htt-consult.com