DRIP Working Group                                       A. Wiethuechter
Internet-Draft                                                   S. Card
Intended status: Standards Track                      AX Enterprize, LLC
Expires: 21 June 20 December 2021                                   R. Moskowitz
                                                          HTT Consulting
                                                            18 December 2020 June 2021

                      DRIP Authentication Formats
                        draft-ietf-drip-auth-00
                        draft-ietf-drip-auth-01

Abstract

   This document describes how to include trust into the ASTM Remote ID
   specification defined in ASTM F3411-19 under a Broadcast Remote ID
   (RID) scenario.  It defines a few different message schemes (based on
   the Authentication Message) that can be used to assure past messages
   sent by a UA and also act as an assurance for UA trustworthiness in
   the absence of Internet connectivity at the receiving node.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 June 20 December 2021.

Copyright Notice

   Copyright (c) 2020 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  DRIP Requirements Addressed . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
     2.1.  Required Terminology  . . . . . . . . . . . . . . . . . .   3   4
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3   4
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
     3.1.  Problem Space and Focus . . . . . . . . . . . . . . . . .   4
     3.2.  Reasoning for IETF DRIP Authentication  . . . . . . . . .   4
     3.3.  ASTM Authentication Message . . . . . . . . . . . . . . .   4   5
   4.  DRIP Authentication Framing Formats . . . . . . . . . . . . . . . . .   6
     4.1.  DRIP General Frame  UAS ID Signature  . . . . . . . . . . . . . . . . . . . .   6
       4.1.1.  DRIP Header
     4.2.  Operator ID Signature . . . . . . . . . . . . . . . . . .   7
     4.3.  Message Set Signature . . . .   8
       4.1.2.  DRIP Authentication Data . . . . . . . . . . . . . .   8
       4.1.3.  Forward Error Correction
     4.4.  Specific Method . . . . . . . . . . . . . . . . . . . . .   9
     4.2.
       4.4.1.  DRIP Wrapper Frame Format . . . . . . . . . . . . . . . . . .   9
       4.4.2.  DRIP Wrapper Format .  10
       4.2.1.  UA Hierarchical Host Identity Tag . . . . . . . . . .  11
       4.2.2.  Trust Timestamp . . . . . .  11
       4.4.3.  DRIP Manifest Format  . . . . . . . . . . . . . . . .  11
       4.2.3.  Wrapped Authentication Data
       4.4.4.  DRIP Link Format  . . . . . . . . . . . . .  12
       4.2.4.  Wrapper Signature . . . . .  13
   5.  Transport Methods & Recommendations . . . . . . . . . . . . .  16
     4.3.  DRIP Attestation Frame  13
     5.1.  Legacy Advertisements (Bluetooth 4.X) . . . . . . . . . .  13
     5.2.  Extended Advertisements (Bluetooth 5.X, WiFi NaN, WiFi
           Beacon) . . . . . . .  16
       4.3.1.  Attestation Data . . . . . . . . . . . . . . . . . .  17
       4.3.2.  Expiration Timestamp  14
     5.3.  DRIP Recommendations  . . . . . . . . . . . . . . . .  18
       4.3.3.  Attestation Signature . .  14
   6.  ICAO Considerations . . . . . . . . . . . . . .  18
   5.  Transport Methods & Recommendations . . . . . . .  14
   7.  IANA Considerations . . . . . .  18
     5.1.  Legacy Advertisements (Bluetooth 4.X) . . . . . . . . . .  18
     5.2.  Extended Advertisements (Bluetooth 5.X and Wifi NaN) . .  19
   6.  ASTM . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     8.1.  Manifest Hash Length  . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . .  15
     8.2.  Replay Attacks  . . . . . . .  20
   8.  Security Considerations . . . . . . . . . . . . . .  15
     8.3.  Trust Timestamp Offsets . . . . .  20 . . . . . . . . . . . .  16
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20  16
   10. Appendix A: Thoughts on ASTM Authentication Message . . . . .  20  16
   11. References Appendix B: DRIP Attestations . . . . . . . . . . . . . . . .  17
     11.1.  Self-Attestation (Axx) . . . . . . . . .  21
     11.1.  Normative References . . . . . . . .  17
     11.2.  Attestation (Axy)  . . . . . . . . . .  21
     11.2.  Informative References . . . . . . . . .  18
     11.3.  Concise Attestation (C-Axy)  . . . . . . . .  21
   Authors' Addresses . . . . . .  19
     11.4.  Mutual Attestation (M-Axy) . . . . . . . . . . . . . . .  20
     11.5.  Link Attestation (L-Axy) . .  22

1.  Introduction

   UA Systems (UAS) are usually in a volatile environment when it comes
   to communication.  UA are generally small with little computational
   (or flying) . . . . . . . . . . . . . .  21
     11.6.  Broadcast Attestation (B-Axy)  . . . . . . . . . . . . .  22
     11.7.  Link Certificate (L-Cxy) . . . . . . . . . . . . . . . .  24
     11.8.  Mutual Certificate (M-Cxy) . . . . . . . . . . . . . . .  24
     11.9.  Example Registration with Attestation  . . . . . . . . .  25
   12. Appendix C: DRIP Broadcast Attestation Structure  . . . . . .  26
     12.1.  Attestor Hierarchical Host Identity Tag  . . . . . . . .  27
     12.2.  Attestation Data . . . . . . . . . . . . . . . . . . . .  27
     12.3.  Trust Timestamp  . . . . . . . . . . . . . . . . . . . .  27
     12.4.  Signing Timestamp  . . . . . . . . . . . . . . . . . . .  27
     12.5.  Attestor Signature . . . . . . . . . . . . . . . . . . .  28
   13. Appendix D: Forward Error Correction  . . . . . . . . . . . .  28
     13.1.  Encoding . . . . . . . . . . . . . . . . . . . . . . . .  28
       13.1.1.  Single Page FEC  . . . . . . . . . . . . . . . . . .  28
       13.1.2.  Multi Page FEC . . . . . . . . . . . . . . . . . . .  29
     13.2.  Decoding . . . . . . . . . . . . . . . . . . . . . . . .  29
       13.2.1.  Single Page FEC  . . . . . . . . . . . . . . . . . .  29
       13.2.2.  Multi Page FEC . . . . . . . . . . . . . . . . . . .  29
     13.3.  FEC Limitations  . . . . . . . . . . . . . . . . . . . .  29
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     14.2.  Informative References . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   UA Systems (UAS) are usually in a volatile environment when it comes
   to communication.  UA are generally small with little computational
   (or flying) horsepower to carry standard communication equipment.
   This limits the mediums of communication to few viable options.

   Observer systems (e.g. smartphones and tablets) place further
   constraints on the communication options.  The Remote ID Broadcast
   messages MUST be available to applications on these platforms without
   modifying the devices.

   The ASTM standard [F3411-19] focuses on two ways of communicating to
   a UAS for RID: Broadcast and Network.

   This document will focus on adding trust to Broadcast RID in the
   current (and an expanded) Authentication Message format.

