idnits 2.17.1 draft-wiethuechter-drip-identity-claims-02.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 (26 October 2020) is 1279 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 472, 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: 29 April 2021 R. Moskowitz 6 HTT Consulting 7 26 October 2020 9 DRIP Identity Claims 10 draft-wiethuechter-drip-identity-claims-02 12 Abstract 14 This document describes the Identity Claims or Certificates for use 15 in various Drone Remote ID Protocols (DRIP) and the wider Unmanned 16 Traffic Management (UTM) system. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 29 April 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Use of the word Certificate . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 3 55 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. DRIP Certificates . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Certificate: X on X (Cxx Form) . . . . . . . . . . . . . 4 58 3.1.1. Certificate: X on X (Short Form) . . . . . . . . . . 5 59 3.2. Certificate: X on Y (Cxy Form) . . . . . . . . . . . . . 6 60 3.2.1. Certificate: X on Y (Short Form) . . . . . . . . . . 7 61 3.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.4. Signatures . . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1. HHIT Delegation . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. Manufacturer . . . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Registry . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.4. Operator . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.5. Aircraft . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.5.1. Standard Provisioning . . . . . . . . . . . . . . . . 12 70 4.5.2. Operator Assisted Provisioning . . . . . . . . . . . 14 71 4.5.3. Initial Provisioning . . . . . . . . . . . . . . . . 16 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 75 6.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 DRIP Certificates are the backbone of trust in DRIP UAS RID, 81 consisting of a chain of special certificates that results in a 82 compact certificate that is used in Broadcast RID. Some of the 83 certificates are stored in and are generated by the Registries 84 (defined in Section 4.3) and allow a user to confirm the 85 trustworthiness of an Unmanned Aircraft (herein referred to as 86 Aircraft) even in the scenario that the Observer is disconnected from 87 the Internet. 89 1.1. Use of the word Certificate 91 The certificates defined in the document were originally referred to 92 as Host Identity Claims as early in the documents inception the 93 authors felt that a distinction should have been drawn between 94 certificates and what was being defined here. 96 This was due to the term "certificate" having significant technologic 97 and legal baggage associated with it, specifically around X.509 98 certificates. These type of certificates and Public Key 99 Infrastructure invokes more legal and public policy considerations 100 than probably any other electronic communication sector. It emerged 101 as a governmental/business platform for trusted identity management 102 and was pursued in international bodies with links into treaty 103 instruments. 105 2. Terminology 107 2.1. Required Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2.2. Definitions 117 See [drip-requirements] for common DRIP terms. 119 HDA: Hierarchial HIT Domain Authority. The 16 bit field identifying 120 the HIT Domain Authority under a RAA. 122 HID: Hierarchy ID. The 32 bit field providing the HIT Hierarchy ID 123 (i.e. RAA + HDA). 125 RAA: Registered Assigning Authority. The 16 bit field identifying 126 the Hierarchical HIT Assigning Authority. 128 3. DRIP Certificates 130 The DRIP Certificates is a set of custom certificates to be used in 131 the USS/UTM system. They are created during the provision of an 132 Aircraft and are tied to the UAS ID [drip-rid]. 134 These certificates when chained together can create a chain of trust 135 back to the manufacturer itself during the initial production of a 136 given Aircraft. The chain can also be used by authorized entities to 137 trace an Aircraft through all owners and flights in the Aircraft's 138 lifetime (ICAO practice on manned aircraft). 140 The rest of this section will define the formats of certificates in 141 DRIP and their common uses. 143 3.1. Certificate: X on X (Cxx Form) 145 The Cxx Form of DRIP Certificates is a self-signed certificate (by an 146 entity known as 'x') staking an unverified claim on a HHIT/HI pairing 147 until an expiration date/time. 149 0 1 2 3 150 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 151 +---------------+---------------+---------------+---------------+ 152 | | 153 | Hierarchical | 154 | Host Identity Tag | 155 | | 156 +---------------+---------------+---------------+---------------+ 157 | | 158 | | 159 | | 160 | Host | 161 | Identity | 162 | | 163 | | 164 | | 165 +---------------+---------------+---------------+---------------+ 166 | Expiration Timestamp | 167 +---------------+---------------+---------------+---------------+ 168 | | 169 | | 170 | | 171 | | 172 | | 173 | | 174 | | 175 | Signature | 176 | | 177 | | 178 | | 179 | | 180 | | 181 | | 182 | | 183 | | 184 +---------------+---------------+---------------+---------------+ 186 Figure 1: Certificate: X on X 188 Certificates of the Cxx Form are 116 bytes. The offset of the 189 Expiration Timestamp SHOULD be of significant length (possibly 190 years). 192 These are 5 (five) Cxx Certificates that can be created in a standard 193 DRIP UAS RID system: Manufacturer on Manufacturer, RAA on RAA, HDA on 194 HDA (Registry on Registry), Operator on Operator, and Aircraft on 195 Aircraft. This is not an exhaustive list as any entity with the DRIP 196 UAS system SHOULD have a Cxx for itself. 198 3.1.1. Certificate: X on X (Short Form) 200 A smaller version of Certificate: X on X exists where the Host 201 Identity is removed allowing a claim to be made in 84 bytes. 203 The Host Identity is expected to be looked up via [hhit-registries] 204 when connected to the Internet. The smaller size of this certificate 205 has the downside of not allowing for signature verification when 206 Internet connectivity is unavailible to retreive the Host Identity. 208 0 1 2 3 209 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 210 +---------------+---------------+---------------+---------------+ 211 | | 212 | Hierarchical | 213 | Host Identity Tag | 214 | | 215 +---------------+---------------+---------------+---------------+ 216 | Expiration Timestamp | 217 +---------------+---------------+---------------+---------------+ 218 | | 219 | | 220 | | 221 | | 222 | | 223 | | 224 | | 225 | Signature | 226 | | 227 | | 228 | | 229 | | 230 | | 231 | | 232 | | 233 | | 234 +---------------+---------------+---------------+---------------+ 236 Figure 2: Certificate: X on X (Short Form) 238 3.2. Certificate: X on Y (Cxy Form) 240 The Cxy Form of DRIP Certificates is a certificate where Entity x 241 asserts trust in the binding claimed by Entity y (in Cyy) and signs 242 this asserting with a timestamp and an expiration of when the binding 243 is no longer asserted by Entity x. 245 0 1 2 3 246 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 247 +---------------+---------------+---------------+---------------+ 248 | | 249 . . 250 . Cxx . 251 . . 252 | | 253 +---------------+---------------+---------------+---------------+ 254 | | 255 . . 256 . Cyy . 257 . . 258 | | 259 +---------------+---------------+---------------+---------------+ 260 | Timestamp | 261 +---------------+---------------+---------------+---------------+ 262 | Expiration Timestamp | 263 +---------------+---------------+---------------+---------------+ 264 | | 265 | | 266 | | 267 | | 268 | | 269 | | 270 | | 271 | Signature | 272 | | 273 | | 274 | | 275 | | 276 | | 277 | | 278 | | 279 | | 280 +---------------+---------------+---------------+---------------+ 282 Figure 3: Certificate: X on Y 284 Cxy Form wraps both self-signed certificates of the entities and is 285 signed by Entity x. Two timestamps, one taken at the time of signing 286 and one as an expiration time are used to set boundaries to the 287 assertion. Care should be given to how far into the future the 288 Expiration Timestamp is set, but is left up to system policy. 290 Most certificates of this form have a length of 304 bytes. 291 Certificate: Registry on Operator on Aircraft is unique in that is 292 680 bytes long, binding of two Cxy forms (in this specific case 293 Certificate: Registry on Operator with Certificate: Operator on 294 Aircraft). 296 3.2.1. Certificate: X on Y (Short Form) 298 This certificate is a special certificate that is the ultimate 299 certificate of the DRIP UAS system. It is used in Broadcast RID to 300 provide the trustworthiness of the Aircraft without the need of the 301 Observer to be connected to the Internet. 303 0 1 2 3 304 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 305 +---------------+---------------+---------------+---------------+ 306 | | 307 | Hierarchical Host Identity Tag | 308 | of Entity X | 309 | | 310 +---------------+---------------+---------------+---------------+ 311 | | 312 . . 313 . Cyy . 314 . . 315 | | 316 +---------------+---------------+---------------+---------------+ 317 | Expiration Timestamp | 318 +---------------+---------------+---------------+---------------+ 319 | | 320 | | 321 | | 322 | | 323 | | 324 | | 325 | | 326 | Signature | 327 | | 328 | | 329 | | 330 | | 331 | | 332 | | 333 | | 334 | | 335 +---------------+---------------+---------------+---------------+ 337 Figure 4: Certificate: X on Y (Short Form) 339 The short form of the Cxy this certificate is 200 bytes long and is 340 designed to fit inside the framing of the ASTM F3411 Authentication 341 Message. The HHIT of Entity X is used in place of the full Cxx (see 342 Section 5 for comments). The timestamp is removed and only an 343 expiration timestamp is present. 345 During creation the Expiration Timestamp MUST be no later than the 346 Expiration Timestamp found in Cyy. 348 Certificate: Registry on Aircraft is the main certificate in this 349 class that is used in Broadcast RID using the HDAs HHIT and the 350 Certificate: Aircraft on Aircraft for the current UAS ID. 352 3.3. Timestamps 354 Timestamps MAY be the standard UNIX time or a protocol specific 355 timestamp, to avoid programming complexities. For example [F3411-19] 356 uses a 00:00:00 01/01/2019 offset. When a Expiration Timestamp is 357 required a desired offset is added, setting the timestamp into the 358 future. The amount of offset for specific timestamps is left to best 359 practice. 361 3.4. Signatures 363 Signatures are ALWAYS taken over the preceding fields in the 364 certificate. For DRIP the EdDSA25519 algorithm from [RFC8032] is 365 used. 367 4. Provisioning 369 Under DRIP UAS RID a special provisioning procedure is required to 370 properly generate and distribute the certificates to all parties in 371 the USS/UTM ecosystem using DRIP RID. 373 Keypairs are expected to be generated on the device hardware it will 374 be used on. Due to hardware limitations (see Security 375 Considerations) and connectivity it is acceptable under DRIP RID to 376 generate keypairs for the Aircraft on Operator devices and later 377 securely inject them into the Aircraft. The methods to securely 378 inject and store keypair information in a "secure element" of the 379 Aircraft is out of scope of this document. 381 4.1. HHIT Delegation 383 Under the FAA [NPRM], it is expecting that IDs for UAS are assigned 384 by the UTM and are generally one-time use. The methods for this 385 however are unspecified leaving two options. 387 1 The entity generates its own HHIT, discovering and using the RAA 388 and HDA for the target Registry. The method for discovering a 389 Registry's RAA and HDA is out of scope here. This allows for the 390 device to generate an HHIT to send to the Registry to be accepted 391 (thus generating the required Host Identity Claim) or denied. 393 2 The entity sends to the Registry its HI for it to be hashed and 394 result in the HHIT. The Registry would then either accept 395 (returning the HHIT to the device) or deny this pairing. 397 In either case the Registry must decide if the HI/HHIT pairing is 398 valid. This in its simplest form is checking the current Registry 399 for a collision on the HHIT. 401 Upon accepting a HI/HHIT pair the Registry MUST populate the required 402 DNS serving the HDA with the HIP RR and other relevant RR types (such 403 as TXT and CERT). The Registry MUST also generate the appropriate 404 DRIP Certificates for the given operation. 406 If the Registry denied the HI/HHIT pair, because there was a HHIT 407 collision or any other reason, the Registry MUST signal back to the 408 device being provisioned that a new HI and HHIT needs to be 409 generated. 411 4.2. Manufacturer 413 +--------------+ Ca0a0 +-----------------+ 414 | Manufacturer | <--------> | Manufacturer CA | 415 +--------------+ Cma0 +-----------------+ 416 ^ | 417 | | 418 | | 419 Ca0a0 | | Cma0 420 | | 421 | v 422 +----------+ 423 | Aircraft | 424 +----------+ 426 During the initial configuration and production at the factory the 427 Aircraft MUST be configured to have a serial number. ASTM defines 428 this to be an ANSI/CTA-2063A. Under DRIP a HHIT can be encoded as 429 such to be able to convert back and forth between them. This is out 430 of scope for this document. 432 Under DRIP the Manufacturer SHOULD be using HHITs and have their own 433 keypair and Cxx (Certificate: Manufacturer on Manufacturer). [Ed. 434 Note: Some words on aircraft keypair and certs here]. 436 Certificate: Aircraft 0 on Aircraft 0 (Ca0a0) is extracted by the 437 manufacturer and send to their Certificate Authority (CA) to be 438 verified and added. A resulting certificate (Certificate: 439 Manufacturer on Aircraft 0) SHOULD be a DRIP Certificate in the Cxy 440 Form - however this certificate could be a X.509 certificate binding 441 the serial number to the manufacturer. 443 4.3. Registry 445 TODO 446 DRIP UAS RID defines two levels of hierarchy maintained by the 447 Registration Assigning Authority (RAA) and HHIT Domain Authority 448 (HDA). The authors anticipate that an RAA is owned and operated by a 449 regional CAA (or a delegated party by an CAA in a specific airspace 450 region) with HDAs being contracted out. As such a chain of trust for 451 registries is required to ensure trustworthiness is not compromised. 452 More information on the registries can be found in [hhit-registries]. 454 Both the RAA and HDA generate their own keypairs and self-signed 455 certificates (Certificate: RAA on RAA and Certificate: HDA on HDA 456 respectively). The HDA sends to the RAA its self-signed certificate 457 to be added into the RAA DNS. 459 The RAA confirms the certificate received is valid and that no HHIT 460 collisions occur before added a HIP RR to its DNS for the new HDA. A 461 Certificate: RAA on HDA is sent as a confirmation that provisioning 462 was successful. 464 The HDA is now a valid "Registry" and uses its keypair and 465 Certificate: HDA on HDA with all provisioning requests from 466 downstream. 468 4.4. Operator 470 +----------+ +---------+ 471 | Registry | ---------> | HDA DNS | 472 +----------+ [HIP RR] +---------+ 473 ^ | 474 | | 475 | | 476 Coo | | Cro 477 | | 478 | v 479 +----------+ 480 | Operator | 481 +----------+ 483 The Operator generates a keypair and HHIT as specified in DRIP UAS 484 RID. A self-signed certificate (Certificate: Operator on Operator) 485 is generated and sent to the desired Registry (HDA). Other relevant 486 information and possibly personally identifiable information needed 487 may also be required to be sent to the Registry (all over a secure 488 channel - the method of which is out of scope for this document). 490 The Registry cross checks any personally identifiable information as 491 required. Certificate: Operator on Operator is verified (both using 492 the expiration timestamp and signature). The HHIT is searched in the 493 Registries database to confirm that no collision occurs. A new 494 certificate is generated (Certificate: Registry on Operator) and sent 495 securely back to the Operator. Optionally the HHIT/HI pairing can be 496 added to the Registries DNS in to form of a HIP Resource Record (RR). 497 Other RRs, such as CERT and TXT, may also be used to hold public 498 information. 500 With the receipt of Certificate: Registry on Operator the 501 provisioning of an Operator is complete. 503 4.5. Aircraft 505 4.5.1. Standard Provisioning 507 Under standard provisioning the Aircraft has its own connectivity to 508 the Registry, the method which is out of scope for this document. 510 +----------+ 511 | Registry | 512 +----------+ 513 ^ 514 | 515 | 516 | Cro, CoaN 517 | 518 | 519 +----------+ +----------+ 520 | Operator | <--------------------- | Aircraft | 521 +----------+ Ca0aN +----------+ 523 Figure 5: Standard Provision: Step 1 525 Through mechanisms not specified in this document the Aircraft should 526 have methods to instruct the Aircrafts onboard systems to generate a 527 keypair and certificate. This certificate is chained to the factory 528 provisioned certificate (Certificate: Aircraft 0 on Aircraft 0). 529 This new certificate (Certificate: Aircraft 0 on Aircraft N) is 530 securely extracted by the Operator. 532 With Certificate: Aircraft 0 on Aircraft N the sub certificate 533 (Certificate: Aircraft N on Aircraft N) is used by the Operator to 534 generate Certificate: Operator on Aircraft N. This certificate along 535 with Certificate: Registry on Operator is sent to the Registry. 537 +----------+ 538 | Registry | 539 +----------+ 540 | 541 | 542 | 543 | Token 544 | 545 v 546 +----------+ +----------+ 547 | Operator | ---------------------> | Aircraft | 548 +----------+ Token +----------+ 550 Figure 6: Standard Provision: Step 2 552 On the Registry Certificate: Registry on Operator is verified and 553 used as confirmation that the Operator is already registered. 554 Certificate: Operator on Aircraft N also undergoes a validation check 555 and used to generate a token to return to the Operator to continue 556 provisioning. 558 Upon receipt of this token, the Operator injects it into the Aircraft 559 and its used to form a secure connection to the Registry. The 560 Aircraft then sends Certificate: Manufacturer on Aircraft 0 and 561 Certificate: Aircraft 0 to Aircraft N. 563 +---------+ 564 | HDA DNS | 565 +---------+ 566 ^ 567 | 568 | HIP RR 569 | 570 | 571 | 572 +----------+ <----------------------------+ 573 | Registry | | 574 +----------+ ------------------------+ | 575 | | | 576 | | | Token, 577 | CroaN CraN | | Cma0, Ca0aN 578 | | | 579 | | | 580 v v | 581 +----------+ +----------+ 582 | Operator | | Aircraft | 583 +----------+ +----------+ 584 Figure 7: Standard Provision: Step 3 586 The Registry uses Certificate: Manufacturer on Aircraft 0 (with an 587 external database if supported) to confirm the validity of the 588 Aircraft. Certificate: Aircraft 0 on Aircraft N is correlated with 589 Certificate: Operator on Aircraft N and Certificate: Manufacturer on 590 Aircraft 0 to see the chain of ownership. The new HHIT tied to 591 Aircraft N is then checked for collisions in the HDA. With the 592 information the Registry generates two certificates: Certificate: 593 Registry on Operator on Aircraft N and Certificate: Registry on 594 Aircraft N. A HIP RR (and other RR types as needed) are generated 595 and inserted into the HDA. 597 Certificate: Registry on Operator on Aircraft N is sent via a secure 598 channel back to the Operator to be stored. Certificate: Registry on 599 Aircraft N is sent to the Aircraft to be used in Broadcast RID. 601 4.5.2. Operator Assisted Provisioning 603 This provisioning scheme is for when the Aircraft is unable to 604 connect to the Registry itself or does not have the hardware required 605 to generate keypairs and certificates. 607 +----------+ 608 | Registry | 609 +----------+ 611 +----------+ +----------+ 612 | Operator | ---------------------> | Aircraft | 613 +----------+ aN, CaNaN +----------+ 615 Figure 8: Operator Assisted Provision: Step 1 617 To start the Operator generates on behalf of the Aircraft a new 618 keypair and Certificate: Aircraft N on Aircraft N. This keypair and 619 certificate are injected into the Aircraft for it to generate 620 Certificate: Aircraft 0 on Aircraft N. After injecting the keypair 621 and certificate, the Operator MUST destroy all copies of the keypair. 623 +----------+ 624 | Registry | 625 +----------+ 626 ^ 627 | 628 | 629 | Cro, Cma0, Ca0aN, CoaN 630 | 631 | 632 +----------+ +----------+ 633 | Operator | <--------------------- | Aircraft | 634 +----------+ Cma0, Ca0aN +----------+ 636 Figure 9: Operator Assisted Provision: Step 2 638 Certificate: Manufacturer on Aircraft 0 and Certificate: Aircraft 0 639 on Aircraft N is extracted by the Operator and the following data 640 items are sent to the Registry; Certificate: Registry on Operator, 641 Certificate: Manufacturer on Aircraft 0, Certificate: Aircraft 0 on 642 Aircraft N, Certificate: Operator on Aircraft N. 644 +----------+ +---------+ 645 | Registry | ---------> | HDA DNS | 646 +----------+ HIP RR +---------+ 647 | 648 | 649 | 650 | CroaN, CraN 651 | 652 v 653 +----------+ +----------+ 654 | Operator | ---------------------> | Aircraft | 655 +----------+ CraN +----------+ 657 Figure 10: Operator Assisted Provision: Step 3 659 On the Registry validation checks are done on all certificates as per 660 the previous sections. Once complete then the Registry checks for a 661 HHIT collision, adding to the HDA if clear and generates Certificate: 662 Registry on Operator on Aircraft N and Certificate: Registry on 663 Aircraft N. Both are sent back to the Operator. 665 The Operator securely inject Certificate: Registry on Aircraft N and 666 securely stores Certificate: Registry on Operator on Aircraft N. 668 4.5.3. Initial Provisioning 670 A special form of provisioning is used when the Aircraft is first 671 sold to an Operator. Instead of generating a new keypair, the built 672 in keypair and certificate done by the Manufacturer is used to 673 provision and register the aircraft to the owner. 675 For this either Standard or Operator Assisted methods can be used. 677 5. Security Considerations 679 A major consideration is the optimization done in Certificate: 680 Registry on Aircraft to get its length down to 200 bytes. The 681 truncation of Certificate: HDA on HDA down to just its HHIT is one 682 that could be used against the system to act as a false Registry. 683 For this to occur an attacker would need to find a hash collision on 684 that Registry HHIT and then manage to spoof all of DNS being used in 685 the system. 687 The authors believe that the probability of such an attack is low 688 when Registry operators are using best practices in security. If 689 such an attack can occur (especially in the time frame of "one-time 690 use IDs") then there are more serious issues present in the system. 692 6. References 694 6.1. Normative References 696 [F3411-19] "Standard Specification for Remote ID and Tracking", 697 February 2020. 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 705 Signature Algorithm (EdDSA)", RFC 8032, 706 DOI 10.17487/RFC8032, January 2017, 707 . 709 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 710 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 711 May 2017, . 713 6.2. Informative References 715 [drip-requirements] 716 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 717 "Drone Remote Identification Protocol (DRIP) 718 Requirements", Work in Progress, Internet-Draft, draft- 719 ietf-drip-reqs-05, 16 October 2020, . 722 [drip-rid] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 723 "UAS Remote ID", Work in Progress, Internet-Draft, draft- 724 ietf-drip-uas-rid-01, 9 September 2020, 725 . 728 [hhit-registries] 729 Moskowitz, R., Card, S., and A. Wiethuechter, 730 "Hierarchical HIT Registries", Work in Progress, Internet- 731 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 732 2020, . 735 [NPRM] "Notice of Proposed Rule Making on Remote Identification 736 of Unmanned Aircraft Systems", December 2019. 738 Authors' Addresses 740 Adam Wiethuechter 741 AX Enterprize, LLC 742 4947 Commercial Drive 743 Yorkville, NY 13495 744 United States of America 746 Email: adam.wiethuechter@axenterprize.com 748 Stuart Card 749 AX Enterprize, LLC 750 4947 Commercial Drive 751 Yorkville, NY 13495 752 United States of America 754 Email: stu.card@axenterprize.com 756 Robert Moskowitz 757 HTT Consulting 758 Oak Park, MI 48237 759 United States of America 760 Email: rgm@labs.htt-consult.com