idnits 2.17.1 draft-wiethuechter-drip-identity-claims-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Croa is special in that it is similar to an issued automobile registration. The Operator, once it receives Croa via a secure channel from the Registry, should store it somewhere safe to be recalled if required. It SHOULD not be public available, as it can be classified as Personally Identifiable Information (PII). -- The document date (20 September 2020) is 1312 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: 'RFC4398' is mentioned on line 201, but not defined == Missing Reference: 'RFC3498' is mentioned on line 347, but not defined == Missing Reference: 'HIP RR' is mentioned on line 430, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP A. Wiethuechter 3 Internet-Draft S. Card 4 Intended status: Standards Track AX Enterprize 5 Expires: 24 March 2021 R. Moskowitz 6 HTT Consulting 7 20 September 2020 9 DRIP Identity Claims 10 draft-wiethuechter-drip-identity-claims-01 12 Abstract 14 This document describes 7 Identity Claims for use in various Drone 15 Remote ID Protocols (DRIP). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 24 March 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 53 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Host Identity Claims . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Why the term: Host Identity Claims . . . . . . . . . . . 3 56 3.2. Cxx Form . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2.1. Cxx Claims . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Cxy Form . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. Cxy Claims . . . . . . . . . . . . . . . . . . . . . 7 60 3.4. Claim: Registry on Aircraft . . . . . . . . . . . . . . . 7 61 4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. HHIT Delegation . . . . . . . . . . . . . . . . . . . . . 9 63 4.2. Manufacturer . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3. Operator . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.4. Aircraft . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 11 67 4.4.2. Operator Assisted Provisioning . . . . . . . . . . . 13 68 4.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 14 69 4.5. Registry . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 8.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document expands on Hierarchical HIT Registries 81 [hhit-registries], defining 7 Identity Claims that are created and 82 distributed through the provisioning process of a Unmanned Aircraft 83 in Trustworthy Multipurpose Remote ID (TMRID). 85 These claims establish trust for Hierarchical HITs 86 [hierarchical-hit]. They are then used in various Drone Remote ID 87 Protocols to establish the trustworthy claims needed to safely use 88 the data provided. 90 2. Terms and Definitions 91 2.1. Requirements Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 2.2. Definitions 101 HDA (Hierarchical HIT Domain Authority): The 16 bit field 102 identifying the HIT Domain Authority under a RAA. 104 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 106 RAA (Registered Assigning Authority): The 16 bit field identifying 107 the Hierarchical HIT Assigning Authority. 109 3. Host Identity Claims 111 Under DRIP there are a total of 7 Identity Claims created during the 112 provisioning of the UA to enable trustworthiness. This document 113 specifies the Host Identity Claims forms in detail, the individual 114 Host Identity Claims created and their use in DRIP. 116 3.1. Why the term: Host Identity Claims 118 Host Identity Claims are a form of digital certificates, specially 119 crafted for the UAS/USS ecosystem. The term "certificates" has been 120 avoided due to the significant technology and legal baggage around 121 X.509 certificates. 123 X.509 certificates and Public Key Infrastructure invokes more legal 124 and public policy considerations than probably any other electronic 125 communication sector. It emerged as a governmental platform for 126 trusted identity management and was pursued in intergovernmental 127 bodies with links into treaty instruments. 129 Thus there is a common expectation whenever the term "Certificates" 130 are used, and the term "Host Identity Claims" to carefully separate 131 these objects from X.509 objects and to emphasize their role as 132 claims. 134 3.2. Cxx Form 136 Cxx is a self-signed Host Identity Claim on entity 'x' with the 137 following format: 139 0 1 2 3 140 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 141 +---------------+---------------+---------------+---------------+ 142 | | 143 | Hierarchical | 144 | Host Identity Tag | 145 | | 146 +---------------+---------------+---------------+---------------+ 147 | | 148 | | 149 | | 150 | Host | 151 | Identity | 152 | | 153 | | 154 | | 155 +---------------+---------------+---------------+---------------+ 156 | Expiration Timestamp | 157 +---------------+---------------+---------------+---------------+ 158 | | 159 | | 160 | | 161 | | 162 | | 163 | | 164 | | 165 | Signature | 166 | | 167 | | 168 | | 169 | | 170 | | 171 | | 172 | | 173 | | 174 +---------------+---------------+---------------+---------------+ 176 This Host Identity Claim form is used to stake an unverified claim 177 onto the specified HI/HHIT pairing, until an expiration time, to be 178 used in DRIP for entity 'x'. All Identity Claims of this form are 179 116 bytes in length. 181 The Expiration Timestamp MUST be current UNIX time, at the time of 182 signing, plus an offset into the future. This offset SHOULD be of 183 significant length (possibly years). 185 3.2.1. Cxx Claims 187 DRIP uses this form to create three self-signed Host Identity Claims, 188 which are then nested into other claims. The three claims created 189 are: 191 Aircraft on Aircraft (Caa) 193 Operator on Operator (Coo) 195 Registry on Registry (Crr) 197 These claims (and keypairs needed to create them) SHOULD be created 198 on the entities that own them. Crr on the Registry, Coo on the 199 Operator device and Caa on the Aircraft itself (if able). 201 These claims could also be stored in DNS under the CERT RR [RFC4398]. 202 The value of doing so is currently unknown. 204 3.3. Cxy Form 206 Cxy is a binding Host Identity Claim with the following format: 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 . . 213 . Cxx . 214 . . 215 | | 216 +---------------+---------------+---------------+---------------+ 217 | | 218 . . 219 . Cyy . 220 . . 221 | | 222 +---------------+---------------+---------------+---------------+ 223 | Timestamp | 224 +---------------+---------------+---------------+---------------+ 225 | Expiration Timestamp | 226 +---------------+---------------+---------------+---------------+ 227 | | 228 | | 229 | | 230 | | 231 | | 232 | | 233 | | 234 | Signature | 235 | | 236 | | 237 | | 238 | | 239 | | 240 | | 241 | | 242 | | 243 +---------------+---------------+---------------+---------------+ 245 In the Cxy form a binding is asserted between the entities of 'x' and 246 'y'. The self-signed Host Identity Claims of Cxx and Cyy are used in 247 the new claim. The new Identity Claims is signed by the first party 248 (in the example above owner of Cxx) using their keypair. 250 During Host Identity Claim creation Timestamp and Expiration 251 Timestamp MUST be UNIX time (with Expiration Timestamp being created 252 using an offset setting it into the future) and MUST be no later than 253 the Expiration Timestamps found in Cxx and Cyy. 255 3.3.1. Cxy Claims 257 In DRIP two Identity Claims are created in the Cxy way, and third one 258 which is a special nesting of the created Host Identity Claims (but 259 following the Cxy form). These claims are as follows: 261 Registry on Operator (Cro): Using Crr and Coo as Cxx and Cyy 262 respectively, this claims asserts the Registry's Acceptance of the 263 claims in Coo. This MUST be performed on the Registry. It is 304 264 bytes in length. 266 Operator on Aircraft (Coa): Using Coo and Caa (Cxx and Cyy 267 respectively) this claim asserts a binding between an Operator and 268 Aircraft. This MUST be performed on the Operator device. It is 269 304 bytes in length. 271 Registry on Operator on Aircraft (Croa): A special claim created, 272 asserting the transitivity between Registry, Operator and 273 Aircraft. It uses Cro as Cxx and Coa as Cyy. This MUST be 274 performed on the Registry. It is 680 bytes in length. 276 The exact methods of transferring data between the entities are out 277 of scope of this document. It MUST be secure, especially when the 278 Registry sends back Croa. It is RECOMMENDED that HIP be used if 279 possible, considering that HHITs are being used already. 281 Croa is special in that it is similar to an issued automobile 282 registration. The Operator, once it receives Croa via a secure 283 channel from the Registry, should store it somewhere safe to be 284 recalled if required. It SHOULD not be public available, as it can 285 be classified as Personally Identifiable Information (PII). 287 It is possible that Cro and/or Coa are stored in DNS and are public 288 available as a result. If so, the CERT RR [RFC3498] should be used 289 to store them. It is unknown the value of storing them in DNS gives. 291 3.4. Claim: Registry on Aircraft 293 The Registry on Aircraft claim is a special Host Identity Claim 294 defined as follows: 296 0 1 2 3 297 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 298 +---------------+---------------+---------------+---------------+ 299 | | 300 | Hierarchical | 301 | Host Identity Tag | 302 | | 303 +---------------+---------------+---------------+---------------+ 304 | | 305 . . 306 . Caa . 307 . . 308 | | 309 +---------------+---------------+---------------+---------------+ 310 | Expiration Timestamp | 311 +---------------+---------------+---------------+---------------+ 312 | | 313 | | 314 | | 315 | | 316 | | 317 | | 318 | | 319 | Signature | 320 | | 321 | | 322 | | 323 | | 324 | | 325 | | 326 | | 327 | | 328 +---------------+---------------+---------------+---------------+ 330 This Identity Claim uses the HHIT of the Registry and Caa to form a 331 short (200 byte) certificate to be used on the Aircraft in Broadcast 332 Remote ID. 334 During Host Identity Claim creation the Expiration Timestamp MUST be 335 UNIX time (with an offset added to it, setting it into the future) 336 and also MUST be no later than the Expiration Timestamp found in Caa. 338 The Registry HHIT is substituted for Crr to keep the Host Identity 339 Claim within the constraints of Broadcast RID payload size. This 340 optimization does allow for an attacker to attempt a hash collision 341 on the HHIT. This, the authors argue, would be incredible hard as 342 the attacker would need to corrupt DNS to go undetected. That is if 343 a collision on the HHIT is even found in time as it is expected that 344 standard operating procedure for UAS would be to use "one-time" 345 identifiers. 347 Cra could also be stored in DNS using the CERT RR [RFC3498]. If this 348 is of any benefit has not been explored. 350 4. Provisioning 352 This section gives an overview of how an Operator then Aircraft are 353 provisioned under DRIP. 355 First keypairs are generates on the required devices. Due to 356 limitations in hardware and connectivity it is acceptable to generate 357 the Aircraft keypairs and Host Identity Claims on the Operator device 358 and later embed the data into the Aircraft at the end of 359 provisioning. The methods to securely perform the action of handling 360 the data and embedding it into the Aircraft hardware are out of scope 361 for this document. This section of the document assumes that the 362 Operator is acting on behalf of the Aircraft. 364 4.1. HHIT Delegation 366 Under the FAA NPRM, it is expect that IDs for UAS are assigned by the 367 UTM and are generally one-time use. The methods for this however is 368 unspecified leaving two options. 370 The entity generates its own HHIT, discovering and using the RAA 371 and HDA for the target Registry. The method for discovering a 372 Registry's RAA and HDA is out of scope here. This allows for the 373 device to generate an HHIT to send to the Registry to be accepted 374 (thus generating the required Host Identity Claim) or denied. 376 The entity sends to the Registry its HI for it to be hashed and 377 result in the HHIT. The Registry would then either accept 378 (returning the HHIT to the device) or deny this pairing. 380 In either case the Registry must make a decision on if the HI/HHIT 381 pairing is valid. This in its simplest form is checking the current 382 Registry for a collision on the HHIT. 384 Upon accepting a HI/HHIT pair the Registry MUST populate the required 385 the DNS serving the HDA with the HIP RR and other relevant RR types 386 (such as TXT and CERT). The Registry MUST also generate the 387 appropriate Host Identity Claim for the given operation. 389 If the Registry denied the HI/HHIT pair, because their was a HHIT 390 collision or any other reason, the Registry MUST signal back to the 391 device being provisioned that a new HI needs to be generated. 393 The subsequent sections follow that the device is generating its own 394 HHIT. 396 4.2. Manufacturer 398 +--------------+ Ca0a0 +-----------------+ 399 | Manufacturer | <--------> | Manufacturer CA | 400 +--------------+ Cma0 +-----------------+ 401 ^ | 402 | | 403 | | 404 Ca0a0 | | Cma0 405 | | 406 | v 407 +----------+ 408 | Aircraft | 409 +----------+ 411 During the initial configuration and production at a factory the 412 Aircraft MUST be configured to have a Serial Number. This is defined 413 by ASTM as being an ANSI-CTA2063A. Under DRIP a HHIT can be encoded 414 as such (out of scope for this document). 416 Under DRIP the Manufacturer SHOULD be using HHITs and have their own 417 keypair and Cxx (known here as Cmm). A new Aircraft should generate 418 its own keypairs and generate a Cxx certificate (known as Ca0a0) 420 Ca0a0 is extracted by the manufacturer and sent to their Certificate 421 Authority (CA) to be verified and added. The resulting certificate 422 (Cma0 here) SHOULD be a certificate of the Cxy form - however it 423 could be a X.509 certificate binding the Serial Number ID to the 424 manufacturer. 426 4.3. Operator 428 +----------+ +---------+ 429 | Registry | ---------> | HDA DNS | 430 +----------+ [HIP RR] +---------+ 431 ^ | 432 | | 433 | | 434 Coo | | Cro 435 | | 436 | v 437 +----------+ 438 | Operator | 439 +----------+ 441 The Operator generates his HHIT then Coo and sends Coo (along with 442 other relevant information if required) to the desired Registry. 444 The Registry performs Operator registration, by confirming that no 445 HHIT collisions occur. Coo undergoes a signature verification. If 446 everything passes the Registry optionally adds the HIP RR and other 447 RRs (such as CERT and TXT) into the HDA DNS, generates Cro and 448 transmits it back to the Operator. 450 Upon receiving Cro the Operator is now registered in the Registry and 451 can proceed to provision any Aircraft. Further verification of Cro 452 can be done, if desired. 454 4.4. Aircraft 456 4.4.1. Standard Provisioning 458 +----------+ 459 | Registry | 460 +----------+ 461 ^ 462 | 463 | 464 | Cro, CoaN 465 | 466 | 467 +----------+ +----------+ 468 | Operator | <--------------------- | Aircraft | 469 +----------+ Ca0aN +----------+ 471 First the Operator instructs the onboard Aircraft system to generate 472 a keypair and then extracts from the Aircraft (through a secure 473 mechanism) Ca0aN. 475 Using Ca0aN, the Operator generates a CoaN and sends to the Registry: 477 * Cro; for verification of the Operator 479 * CoaN; claim to bind aircraft identity aN to Operator 480 +----------+ 481 | Registry | 482 +----------+ 483 | 484 | 485 | 486 | Token 487 | 488 v 489 +----------+ +----------+ 490 | Operator | ---------------------> | Aircraft | 491 +----------+ Token +----------+ 493 The Registry performs checks on the received Cro to confirm the 494 identity of the Operator and a check on CoaN to confirm signatures. 496 In response the Registry sends to the Operator a Token to pass to the 497 Aircraft to continue provisioning. 499 +---------+ 500 | HDA DNS | 501 +---------+ 502 ^ 503 | 504 | HIP RR 505 | 506 | 507 | 508 +----------+ <-----------------------------+ 509 | Registry | | 510 +----------+ -------------------------+ | 511 | | | 512 | | | Token, 513 | CroaN CraN | | Cma0, Ca0aN 514 | | | 515 | | | 516 v v | 517 +----------+ +----------+ 518 | Operator | | Aircraft | 519 +----------+ +----------+ 521 Using the Token as authentication the Aircraft connects via a secure 522 channel to the Registry. Once connected the Aircraft sends: 524 * Cma0; authentication for itself to confirm its identity 526 * Ca0aN; the Cxx for the new identity it wants to use with the 527 Operator 529 The Registry first checks that Cma0 checks out via external methods 530 (the manufacturer CA). 532 The Registry also checks that the aN in Ca0aN matches the original 533 requested aN in the Operators CoaN sent. 535 In response the Registry generates and issues CroaN to the Operator 536 and CraN to the Aircraft. A HIP RR is also generates and added to 537 the HDA DNS for the new Aircraft identifier. 539 4.4.2. Operator Assisted Provisioning 541 The goal of Operator Assisted Provisioning is to support the case 542 where the Aircraft can not itself connect to the Registry and instead 543 uses the Operator as a proxy. 545 +----------+ 546 | Registry | 547 +----------+ 549 +----------+ +----------+ 550 | Operator | ---------------------> | Aircraft | 551 +----------+ aN, CaNaN +----------+ 553 To start the Operator generates the Aircraft's new keypair and Cxx 554 certificate. These are inject into the Aircraft (with a secure 555 mechanism). 557 The Aircraft then generates on its own Ca0aN. 559 +----------+ 560 | Registry | 561 +----------+ 562 ^ 563 | 564 | 565 | Cro, Cma0, Ca0aN, CoaN 566 | 567 | 568 +----------+ +----------+ 569 | Operator | <--------------------- | Aircraft | 570 +----------+ Cma0, Ca0aN +----------+ 572 The Operator now extracts Cma0 and Ca0aN to continue provisioning. 574 The Operator generates CoaN using Ca0aN and sends to the Registry: 576 * Cro; for verification of the Operator 578 * Cma0; for verification of the Aircraft 580 * Ca0aN; for verification of the binding 582 * CoaN; claim to bind aircraft identity aN to Operator 584 +----------+ +---------+ 585 | Registry | ---------> | HDA DNS | 586 +----------+ HIP RR +---------+ 587 ^ 588 | 589 | 590 | CroaN, CraN 591 | 592 | 593 +----------+ +----------+ 594 | Operator | ---------------------> | Aircraft | 595 +----------+ CraN +----------+ 597 After verification of all the received components the Registry 598 generates CroaN and CraN and sends them back to the Operator. 600 The Operator then securely injects CraN into the Aircraft for use. 602 4.4.3. Initial Provisioning 604 A special form of provisioning is used when the Aircraft is first 605 sold to a Operator. Instead of generating a new keypair, the built 606 in keypair (a0, Ca0a0) is used to provision and register the aircraft 607 to the owner. 609 For this either Standard or Operator Assisted methods can be used. 611 4.5. Registry 613 It should be noted that the Registry can undergo a similar process as 614 Operator/Aircraft to provision them to an RAA (as a Registry is most 615 likely the HDA). This is currently not specified here for brevity of 616 the document. 618 5. IANA Considerations 620 TBD 622 6. Security Considerations 624 A major consideration is the optimization done in Cra to get its 625 length down to 200 bytes. The truncation of Crr down to just its 626 HHIT is one that could be used against the system to act as a false 627 Registry. For this to occur an attacker would need to find a hash 628 collision on that Registry HHIT and then manage to spoof all of DNS 629 being used in the system. 631 The authors believe that the probability of such an attack is low 632 when Registry operators are using best practices in security. If 633 such an attack is able to occur (especially in the time frame of 634 "one-time use IDs") then there are more serious issues present in the 635 system. 637 7. Acknowledgments 639 TBD 641 8. References 643 8.1. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 8.2. Informative References 656 [hhit-registries] 657 Moskowitz, R., Card, S., and A. Wiethuechter, 658 "Hierarchical HIT Registries", Work in Progress, Internet- 659 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 660 2020, . 663 [hierarchical-hit] 664 Moskowitz, R., Card, S., and A. Wiethuechter, 665 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 666 Draft, draft-moskowitz-hip-hierarchical-hit-05, 13 May 667 2020, . 670 Authors' Addresses 672 Adam Wiethuechter 673 AX Enterprize 674 4947 Commercial Drive 675 Yorkville, NY 13495 676 United States of America 678 Email: adam.wiethuechter@axenterprize.com 680 Stuart W. Card 681 AX Enterprize 682 4947 Commercial Drive 683 Yorkville, NY 13495 684 United States of America 686 Email: stu.card@axenterprize.com 688 Robert Moskowitz 689 HTT Consulting 690 Oak Park, MI 48237 691 United States of America 693 Email: rgm@labs.htt-consult.com