1.1.  DRIP Requirements Addressed

   The following [drip-requirements] will be addressed:

   GEN 1: Provable Ownership  This will be addressed using the
      Certificate Message type (Section 4.3.1.1). DRIP
      Link.

   GEN 2: Provable Binding  This requirement is addressed using the
      Wrapped ASTM Message (Section 4.2.3.1.2), Manifest Message
      (Section 4.2.3.2) and Message Pack Signature (Section 4.2.3.1.1)
      types. DRIP
      Link, Manifest.

   GEN 3: Provable Registration  This requirement is addressed using the
      Certificate Message type (Section 4.3.1.1).
      DRIP Link.

2.  Terminology

2.1.  Required Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   See [drip-requirements] for common DRIP terms.

   Aircraft:  In this document whenever the word Aircraft is used it is
      referring to an Unmanned Aircraft (UA) not a Manned Aircraft.

3.  Background

3.1.  Problem Space and Focus

   The current standard for Remote ID (RID) does not, in any meaningful
   capacity, address the concerns of trust in the UA space with
   communication in the Broadcast RID environment.  This is a
   requirement that will need to be addressed eventually for various
   different parties that have a stake in the UA industry.

   The following subsections will provide a high level reference to the
   ASTM standard
   ASTM standard for Authentication Messages and how their current
   limitations effect trust in the Broadcast RID environment.

3.2.  Reasoning for IETF DRIP Authentication

   The ASTM Authentication Message has provisions in [F3411-19] to allow
   for other organizations to define (and standardize) Authentication
   formats.  The standardization of special formats to support the DRIP
   requirements in UAS RID for Authentication Messages and how their current
   limitations effect trustworthy communications over Broadcast
   RID is an important part of the chain of trust for a UAS ID.  No
   existing formats (defined by ASTM or others) was flexible enough to
   satisfy this goal resulting in the Broadcast RID environment.

3.2. work reflected in this document.

3.3.  ASTM Authentication Message

     Page 0:
      0                   1                   2                   3
      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
     +---------------+-----------------------------------------------+
     |  Auth Header  |                                               |
     +---------------+  ASTM Authentication Headers  +---------------+
     |                                               |               |
     +-----------------------------------------------+               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                Authentication Data / Signature                |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------------------------------------------------------+

     Page 1 - 4: 15:
      0                   1                   2                   3
      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
     +---------------+-----------------------------------------------+
     |  Auth Header  |                                               |
     +---------------+                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                Authentication Data / Signature                |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------------------------------------------------------+

     Auth Header (1 byte):
         Contains Authentication Type (AuthType) and Page Number. For
         DRIP Authentication AuthType is a value of 0x5.

     ASTM Authentication Headers: (6 bytes)
         Contains other header information for the Authentication
         Message from ASTM UAS RID Standard.

     Authentication Data / Signature: (109 bytes: 17+23*4) (0 to 255 bytes)
         Opaque authentication data.

           Figure 1: Standard ASTM Authentication Message format

   The above diagram is the format defined by ASTM [F3411-19] that is
   the frame which everything this document fits into.  The specific
   details of the ASTM headers are abstracted away as they are not
   necessarily required for this document.

   There is a 25th byte exclude in the diagrams that comes before the
   Auth Header.  This is the ASTM Header and consists of the Protocol
   Version and Message Type of the given message frame/page.

4.  DRIP Authentication Framing Formats

   Currently the ASTM AuthType of 0x5 should be used to denote DRIP
   based Authentication.  The max page count of the Authentication
   Message is increased to 10, instead of being capped at 5.

   To keep consistent formatting across the different mediums (Bluetooth
   4, Bluetooth 5 and Wifi WiFi NaN) and their independent restrictions the
   authentication data being sent is REQUIRED to fit within the first 9
   pages (Page 0 through Page 8) of the Authentication Message. Message (giving a
   max of 201 bytes).  The final (10th) page rest of the pages of the message is reserved
   exclusively for Forward Error Correction bytes and is only present on
   Bluetooth 4.

4.1.  UAS ID Signature

   The existing ASTM [F3411-19] Authentication Type 0x1 can be used to
   send a fresh Self-Attestation of the UA over 7 pages.

      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                        UA Hierarchical                        |
     |                       Host Identity Tag                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                        UA Host Identity                       |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                          UA Signature                         |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

                      Figure 2: DRIP General Frame

     Page 0: UAS ID Signature

4.2.  Operator ID Signature

   The existing ASTM [F3411-19] Authentication Type 0x2 can be used to
   send a static Self-Attestation of the Operator over 7 pages.

      0                   1                   2                   3
      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
     +---------------+-----------------------------------------------+
     +---------------+---------------+---------------+---------------+
     |  Auth Header                                                               |
     |
     +---------------+  ASTM Authentication Headers  +---------------+                     Operator Hierarchical                     |
     |  DRIP Header                       Host Identity Tag                       |
     |
     +-----------------------------------------------+---------------+                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |                    DRIP Authentication Data
     |                     Operator Host Identity                    |
     |                                                               |
     |                                                               |
     |
     +---------------------------------------------------------------+

     Page 1 - Page N-1:                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                       Operator Signature                      |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

                    Figure 3: DRIP Operator ID Signature

4.3.  Message Set Signature

   When running under Extended Advertisements, the existing ASTM
   [F3411-19] Authentication Type 0x3 can be used to sign over the
   adjacent ASTM Messages in the Message Pack (0xF).

   The concatenation of all messages in the Message Pack (excluding
   Authentication) before signing MUST be in Message Type order and be
   placed between the UA HHIT and Signing Timestamp field.

      0                   1                   2                   3
      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
     +---------------+-----------------------------------------------+
     +---------------+---------------+---------------+---------------+
     |  Auth Header                                                               |
     |
     +---------------+                        UA Hierarchical                        |
     |                       Host Identity Tag                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                    DRIP Authentication Data                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------------------------------------------------------+

     Page N:
     |                                                               |
     |                          UA Signature                         |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

                    Figure 4: DRIP Message Set Signature

4.4.  Specific Method

   Under Specific Method (Authentication Type 0x5) is where the main set
   of DRIP Authentication Formats are defined.  These formats unlike the
   previous ones are more well defined and can include Forward Error
   Correction data.

4.4.1.  DRIP Frame Format

   This is specified when the SAM ID is DRIP Frame.  It is encapsulated
   by the ASTM Authentication Message (Section 3.3) and fills the
   Authentication Data / Signature field in Figure 1.

      0                   1                   2                   3
      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
     +---------------+-----------------------------------------------+
     |  Auth Header  |                                               |
     +---------------+                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                    Forward Error Correction    SAM ID     |                                               |
     +---------------+                                               |
     .                                                               .
     .                    DRIP Authentication Data                   .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                     Forward Error Correction                  .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+

     SAM ID (1 byte):
         The SAM ID (Specific Authentication Method ID) is
         defined by ASTM under AuthType 0x5 and values allocated
         by ICAO.

         For DRIP there are four SAM IDs allocated:

             SAM ID                       | Value
             -----------------------------+-------
             DRIP Frame                   |
     +---------------------------------------------------------------+ 0
             DRIP Header (1 byte):
            7     6     5     4     3     2 Wrapper                 | 1     0
         +-----+-----+-----+-----+-----+-----+-----+-----+
             DRIP Manifest                | FEC 2
             DRIP Link                    | 3

     DRIP Authentication Data (0 to 200 bytes):
         DRIP Authentication data.

     Forward Error Correction (0 to 161 bytes):
         Forward Error Correction data.

                        Figure 5: DRIP Frame Format

4.4.1.1.  Specific Authentication Method ID (SAM ID)

   Defined by ASTM (only under AuthType              |
         +-----+-----+-----+-----+-----+-----+-----+-----+ 0x5), values are allocated by
   ICAO.  For DRIP there are four SAM IDs: DRIP Frame, DRIP Wrapper,
   DRIP Manifest and DRIP Link.

4.4.1.2.  DRIP Authentication Data

   This field has a maximum size of 200 bytes.  If the data is less than
   the max and a page is only partially filled then the rest of the
   partially filled page must be null padded.  Note that the Length
   field in the Authentication Message is set to the length of the DRIP
   Authentication Data and MUST NOT include the Forward Error
   Correction.

   When possible the DRIP Broadcast Attestation Structure (Section 12)
   should be used in this space.

4.4.1.3.  Forward Error Correction

   This field has a maximum size of 161 bytes and SHOULD be page aligned
   at start.  The number of pages present after the data indicate the
   FEC (1 bit):
             Enabled [1] scheme.  When a single page of FEC is present an XOR operation
   MUST be used.  When there are multiple pages of FEC (2 or Disabled [0]. Signals if Page N more) a
   Reed Solomon method MUST be used.

   See Section 13 for more.

4.4.2.  DRIP Wrapper Format

   This is
             filled specified when the SAM ID is DRIP Wrapper.  It is
   encapsulated by the DRIP Frame (Section 4.4.1) and Broadcast
   Attestation Structure (Section 12); filling the Attestation Data
   (Section 12.2) field with XOR FEC.

         DRIP AuthType (7 bits):
             DRIP AuthType                        Values
             -------------                        ------
             0 Wrapped full (25-byte) ASTM Message(s)            0
             1 Wrapped Messages.  The minimum
   number of ASTM Message(s) Messages being 1
             2 Wrapped ASTM Message(s)            2
             3 Wrapped ASTM Message(s)            3
             4 Wrapped ASTM Message(s)            4
             5 Wrapped (Editors Note: Is this minimum 1 or
   0?) and the max being 4.  The encapsulated ASTM Message(s)            5
             8 Byte Manifest                      6
             4 Byte Manifest                      7
             Reserved (Wrapped Messages)          8-15
             Certificate: Registry on Aircraft    16
             Reserved (Certificates)              17-31
             Private Use                          32-63
             Reserved                             64-111
             Experimental Use                     112-127

     DRIP Authentication Data (200 bytes):
         DRIP Messages MUST be in
   Message Type order as defined by ASTM.  All message types except
   Authentication data. 0 to 200 bytes.

     Forward Error Correction (23 bytes):
         Optional (0x2) and signaled using Message Pack (0xF) are allowed.

   To determine the number of messages wrapped the receiver can check
   that the length of the Attestation Data (Section 12.2) field of the
   DRIP Header. Always last
         Authentication page.

                    Figure 2: Broadcast Attestation (Section 12) is a multiple of 25-bytes.

4.4.2.1.  Wrapper Limitations

   TODO

4.4.3.  DRIP General Frame Manifest Format

4.1.1.

   This format is specified when SAM ID is set to DRIP Header

   The Manifest.  It is
   encapsulated by the DRIP Header Frame (Section 4.4.1) and Broadcast
   Attestation Structure (Section 12); filling the Attestation Data
   (Section 12.2) field with 8-byte hashes of previous ASTM Messages.

   By hashing previously sent messages and signing them we gain trust in
   UAs previous reports.  An observer who has been listening for any
   considerable length of time can hash received messages and cross
   check against listed hashes.  This is used a way to signal what kind evade the limitation
   of Authentication under
   DRIP that a maximum of 4 messages in the message is using Wrapper Format and consists reduce overhead.

   (Editors Note: Manifests MUST NOT be of two fields.

4.1.1.1.  Forward Error Correction (Bit 8) a length multiple of 25-bytes
   or 48-bytes.)

4.4.3.1.  Hash Algorithms and Operation

   The Most Significant Bit hash algorithm used for the Manifest Message is the same hash
   algorithm used to signal if FEC in creation of the HHIT that is signing the Manifest.

   A standard HHIT would be using cSHAKE128 from [NIST.SP.800-185].
   With cSHAKE128, the hash is present computed as follows:

   cSHAKE128(Message, 128, "", "Remote ID Auth Hash")

4.4.3.2.  Pseudo-Blockchain Hashes

   Two special hashes are included in all Manifest messages; a previous
   manifest hash, which links to the
   final page of previous manifest message, as well
   as a current manifest hash.  This gives a pseudo-blockchain
   provenance to the Authentication Message.  It MUST manifest message that could be set to 1 traced back if FEC
   is being used.  This is only enabled under Bluetooth 4 the
   observer was present for extended periods of time.

   Creation:  During creation and signing of this message format this
      field MUST be set to 0 on Bluetooth 5 or Wifi NaN.

4.1.1.2.  DRIP AuthType (Bits 1-7)

   The lower 7 bits are used as 0.  So the DRIP AuthType signature will be based on this
      field denoting what
   Authentication type is being used.  There are 5 major areas carved
   out 0, as well as its own hash.  It is an open question of
      if we compute the DRIP AuthType defined by hash, then sign or sign then compute.

   Cycling:  There a few different ways to cycle this message.  We can
      "roll up" the following bitmaps:

                000 xxxx (0x00-0x0F): Wrapped Messages (16)
                001 xxxx (0x10-0x1F): Certificates (16)
                01x xxxx (0x20-0x3F): Private Use (32)
                1xx xxxx (0x40-0x6F): Reserved (48)
                111 xxxx (0x70-0x7F): Experimental Use (16)

                       Figure 3: DRIP Header Bitmasks

4.1.2.  DRIP Authentication Data hash of 'current' to 'previous' when needed or to
      completely recompute the hash.  This field has a maximum size mostly depends on the
      previous note.

4.4.3.3.  Manifest Limitations

   A potential limitation to this format is dwell time of 200 bytes. the UA.  If
   the data UA is less than
   the max and not sticking to a page is only partially filled general area then most likely the
   Observer will not obtain many (if not all) of the messages in the
   manifest.  Without the rest original messages received no verification can
   be done.  Examples of such scenarios include delivery or survey UA.

   Another limitation is the
   partially filled page must be null padded. length of hash, which is discussed in
   Section 8.

4.4.4.  DRIP Link Format

   This section format is generally filled with either specified when SAM ID is set to DRIP Link.  It is
   encapsulated by the Wrapper DRIP Frame (Section 4.2) or the 4.4.1) and Broadcast
   Attestation Frame Structure (Section 4.3).

4.1.3.  Forward Error Correction

   To help Bluetooth (specifically Bluetooth 4) achieve 12) but the attestation has already
   taken place, thus the UA need not dynamically sign the structure.

   See Broadcast Attestation as defined in [drip-rid] and Section 11.6.

4.4.4.1.  Link Limitations

   TODO

5.  Transport Methods & Recommendations

5.1.  Legacy Advertisements (Bluetooth 4.X)

   With Legacy Advertisements the goal of is to attempt to bring reliable
   receipt of the paged messages a Authentication Message.  Forward Error
   Correction (FEC)
   scheme is introduced and (Section 4.4.1.3) MUST be used for enabled when using Legacy
   Advertising
   (Bluetooth 4) and MUST NOT be used for Extended Advertising
   (Bluetooth 5, Wifi NaN) under DRIP.

4.1.3.1.  Encoding

   A compliant implementation of this standard MUST use XOR for the FEC.
   When generating the parity the first byte methods (such as Bluetooth 4.X).

   Under ASTM Bluetooth 4.X rules, transmission of dynamic messages are
   at least every 1 second while static messages (which is what
   Authentication
   Page is classified under) are sent at least every 3
   seconds.

   Under DRIP the Certificate Message MUST be exclude from transmitted to properly
   meet the XOR operation.  For pages GEN 1 through N
   this leaves and GEN 3 requirement.

   The ASTM Message Wrapper and Manifest both satisfy the data portion GEN 2
   requirement.  At least one MUST be implemented to comply with the GEN
   2 requirement.

   A single Manifest can carry at most (using the full 10 page limit and
   8 byte hashes) 12 unique hashes of the page while page 0 will include previously sent messages (of any
   type).  This results in a
   number total of headers along with 17 bytes 22 (12 + 10) frames of data.

   To generate the parity a simple XOR operation using Bluetooth
   data being transmitted over Bluetooth.

   In comparison the previous and
   current page is used.  For page 0, Message Wrapper sends 6 pages (each a 23 byte null pad is used single frame)
   for each wrapped message.  For backwards compatibility the
   previous page.
   implementation should also send the standard ASTM message that was
   wrapped for non-DRIP compliant receivers to obtain.  This method
   results in 84 total Bluetooth frames (12 + (12 * 6)) sent.

   The resulting 23 bytes question of parity which is appended in one
   full page (always the last) allowing for recovery when any single
   page better suited is lost in transmission.

4.1.3.2.  Decoding

   Due up to the nature of Bluetooth 4 and implementation.

5.2.  Extended Advertisements (Bluetooth 5.X, WiFi NaN, WiFi Beacon)

   Under the existing ASTM paging
   structure an optimization can be used.  If specification, Bluetooth 5 or WiFi NaN transport of
   Remote ID is to use the Message Pack (Type 0xF) format for all
   transmissions.  Under Message Pack all messages are sent together (in
   Message Type order) in a single Bluetooth frame fails
   its CRC check, then the (up to 9 single frame is dropped without notification
   equivalent messages).  Message Packs are required by ASTM to the
   upper protocol layers.  From the Remote ID perspective this means the
   loss of be sent
   at a complete frame/message/page.  In Authentication Messages,
   each page is already numbered so the rate of 1 per second (like dynamic messages).

   Without any fragmentation or loss of a page allows the
   receiving application to build a "dummy" page filling the
   Authentication Data field (and ASTM Authentication Headers fields if
   page 0) pages with nulls.

   Using the same methods transmission Forward
   Error Correction (Section 4.4.1.3) MUST NOT be used as encoding, an XOR operation it is used between
   impractical.

5.3.  DRIP Recommendations

   For DRIP it is RECOMMENDED the current page).  The resulting 23 bytes is following Authentication Formats are
   sent:

   1.  DRIP Link using the data Broadcast Attestation of HID Root and the
   missing page.

   If page 0 is being reconstructed an additional check CAA

   2.  DRIP Link using the Broadcast Attestation of CAA and the Page
   Count, USS

   3.  DRIP Link using the Broadcast Attestation of USS and the UA

   4.  Any other DRIP Authentication Format where the UA is dynamically
       signing data

6.  ICAO Considerations

   DRIP requests the following SAM IDs to check against how many pages are actually present, MUST be
   performed allocated:

   1.  DRIP Frame

   2.  DRIP Wrapper

   3.  DRIP Manifest

   4.  DRIP Link

7.  IANA Considerations

   This document does not require any actions by IANA.

8.  Security Considerations
8.1.  Manifest Hash Length

   For DRIP Manifest an 8-byte hash length has been selected by the
   authors for sanity.  An additional check on a number of reasons.

   1.  Hash lengths smaller than 8-bytes (for example 4-bytes) were
       originally contemplated but ruled out by comments by various
       cryptographers.  The main concern raised in this forum was that
       the Data Length field
   can length of hash would not provide strong resistance against
       collision rate.  The authors also be performed, but is after further review agreed
       with this and also realized operationally it was not required.

4.1.3.3.  Limitations & Recommendations

   If necessarily
       viable.  While 4-byte hashes would allow more than one page is lost (>1/5 for 5 page messages, >1/10 for 10
   page messages) than messages to be
       filled into a single DRIP Manifest payload (up to 22 individual
       hashes) the error rate length of time for the link is already beyond
   saving and the application has more issues UA to deal with.

   In theory under Bluetooth 4 up stay in a single place
       where the Observer would receive all the originally messages to 15 pages Authentication could be
   sent (9 pages reserved
       rehash to Authentication and 6 pages reserved for
   Forward Error Correction).  It is currently recommended however for verify such a
   max of 10 pages total.

4.2.  DRIP Wrapper Frame

   This format MUST be encapsulated message was impractical.

   2.  Hash lengths larger than 8-bytes (for example 16-bytes) were also
       considered by the General Frame (Section 4.1)
   and reside in its data field (Section 4.1.2).

   Typically authors.  These got the DRIP Header is set in approval of the
       cryptographers but the range number of 0x00 through 0x0F
   (FEC disabled) or 0x80 through 0x8F (FEC enabled).

      0                   1                   2                   3
      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 hashes to send became much lower
       (only 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                        UA Hierarchical                        |
     |                       Host Identity Tag                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                      Authentication Data                      .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                            Signature                          |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     UA Hierarchial Host Identity Tag (16 bytes):
         The UAs HHIT in byte form. Hashed from individual hashes).  While this lower number is a more
       reasonable number of original messages the EdDSA25519
         public key.

     Trust Timestamp (4 bytes):
         Timestamp denoting current time plus an offset Observer would have to trust
         message to.

     Authentication Data (116 bytes):
         Opaque authentication data using DRIP format specified in
         the
       capture it would also mean that potentially more DRIP Header. 0 Manifests
       would need to 116 bytes.

     Signature (64 bytes):
         Signature over preceding fields using be sent.  Overall the EdDSA25519
         keypair increase length of the UA.

                    Figure 4: DRIP Wrapper Frame Format

4.2.1.  UA Hierarchical Host Identity Tag

   To avoid needing hash
       did not operationally justify the UAs HHIT via cost.

   3.  Simplifying the ASTM Basic ID in a detached
   fashion current design and locking it into using the same
       hash as the 16 byte HHIT instead of the UA is included allowing for agility in either hash
       algorithm or length seemed more realistic to the wrapper frame. authors today.

8.2.  Replay Attacks

   The HHIT for astute reader may note that the UA (and other entities DRIP Link messages, which are
   recommended to be sent under DRIP, are static in the RID nature and greater UTM
   system under DRIP) is contain
   various timestamps.  These Attestation Link message can easily be
   replayed by an enhancement of the Host Identity Tag (HIT)
   [RFC7401] introducing hierarchy (and how they attacker who has copied them from previous broadcasts.
   There are used in UAS RID) as
   defined two things to mitigate this in [drip-rid].

4.2.2.  Trust Timestamp

   The Trust Timestamp DRIP:

   1.  If an attacker (who is of smart and spoofs more than just the format defined UAS
       ID/data payloads) willing replays an Attestation Link message
       they have in [F3411-19].  That principle actually helped by ensuring the message is
   a UNIX timestamp offset
       sent more frequently and be received by 01/01/2019 00:00:00.  An additional offset potential Observers.

   2.  Under DRIP it is then added RECOMMENDED to push send more than just DRIP Link
       messages, specifically those that sign over changing data using
       the timestamp a short time into current session keypair, and those messages are sent more
       frequently.  An aircraft beaconing these messages then actually
       signing other messages using the future to
   avoid replay attacks.

   When wrapping a Vector (Position/Location) Message keypair validates the payload WILL
   contain (by ASTM rules) constantly changing data, this includes its
   own timestamp.  This timestamp is only 2 bytes, which is easily
   attacked and only expresses data
       receiver by an Observer.  An UA who does not either run DRIP
       themselves or does not have possession of the same private key,
       would be clearly exposed upon signature verification.

8.3.  Trust Timestamp Offsets

   Note the 1/10th discussion of Trust Timestamp Offsets here is in context of seconds since
   the last
   hour.

   Other ASTM message types, such as Basic ID DRIP Wrapper (Section 4.4.2) and Self-ID are static DRIP Manifest (Section 4.4.3)
   messages.  For DRIP Link (Section 4.4.4) messages with no changing data.  To protect a replay of these signed
   messages the Trust Timestamp is offsets are
   set by the field during signing to be
   guaranteed Attestor (typically a registry) and have their own set of
   considerations as seen in (TODO: link to change. registry draft security
   considerations here).

   The offset used against of the UNIX timestamp is not defined in this
   document.  Best practices to identify Trust Timestamp (defined as a acceptable very short Expiration
   Timestamp) is one that needs careful consideration for any
   implementation.  The offset should be
   used taking into consideration the UA environment, and propagation
   characteristics of the messages being sent.

4.2.3.  Wrapped Authentication Data

   This field has a maximum of 116 bytes in length.

4.2.3.1.  Wrapped ASTM Message Formats

   When wrapping shorter than any ASTM Messages given flight
   duration (typically less than an hour) but be long enough to be
   received and filling the Wrapped
   Authentication Data field under DRIP the messages MUST processed by Observers (larger than a few seconds).  It
   recommended that 3-5 minutes should be sufficient to serve this
   purpose in Message
   Type order as defined any scenario, but is not limited by ASTM.  All message types except
   Authentication (0x2) and Message Pack (0xF) are allowed.

4.2.3.1.1.  0 Wrapped ASTM Message(s)

   This payload type MUST only be used under Extended Advertisement
   (Bluetooth 5.X design.

9.  Acknowledgments

   Ryan Quigley and Wifi NaN).

   The Wrapped Authentication Data is the concatenation James Mussi of all messages AX Enterprize, LLC for early
   prototyping to find holes in the Message Pack (excluding Authentication) in Message Type order.
   No actual data payload is present draft specifications.

   Soren Friis for pointing out that WiFi protocols would not give
   access to the MAC Address, originally used in this format as calculation of the
   hashes for DRIP Manifest.  Also for confirming that Message Packs
   (0xF) can only carry up to 9 ASTM frames worth of data is found
   outside the (9
   Authentication Message in pages) - this drove the same requirement for max page
   length of Authentication Data itself.

10.  Appendix A: Thoughts on ASTM Authentication Message Pack.

   The DRIP Header

   (Editor Note: is set to 0x00 (0).

4.2.3.1.2.  1 this valid anymore to 4 Wrapped ASTM Message(s)

   This payload type can be used on either Legacy or Extended
   Advertisements. keep?)

   The DRIP Header is set to 0x81-0x84 (129-134) when using Legacy
   Advertisements (FEC is enabled) and 0x01-0x04 (1-4) when using
   Extended Advertisements (FEC is disabled).

4.2.3.1.3.  5 Wrapped format standardized by the ASTM Message(s)

   Editors Note: This payload type does not currently fit is designed with a few major
   considerations in mind, which the 116
   byte limit authors of this document feel put
   significant limitations on the Wrapper Frame.  If the ASTM relaxes expansion of the Max Page
   Count limit for Legacy Advertisements to use all 15 pages then standard.

   The primary consideration (in this context) is possible. the use of the
   Bluetooth 5.X Extended Frame format.  This method allows for a 255
   byte payload type MUST only to be used on Legacy Advertisements
   (Bluetooth 4.X).  It requires 11 pages sent in what the ASTM refers to complete. as a "Message
   Pack".

   The DRIP Header idea is set to 0x85 (133).

   This payload type allows in Legacy Advertisements include up to have a pseudo-
   Message Pack like what is found in Extended Advertisements.

4.2.3.1.4.  Limitations

   When wrapping a single five standard ASTM Message the 25 byte payload actually
   causes an inefficiency in the framing format, create a whole page
   unused except for a single byte.  This can be optimized by removing a
   single byte out of the wrapped message but creates an issue on the
   receiver Broadcast RID
   messages (each of knowing which byte was removed.

   When sending a Location Message (Message Type 0x1) are 25 bytes) plus a single byte can
   be removed at the end authentication
   message (5 pages of 25 bytes each) in the message as it Message Pack.  The
   reasoning is currently unused.  Many
   other messages in then the Authentication Message is for the ASTM entire
   Message set however do not Pack.

   The authors have no issues with this proposed approach; this
   ability.  The first byte can not be removed as it is the key to know
   how a
   valid format to decode use for the message.

4.2.3.2.  Manifests

   Manifests fill Authentication Message provided by the
   ASTM.  However, by limiting the Wrapped Authentication Data field with hashes Message to ONLY five
   pages in the standard it ignores the possibility of
   previously send messages.

   By hashing previously sent messages other formatting
   options to be created and signing them we gain trust used.

   Another issue with this format, not fully addressed in
   UAs previous reports.  An observer who has been listening for any
   considerable length of time this document
   is fragmentation.  Under Bluetooth 4.X, each page is sent separately
   which can hash received messages and cross
   check against listed hashes.

4.2.3.2.1.  Hash Algorithm and Operation

   The hash algorithm used for result in lose of pages on the Manifest Message receiver.  This is
   disastrous as the same hash
   algorithm used in creation loss of even a single page means any signature is
   incomplete.

   With the HHIT that current limitation of 5 pages, Forward Error Correction
   (FEC) is signing nearly impossible without sacrificing the Manifest.

   A standard HHIT amount of data
   sent.  More pages would allow FEC to be using cSHAKE128 from [NIST.SP.800-185].
   With cSHAKE128, performed on the hash is computed as follows:

   cSHAKE128(MAC Address|Message, 8*H-Len, "", "RemoteID Auth Hash")

   The message MAC Address
   Authentication Message pages so loss of pages can be mitigated.

   All these problems are further amplified by the transmitter is prepended speed at which UA fly
   and the Observer's position to receive transmissions.  There is no
   guarantee that the
   message, as Observer will receive all the pages of even a 5
   page Authentication Message in the MAC Address time it takes a UA to traverse
   across their line of sight.  Worse still is the only information that links is not including
   other UA in the area, which congests the spectrum and could cause
   further confusion attempting to collate messages from a specific various UA.

   Editors Note: It should be noted that for Bluetooth mediums this
   This specific problem is
   valid - however Wifi NaN does not give the receiver device the
   transmitters MAC Address - making out of scope for this impossible.  Either MAC
   Address document and our
   solutions in general, but should be removed entirely or something different be used in
   its place to link to noted as a given UA.  Thanks Soren Friis for pointing
   this out.

4.2.3.2.2. design consideration.

11.  Appendix B: DRIP Attestations

11.1.  Self-Attestation (Axx)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                          Hierarchical                         |
     |                       Host Identity Tag                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                          Host Identity                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                            Signature                          |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 120-bytes

                      Figure 6: DRIP Self-Attestation

11.2.  Attestation (Axy)
      0                   1                   2                   3
      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 Byte 9 0 1
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              Axx                              .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              Ayy                              .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by X                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 312-bytes

                         Figure 7: DRIP Attestation

11.3.  Concise Attestation (C-Axy)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                   Hash                                                               |
     |                          Hierarchical                         |
     |                    Host Identity Tag of Previous Manifest X                     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                    Hash                                                               |
     |                          Hierarchical                         |
     |                    Host Identity Tag of Current Manifest Y                     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Message Hash 1                      Trust Timestamp by X                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                         Message Hash 2                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 104-bytes

                     Figure 8: DRIP Concise Attestation

11.4.  Mutual Attestation (M-Axy)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              Axy                              .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                        Message Hash 12                      Trust Timestamp by Y                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Y                    |
     +---------------+---------------+---------------+---------------+

     DRIP Header:
         With FEC: 0x87 [135] (RECOMMENDED)
         Without FEC: 0x07 [7]

     Hash of Previous Manifest: (8 bytes)
         A hash of the previously sent Authentication message.

     Hash of Current Manifest: (8 bytes)
         A hash of the current Authentication message.

     Message Hash: (8 bytes)
         A hash of a previously sent message. 12 max.
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Y                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 384-bytes

                     Figure 5: 4 Byte Manifest

4.2.3.2.3.  4 Byte 9: DRIP Mutual Attestation

11.5.  Link Attestation (L-Axy)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                   Hash of Previous Manifest                   |
     +---------------+---------------+---------------+---------------+
     |                    Hash of Current Manifest                   |
     +---------------+---------------+---------------+---------------+
     |                         Message Hash 1                        |
     +---------------+---------------+---------------+---------------+
     |                         Message Hash 2                        |
     +---------------+---------------+---------------+---------------+
     .                                                               .
     .                                                               .
     .                                                               .
     +---------------+---------------+---------------+---------------+
     |                        Message Hash 27                        |
     +---------------+---------------+---------------+---------------+

     DRIP Header:
         With FEC: 0x86 [132] (RECOMMENDED)
         Without FEC: 0x06 [6]

     Hash of Previous Manifest: (4 bytes)
         A hash of the previously sent Authentication message.

     Hash of Current Manifest: (4 bytes)
         A hash of the current Authentication message.

     Message Hash: (4 bytes)
         A hash of a previously sent message. 27 max.

                         Figure 6: 4 Byte Manifest

4.2.3.2.4.  Pseudo-Blockchain Hashes

   Two special hashes are included in all Manifest messages; a previous
   manifest hash, which links to the previous manifest message, as well
   as a current manifest hash.  This gives a pseudo-blockchain
   provenance to the manifest message that could be traced back if the
   observer was present for extended periods of time.

   Creation:  During creation and signing of this message format this
      field MUST be set to 0.  So the signature will be based on this
      field being 0, as well as its own hash.  It is an open question of
      if we compute the hash, then sign or sign then compute.

   Cycling:  There a few different ways to cycle this message.  We can
      "roll up" the hash of 'current' to 'previous' when needed or to
      completely recompute the hash.  This mostly depends on the
      previous note.

4.2.3.2.5.  Manifest Limitation

   A potential limitation to this format is dwell time
     |                                                               |
     .                                                               .
     .                             C-Axy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Y                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Y                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Y                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 176-bytes

                      Figure 10: DRIP Link Attestation

11.6.  Broadcast Attestation (B-Axy)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                          Hierarchical                         |
     |                    Host Identity Tag of the UA.  If
   the UA is not sticking to a general area then most likely the
   Observer will not obtain many (if not all) X                     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                          Hierarchical                         |
     |                    Host Identity Tag of the messages in the
   manifest.  Without the original messages received no verification can
   be done.  Examples Y                     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                       Host Identity of such scenarios include delivery or survey UA.

4.2.4.  Wrapper Y                      |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by X                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature

   The wrapper signature is generated using the private key half of the
   the UAs by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 136-bytes

                   Figure 11: DRIP Broadcast Attestation

11.7.  Link Certificate (L-Cxy)

      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                          Hierarchical                         |
     |                    Host Identity (HI) Tag of Z                     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             L-Axy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Z                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Z                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 264-bytes

                      Figure 12: DRIP Link Certificate

11.8.  Mutual Certificate (M-Cxy)
      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              Azz                              .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             M-Axy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Z                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Z                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 264-bytes

                     Figure 13: DRIP Mutual Certificate

11.9.  Example Registration with Attestation

   1.  X generates Axx and is done over all preceding data.
   ASTM/DRIP Headers are exclude from this operation only information
   within the Wrapper Fame (Section 4.2) is signed.

4.3. Y generates Ayy

   2.  Y sends Ayy to X
   3.  X verified Ayy; composes Axy, C-Axy, B-Axy; sends Axy, C-Axy,
       B-Axy and B-Axy's from parents

   4.  Y composes M-Axy and L-Axy

   5.  Y broadcasts B-Axy's

12.  Appendix C: DRIP Broadcast Attestation Frame

   This format MUST be encapsulated by Structure

   When possible the General Frame (Section 4.1)
   and reside in its data field (Section 4.1.2).

   This following format is typically should be used to form a complete certificate using
   attestation data from a Registry defined in [identity-claims].  The
   DRIP Header is normally in the range of 0x10 through 0x1F (FEC
   disable) or 0x90 through 0x9F (FEC enabled). DRIP
   Authentication Data (Section 4.4.1.2) field.

      0                   1                   2                   3
      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                      Attestor Hierarchical                    |
     |                       Host Identity Tag                       |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                        Attestation Data                       .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Expiration                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                            Signature                                                               |
     |                        Attestor Signature                     |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Attestation Data: (up to 132 bytes):
         Data the UA asserts claim to.
         Up to 132 bytes in length.

     Expiration Timestamp (4 bytes):
         Generated by the UA to protect against replay attacks.

     Signature (64 bytes):
         Signature over preceding fields using the EdDSA25519
         keypair of the UA.

                     Figure 7: DRIP Attestation Format

4.3.1.  Attestation Data

   Any data up to 132 bytes in length that the UA wishes to assert truth
   to.

4.3.1.1.  DRIP Certificate

   This payload type can be used in either Legacy or Extended
   Advertising.  It is used to grant the ability to authenticate UA
   Remote ID when the receiving device of the observer (e.g. a
   smartphone with a dedicated RID application) has no Internet service
   (e.g.  LTE signal).

   The DRIP Header is set to 0x90 (144) when used for Legacy
   Advertisements and 0x10 (16) for Extended Advertisements.

   The Attestation Data field is filled with the Attestation: Registry
   on Aircraft (Section 3.2.2 Attestation: X on Y (Offline Form) from
   [identity-claims]).  This is binding claim between the Registry and
   the Aircraft, asserting the relationship between the two entities.
   It also provides the UA Host Identity to allow signature verification
   of messages signed by the UA.  Also included in its structure is the
   HHIT of the Registry to check the local shortlist of Registries that
   the Observer device trusts (mapping HHITs to HIs).

   More details about this Attestation and other certificates and the
   provisioning process can be found
     |                                                               |
     +---------------+---------------+---------------+---------------+
     Attestor Hierarchial Host Identity Tag (16 bytes):
         The Attestors HHIT in [identity-claims].

4.3.2.  Expiration byte form (network byte order).

     Attestation Data (0 to 112 bytes):
         Opaque attestation data.

     Trust Timestamp

   Generated by the UA during the creation of the Authentication
   message.  It is set a short (4 bytes):
         Timestamp denoting recommended time into the future to protect against
   replay attacks of this DRIP format.

   It shares the same format as the Trust trust data to.

     Signing Timestamp (Section 4.2.2).

4.3.3.  Attestation (4 bytes):
         Current time at signing.

     Attestor Signature

   Performed by the UA (64 bytes):
         Signature over preceding fields using the onboard keypair which matches the HHIT
   in the Basic ID Message (0x0).

5.  Transport Methods & Recommendations

5.1.  Legacy Advertisements (Bluetooth 4.X)

   With Legacy Advertisements the goal is to attempt to bring reliable
   receipt of
         the paged Authentication Message.  Forward Error
   Correction (Section 4.1.3) MUST be enabled when using Legacy
   Advertising methods (such as Bluetooth 4.X).

   Under ASTM Bluetooth 4.X rules, transmission of dynamic messages are
   at least every 1 second while static messages (which is what
   Authentication is classified under) are sent at least every 3
   seconds.

   Under Attestor.

            Figure 14: DRIP the Certificate Message MUST be transmitted to properly
   meet the GEN 1 and GEN 3 requirement. Broadcast Attestation Data Structure

12.1.  Attestor Hierarchical Host Identity Tag

   The ASTM Message Wrapper and Manifest both satisfy the GEN 2
   requirement.  At least one MUST be implemented to comply with the GEN
   2 requirement.

   A single Manifest can carry at most (using HHIT is an enhancement of the full 10 page limit Host Identity Tag (HIT) [RFC7401]
   introducing hierarchy and
   8 byte hashes) 12 unique hashes of previously sent messages (of any
   type).  This results how they are used in UAS RID as defined in
   [drip-rid].

12.2.  Attestation Data

   This field has a total of 22 (12 + 10) frames maximum of Bluetooth 112 bytes in length.  It is nominally
   filled with data as defined by the SAM ID being transmitted over Bluetooth.

   In comparison set or other sub-
   multiplexer in the Message Wrapper sends 6 pages (each authentication payload.

12.3.  Trust Timestamp

   The Trust Timestamp is of the format defined in [F3411-19].  That is
   a single frame)
   for each wrapped message.  For backwards compatibility UNIX timestamp offset by 01/01/2019 00:00:00.  An additional offset
   is then added to push the
   implementation should also send timestamp a short time into the standard ASTM message that was
   wrapped for non-DRIP compliant receivers future to obtain.  This method
   results in 84 total Bluetooth frames (12 + (12 * 6)) sent.
   avoid replay attacks.

   The question of which is better suited offset used against the UNIX timestamp is up not defined in this
   document.  Best practices to identify a acceptable offset should be
   used taking into consideration the implementation.

5.2.  Extended Advertisements (Bluetooth 5.X UA environment, and Wifi NaN)

   Under the ASTM specification, Bluetooth 5 or Wifi NaN transport propagation
   characteristics of
   Remote ID is to use the Message Pack (Type 0xF) format for all
   transmissions.  Under Message Pack all messages are sent together (in
   Message Type order) being sent.

12.4.  Signing Timestamp

   Follows the format defined in [F3411-19].  That is a single Bluetooth frame (up to 9 single frame
   equivalent messages).  Message Packs are required UNIX timestamp
   offset by ASTM to 01/01/2019 00:00:00.

12.5.  Attestor Signature

   The signature is generated over all the preceding data.  ASTM/DRIP
   Headers are exclude from this operation only information within the
   Broadcast Attestation Structure (Section 12) is signed.

13.  Appendix D: Forward Error Correction

   (Editors Note: move specifics of FEC (everything below) into its own
   draft for titled Integrity Protection)

   Remote ID data can be sent
   at a rate of 1 per second (like dynamic messages).

   Without any fragmentation or loss of pages across many different broadcast link
   media, all with different characteristics.  To enable robustness in
   Remote ID transmission media that has Forward Error Correction (Section 4.1.3) MUST NOT
   capability SHOULD be used as it used.

   In cases where FEC is
   impractical.

6.  ASTM Considerations

   *  Increase Authentication Max Page Count from 5 to 10.  Legacy
      Advertising can use all 10 while Extended Advertising has a
      maximum of 9 due to Bluetooth 5 limitations.

   *  Allocate Authentication Type 0x5 for DRIP from ASTM AuthType
      field.

7.  IANA Considerations

   This document does not require any actions by IANA.

8.  Security Considerations

   TODO

   (Ed.  Note: Hash lengths (length vs strength/collision rate); replay
   attacks with timestamps; static Cra (issue but nulled if UA signing
   other stuff dynamically meaning signatures will fail as HI won't
   match - this is probably a deeper discussion topic for provisioning
   security considerations when we get to there))

9.  Acknowledgments

   Ryan Quigley and James Mussi available below the equivalent of AX Enterprize, LLC for early
   prototyping to find holes in the draft specifications.

10.  Appendix A: Thoughts on ASTM
   transport layer (known as Legacy Advertisements) DRIP Authentication Message

   The format standardized by the ASTM
   REQUIRES that an application level FEC scheme is designed with a few major
   considerations in mind, which used.  In cases
   where FEC is available below the authors equivalent of this document feel put
   significant limitations on the expansion of transport layer
   (known as Extended Advertisements) DRIP MUST NOT use any application
   level FEC and instead SHALL rely on the standard.

   The primary consideration (in this context) is lower layers FEC
   functionality.

   For current Remote ID the use of media options are the following:

   Legacy Advertisements:  Bluetooth 5.X 4.X

   Extended Frame format.  This method allows for a 255 Advertisements:  WiFi NAN, WiFi Beacon, Bluetooth 5.X

   (Editors Note: add in self-protecting and more-than-self-protecting
   options, with their justifications)

13.1.  Encoding

13.1.1.  Single Page FEC

   When generating the parity the first byte payload to of every Authentication
   Page MUST be sent in what exclude from the ASTM refers to as a "Message
   Pack".

   The idea is to include up to five standard ASTM Broadcast RID
   messages (each XOR operation.  For pages 1 through N
   this leaves the data portion of which are 25 bytes) plus the page while page 0 will include a single authentication
   message (5 pages
   number of 25 headers along with 17 bytes each) in of data.

   To generate the Message Pack.  The
   reasoning is then parity a simple XOR operation using the Authentication Message previous and
   current page is used.  For page 0, a 23 byte null pad is used for the entire
   Message Pack.
   previous page.  The authors have no issues with this proposed approach; this resulting 23 bytes of parity is a
   valid format to use appended in one
   full page (always the last) allowing for recovery when any single
   page is lost in transmission.

13.1.2.  Multi Page FEC

   TODO (Reed Solomon)

13.2.  Decoding

   Due to the Authentication Message provided by nature of Bluetooth 4 and the
   ASTM.  However, by limiting existing ASTM paging
   structure an optimization can be used.  If a Bluetooth frame fails
   its CRC check, then the Authentication Message frame is dropped without notification to ONLY five
   pages in the standard it ignores
   upper protocol layers.  From the possibility of other formatting
   options to be created and used.

   Another issue with this format, not fully addressed in Remote ID perspective this document
   is fragmentation.  Under Bluetooth 4.X, means the
   loss of a complete frame/message/page.  In Authentication Messages,
   each page is sent separately
   which can result in lose of pages on the receiver.  This is
   disastrous as already numbered so the loss of even a single page means any signature is
   incomplete.

   With allows the
   receiving application to build a "dummy" page filling the current limitation of 5 pages, Forward Error Correction
   (FEC)
   Authentication Data field (and ASTM Authentication Headers fields if
   page 0) with nulls.

   If page 0 is nearly impossible without sacrificing the amount being reconstructed an additional check of data
   sent.  More pages would allow FEC the Page
   Count, to check against how many pages are actually present, MUST be
   performed for sanity.  An additional check on the
   Authentication Message pages so loss of pages can Data Length field
   SHOULD also be mitigated.

   All these problems are further amplified by the speed at which UA fly
   and performed.

13.2.1.  Single Page FEC

   Using the Observer's position to receive transmissions.  There same methods as encoding, an XOR operation is used between
   is no
   guarantee that the Observer will receive all current page).  The resulting 23 bytes is the pages data of even a the
   missing page.

13.2.2.  Multi Page FEC

   TODO (Reed Solomon)

13.3.  FEC Limitations

   If more than one page is lost (>1/5 for 5 page Authentication Message in messages, >1/10 for 10
   page messages) than the time it takes a UA to traverse
   across their line error rate of sight.  Worse still is that is not including
   other UA in the area, which congests the spectrum link is already beyond
   saving and could cause
   further confusion attempting the application has more issues to collate messages from various UA.
   This specific problem is out of scope for deal with.

   (Editors Note: Is this document and our
   solutions in general, valid anymore, for XOR yes but should be noted as a design consideration.

11. for multi-page
   FEC?)

14.  References

11.1.

14.1.  Normative References

   [F3411-19] "Standard Specification for Remote ID and Tracking",
              February 2020.

   [NIST.SP.800-185]
              Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived
              Functions: cSHAKE, KMAC, TupleHash and ParallelHash",
              DOI 10.6028/nist.sp.800-185, NIST
              Special Publication SP 800-185,
              DOI 10.6028/nist.sp.800-185, December 2016,
              <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-185.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.

14.2.  Informative References

   [drip-requirements]
              Card, S., S. W., Wiethuechter, A., Moskowitz, R., and A.
              Gurtov, "Drone Remote Identification Protocol (DRIP)
              Requirements", Work in Progress, Internet-Draft, draft-
              ietf-drip-reqs-06, 1 November 2020, <http://www.ietf.org/
              internet-drafts/draft-ietf-drip-reqs-06.txt>.
              ietf-drip-reqs-13, 14 June 2021,
              <https://www.ietf.org/archive/id/draft-ietf-drip-reqs-
              13.txt>.

   [drip-rid] Moskowitz, R., Card, S., S. W., Wiethuechter, A., and A.
              Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, draft-
              ietf-drip-uas-rid-01,
              draft-ietf-drip-uas-rid-01, 9 September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-drip-uas-
              rid-01.txt>.
              <https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
              01.txt>.

   [identity-claims]
              Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
              Identity Claims", Work in Progress, Internet-Draft, draft-
              wiethuechter-drip-identity-claims-03, 2 November 2020,
              <http://www.ietf.org/internet-drafts/draft-wiethuechter-
              drip-identity-claims-03.txt>.
              <https://www.ietf.org/archive/id/draft-wiethuechter-drip-
              identity-claims-03.txt>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

Authors' Addresses
   Adam Wiethuechter
   AX Enterprize, LLC
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: adam.wiethuechter@axenterprize.com

   Stuart Card
   AX Enterprize, LLC
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: stu.card@axenterprize.com

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI 48237
   United States of America

   Email: rgm@labs.htt-consult.com