DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9886.
|
|
|---|---|---|---|
| Authors | Adam Wiethuechter , Jim Reid | ||
| Last updated | 2022-12-05 | ||
| Replaces | draft-wiethuechter-drip-registries | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Early review
(of
-19)
by Ron Bonica
On the right track
DNSDIR Early review
(of
-18)
by David Blacka
On the right track
DNSDIR Early review
(of
-09)
by Tim Wicinski
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9886 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-drip-registries-07
drip Working Group A. Wiethuechter
Internet-Draft AX Enterprize, LLC
Intended status: Informational J. Reid
Expires: 8 June 2023 RTFM llp
5 December 2022
DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-07
Abstract
This document describes the high level architecture for the
registration and discovery of DRIP Entity Tags (DETs) using DNS.
Discovery of DETs and their artifacts are through the existing DNS
structure and methods by using FQDNs. A general overview of the
interfaces required between involved components is described in this
document with supporting documents giving technical specifications.
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 8 June 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wiethuechter & Reid Expires 8 June 2023 [Page 1]
Internet-Draft DETIM Architecture December 2022
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Abstract Process and Reasoning . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Required Terminology . . . . . . . . . . . . . . . . . . 5
3.2. Additional Definitions . . . . . . . . . . . . . . . . . 6
4. DIME Roles . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Apex . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Registered Assigning Authority (RAA) . . . . . . . . . . 7
4.2.1. ICAO Registry of Manufacturers (IRM) . . . . . . . . 8
4.3. Hierarchial HIT Domain Authority (HDA) . . . . . . . . . 8
4.3.1. Manufacturers Registry of Aircraft (MRA) . . . . . . 9
4.4. Role Abbreviation in DETs . . . . . . . . . . . . . . . . 9
5. DIME Architecture . . . . . . . . . . . . . . . . . . . . . . 9
5.1. DRIP Provisioning Agent (DPA) . . . . . . . . . . . . . . 11
5.2. Registry . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Name Server (NS) . . . . . . . . . . . . . . . . . . . . 11
5.4. DRIP Information Agent (DIA) . . . . . . . . . . . . . . 12
5.5. Registration Data Directory Service (RDDS) . . . . . . . 12
6. Registration/Provisioning Process . . . . . . . . . . . . . . 12
6.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Operator . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Session ID . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. UA Based . . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. UAS Based . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Child DIME . . . . . . . . . . . . . . . . . . . . . . . 19
7. Differentiated Access Process . . . . . . . . . . . . . . . . 20
8. DRIP in the Domain Name System . . . . . . . . . . . . . . . 21
8.1. DRIP Fully Qualified Domain Names . . . . . . . . . . . . 21
8.1.1. DRIP Entity Tag . . . . . . . . . . . . . . . . . . . 21
8.1.2. Serial Number . . . . . . . . . . . . . . . . . . . . 22
8.2. Supported DNS Records . . . . . . . . . . . . . . . . . . 23
8.2.1. HIP . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.2. TLSA . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.3. CERT . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.4. SVR . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Endorsements . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Endorsement Structure . . . . . . . . . . . . . . . . . . 25
Wiethuechter & Reid Expires 8 June 2023 [Page 2]
Internet-Draft DETIM Architecture December 2022
9.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . 26
9.1.2. Evidence . . . . . . . . . . . . . . . . . . . . . . 26
9.1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.4. Signature . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Self-Endorsement (SE-x) . . . . . . . . . . . . . . . . . 27
9.3. Generic Endorsement (GE-x.y) . . . . . . . . . . . . . . 27
9.4. Concise Endorsement (CE-x.y) . . . . . . . . . . . . . . 28
9.5. Mutual Endorsement (ME-x.y) . . . . . . . . . . . . . . . 28
9.6. Link Endorsement (LE-x.y) . . . . . . . . . . . . . . . . 29
9.7. Broadcast Endorsement (BE-x.y) . . . . . . . . . . . . . 29
9.8. Abbreviations & File Naming Conventions . . . . . . . . . 30
9.8.1. In Text Abbreviation . . . . . . . . . . . . . . . . 30
9.8.2. File Naming . . . . . . . . . . . . . . . . . . . . . 31
10. X.509 Certificates . . . . . . . . . . . . . . . . . . . . . 31
10.1. Certificate Policy and Certificate Stores . . . . . . . 31
10.2. Certificate Management . . . . . . . . . . . . . . . . . 32
10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 32
10.4. Alternative Certificate Encoding . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.1. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 32
11.1.1. DRIP Endorsement Subregistries . . . . . . . . . . . 32
11.1.2. Aircraft Information Subregistry . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12.1. Key Rollover & Federation . . . . . . . . . . . . . . . 35
12.2. DET Generation . . . . . . . . . . . . . . . . . . . . . 36
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Binary Endorsements . . . . . . . . . . . . . . . . 39
A.1. Self-Endorsement (SE-x) . . . . . . . . . . . . . . . . . 39
A.2. Generic Endorsement (GE-x.y) . . . . . . . . . . . . . . 41
A.3. Concise Endorsement (CE-x.y) . . . . . . . . . . . . . . 42
A.4. Mutual Endorsement (ME-x.y) . . . . . . . . . . . . . . . 43
A.5. Link Endorsement (LE-x.y) . . . . . . . . . . . . . . . . 44
A.6. Broadcast Endorsement (BE-x.y) . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote
ID (RID). Only very limited operational information can be
Broadcast, but extended information is sometimes needed. The most
essential element of information sent is the UAS ID itself, the
unique key for lookup of extended information in relevant registries
(see Figure 4 of [drip-arch]).
Wiethuechter & Reid Expires 8 June 2023 [Page 3]
Internet-Draft DETIM Architecture December 2022
While it is expected that registry functions will be integrated with
UAS Service Supplier (USS) (Appendix A.2 of [drip-arch]), who will
provide them is not yet determined in most, and is expected to vary
between jurisdictions. However this evolves, the essential registry
functions (including the management of identifiers) are expected to
remain the same, so are specified herein.
While most data to be sent via Broadcast RID (Section 1.2.1 of
[drip-arch]) or Network RID (Section 1.2.2 of [drip-arch]) is public,
much of the extended information in registries will be private. As
discussed in Section 7 of [drip-arch], Authentication, Attestation,
Authorization, Access Control, Accounting, Attribution, and Audit
(AAA) for registries is essential, not just to ensure that access is
granted only to strongly authenticated, duly authorized parties, but
also to support subsequent attribution of any leaks, audit of who
accessed information when and for what purpose, etc. As specific AAA
requirements will vary by jurisdictional regulation, provider
choices, customer demand, etc., they are left to specification in
policies, which should be human readable to facilitate analysis and
discussion, and machine readable to enable automated enforcement,
using a language amenable to both (e.g., eXtensible Access Control
Markup Language (XACML)).
The intent of the access control requirements on registries is to
ensure that no member of the public would be hindered from accessing
public information, while only duly authorized parties would be
enabled to access private information. Mitigation of Denial of
Service (DoS) attacks and refusal to allow database mass scraping
would be based on those behaviors, not on identity or role of the
party submitting the query per se, but querant identity information
might be gathered (by security systems protecting DRIP
implementations) on such misbehavior.
Registration under DRIP is vital to manage the inevitable collisions
in the hash portion of the DRIP Entity Tags (DETs). Forgery of the
DETs is still possible, but including it as a part of a public
registration mitigates this risk. This document creates the DRIP DET
registration and discovery ecosystem. This includes all components
in the ecosystem (e.g., Unmanned Aircraft (UA), Registered Assigning
Authority (RAA), Hierarchical HIT Domain Authority (HDA), Ground
Control Station (GCS), and USS).
This document uses the Concise Data Definition Language (CDDL)
[RFC8610] for describing the registration data.
Wiethuechter & Reid Expires 8 June 2023 [Page 4]
Internet-Draft DETIM Architecture December 2022
2. Abstract Process and Reasoning
In DRIP each entity (registry, operator, and aircraft) is expected to
generate a full DRIP Entity ID [drip-rid] on the local device their
key is expected to be used. These are registered with a Public
Information Registry within the hierarchy along with whatever data is
required by the cognizant CAA and the registry. Any Personally
Identifiable Information (PII) is stored in a Private Information
Registry protected through industry practice AAA or stronger. In
response, the entity will obtain an endorsement from the registry
proving such registration.
Manufacturers that wish to participate in DRIP should not only
support DRIP as a Session ID type for their aircraft but could also
generate a DET then encode it as a Serial Number. This would allow
aircraft under CAA mandates to fly only ID Type 1 (Serial Number)
could still use DRIP and most of its benefits. Even if DRIP is not
supported for Serial Numbers by a Manufacturer it is hoped that they
would still run a registry to store their Serial Numbers and allow
look ups for generic model information. This look up could be
especially helpful in UTM for Situational Awareness when an aircraft
flying with a Serial Number is detected and allow for an aircraft
profile to be displayed.
Operators are registered with a number of registries or their
regional RAA. This acts as a verification check when a user performs
other registration operations; such as provisioning an aircraft with
a new Session ID. It is an open question if an Operator registers to
their CAA (the RAA) or multiple USS's (HDA's). PII of the Operator
would vary based on the CAA they are under and the registry.
Finally, aircraft that support using a DET would provision per flight
to a USS, proposing a DET to the registry to generate a binding
between the aircraft (Session ID, Serial Number, and Operational
Intent), operator and registry. The aircraft then follows
[drip-auth] to meet various requirements from [RFC9153] during a
flight.
3. Terminology
3.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.
Wiethuechter & Reid Expires 8 June 2023 [Page 5]
Internet-Draft DETIM Architecture December 2022
3.2. Additional Definitions
See [RFC9153] for common DRIP terms and Section 2.2 of [drip-arch]
for additional terms used in this document.
HDA:
Hierarchial HIT Domain Authority. The 14 bit field identifying
the HIT Domain Authority under a RAA.
HID:
Hierarchy ID. The 28 bit field providing the HIT Hierarchy ID.
PII:
Personally Identifiable Information. Any information a cognizant
authority (such as a government agency) or a user requires
differentiated access to obtain.
RAA:
Registered Assigning Authority. The 14 bit field identifying the
Hierarchical HIT Assigning Authority.
4. DIME Roles
[drip-arch] defines the DRIP Identity Management Entity (DIME) as an
entity that vets Claims and/or Evidence from a registrant and
delivers back Endorsements and/or Certificates in response. The DIME
encompasses various logical components and can be classified to serve
a number of different roles, which are detailed in the following
subsections. The general hierarchy of these roles are illustrated in
Figure 1.
Wiethuechter & Reid Expires 8 June 2023 [Page 6]
Internet-Draft DETIM Architecture December 2022
+----------+
| Apex |
+-o------o-+
| |
******************|******|*****************************
| |
+-----o-+ +-o-----+
RAAs | IRM | | RAA o------.
+---o---+ +---o---+ '
| | |
****************|**********|**********|****************
| | |
+---o---+ +---o---+ +---o---+
HDAs | MRA | | RIDR | | HDA |
+-------+ +-------+ +-------+
Figure 1: DIME Roles and Hierarchy
4.1. Apex
The Apex is a special DIME role that holds the value of RAA=0 and
HDA=0. It serves as the branch point from the larger DNS system in
which HHITs are defined. The Apex generally has as prefix portions
of the HHIT associated with it (such as 2001:0030/28) which are
assigned by IANA from the non-routable special IPv6 address space for
ORCHIDs (where HHITs are derived from).
The Apex manages all delegations and allocations of the HHIT's RAA to
various parties with NS records to redirect DNS queries to proper
sub-branches.
4.2. Registered Assigning Authority (RAA)
RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field
(16,384 RAAs) of an HHIT). An RAA is a business or organization that
manages a registry of HDAs (Section 4.3). Most are contemplated to
be Civil Aviation Authorities (CAA), such as the Federal Aviation
Authority (FAA), that then delegate HDAs to manage their National Air
Space (NAS). This is does not preclude other entities to operate an
RAA if the Apex allows it.
For DRIP and the UAS use case ICAO will handle the registration of
RAAs. Once ICAO accepts an RAA, it will assign a number and create a
zone delegation under the <prefix>.hhit.arpa. DNS zone for the RAA.
Wiethuechter & Reid Expires 8 June 2023 [Page 7]
Internet-Draft DETIM Architecture December 2022
As HHITs may be used in many different domains, RAA should be
allocated in blocks with consideration on the likely size of a
particular usage. Alternatively, different prefixes can be used to
separate different domains of use of HHITs.
An RAA must provide a set of services to allocate HDAs to
organizations. It must have a public policy on what is necessary to
obtain an HDA. It must maintain a DNS zone minimally for discovering
HID RVS servers. All RAA's use an HDA value of 0 and have their RAA
value delegated to them by the Root.
4.2.1. ICAO Registry of Manufacturers (IRM)
An RAA-level DIME that hands out HDA values to participating
Manufacturer's that hold an ICAO Manufacturer Code used in
[CTA2063A].
To manage the large ICAO Manufacturer Code space (34 character set; 4
characters; 1,336,336 possible codes) a range of RAA values are set
aside for the DRIP use case. These are the RAA values of 2 (0x0002)
up to 96 (0x0060). This allows a single HDA for each Manufacturer
Code.
All IRM's have two reserved HDA values. 0 (0x0000) for itself in its
role as an RAA and 1 (0x0001) if it wishes to offer HDA services.
4.3. Hierarchial HIT Domain Authority (HDA)
An HDA may be an USS, ISP, or any third party that takes on the
business to register the actual UAS entities that need DETs. This
includes, but is not limited to UA, GCS, and Operators. It should
also provide needed UAS services including those required for HIP-
enabled devices (e.g. RVS).
The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by
an RAA. An HDA should maintain a set of RVS servers for UAS clients
that may use HIP. How this is done and scales to the potentially
millions of customers are outside the scope of this document. This
service should be discoverable through the DNS zone maintained by the
HDA's RAA.
An RAA may assign a block of values to an individual organization.
This is completely up to the individual RAA's published policy for
delegation. Such policy is out of scope.
Wiethuechter & Reid Expires 8 June 2023 [Page 8]
Internet-Draft DETIM Architecture December 2022
4.3.1. Manufacturers Registry of Aircraft (MRA)
An HDA-level DIME run by a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific
ICAO Manufacturer Code (assigned to the manufacturer by ICAO).
A DET can be encoded into a Serial Number (see [drip-rid]) and this
registry would hold a mapping from the Serial Number to the DET and
its artifacts.
4.3.1.1. Remote ID Registries (RIDR)
An HDA-level DIME that holds the binding between a UAS Session ID
(for DRIP the DET) and the UA Serial Number. The Serial Number MUST
have its access protected to allow only authorized parties to obtain.
The Serial Number SHOULD be encrypted in a way only the authorized
party can decrypt.
As part of the UTM system they also hold a binding between a UAS ID
(Serial Number or Session ID) and an Operational Intent. They may
either be a direct logical part of a UAS Service Supplier (USS) or be
a UTM wide service to USS's.
4.4. Role Abbreviation in DETs
On receiver devices a DET can be translated to a more human readable
form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4
Characters of DET Hash}. An example of this would be US FAA FE23. To
support this DIMEs are RECOMMENDED to have an abbreviation that could
be used for this form. These abbreviations SHOULD be a maximum of
six characters in length. Spaces SHOULD NOT be used and be replaced
with either underscores (_) or dashes (-). For RAAs the abbreviation
is RECOMMENDED to be set to the ISO 3166 country code (either Alpha-2
or Alpha-3) for the CAA.
If a DIME does not have an abbreviation or it can not be looked up
then the receiver SHOULD use the 4-character hexadecimal encoding of
the field it is missing.
5. DIME Architecture
The DIME, in any of its roles (Section 4), is comprised of a number
of logical components that are depicted in Figure 2. Any of these
components could be delegated to other entities as a service both co-
located or remote. For example:
Wiethuechter & Reid Expires 8 June 2023 [Page 9]
Internet-Draft DETIM Architecture December 2022
* The Name Server component could be handled by a well-established
DNS registrar/registry with the DRIP Provisioning Agent (DPA)
(Section 5.1) interfacing to them
- Either the DPA or the Registry/Name Server interfaces to the
DRIP Information Agent (DIA)
* The DPA, Registry, and Name Server may all be co-located in one
implementation with an interface to a DIA offered by another
organization from any one of the co-located components
+--------------------+
| Registering Client |
+---------o----------+
|
**********|******************************************************
* | DRIP Identity Management Entity *
* | *
* +------o-------+ +-------------+ +--------------+ *
* | DRIP | | | | | *
* | Provisioning o------o | | | *
* | Agent | | | | | *
* +-------o------+ | | | | *
* | | | | | *
* | | DRIP | | Registration | *
* +-------o--+ | Information o------o Data | *
* | Registry o----------o Agent | | Directory | *
* +-------o--+ | | | Service | *
* | | | | | *
* | | | | | *
* +-------o-----+ | | | | *
* | Name Server | | | | | *
* +------o------+ +-----o-------+ +------o-------+ *
* | | | *
* | | | *
**********|********************|*********************|***********
| | |
| +-------o-------+ |
'------------o Lookup Client o-------------'
+---------------+
Figure 2: Registry Hierarchy
Wiethuechter & Reid Expires 8 June 2023 [Page 10]
Internet-Draft DETIM Architecture December 2022
5.1. DRIP Provisioning Agent (DPA)
The DPA performs the important task of vetting information (such as
the DRIP Endorsements) coming from clients wishing to register and
then delegate (internally or externally) various items to other
components in the DIME.
A standard interface over HTTPS MUST be provided for clients to
access with JSON or CBOR encoding of objects being sent to the DPA.
This interface specification is out of scope for this document.
There MUST be an interface from the DPA to a Registry (Section 5.2)
component which handles the DNS specific requirements of the DIME as
defined by the Registry. There MAY also be interface from the DPA to
a DRIP Information Agent (Section 5.4) as defined by the DIA.
5.2. Registry
The Registry component handles all the required DNS based
requirements of the DIME to function for DRIP. This includes the
registration and maintenance of various DNS Resource Records which
use the DRIP FQDNs (Section 8.1).
A standardized interface MUST be implemented for interactions with
the DPA (Section 5.1). This interface MAY be over HTTPS using JSON/
CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP)
[RFC5730]. The specifications of either of these interfaces is out
of scope for this document.
There MAY be interface from the Registry to a DRIP Information Agent
(Section 5.4) as defined by the DIA.
5.3. Name Server (NS)
This may be very important here as we should not preclude a USS from
running his own Name Server but they are not DNS experts and will
need guidance or at least pointers to it to not mess it up. Such as
SOA and NS formats to allow delegation if as RAA.
The interface of the Name Server to any component (nominally the
Registry) in a DIME is out of scope as typically they are
implementation specific.
Wiethuechter & Reid Expires 8 June 2023 [Page 11]
Internet-Draft DETIM Architecture December 2022
5.4. DRIP Information Agent (DIA)
The DIA is the main component handling requests for information from
entities outside of the DIME. Typically this is when an Observer
looks up a Session ID from an UA and gets pointed to the DIA via a
SVR RR to obtain information not available via DNS.
The information contained in the DIA is generally more oriented
around the Operator of a given UAS and is thus classified as
Personally Identifiable Information (PII). To protect the privacy of
an Operator of the UAS this information is not publicly accessible
and is only available behind policy driven differentiated access
mechanisms. As an example the Serial Number, under the FAA, is
classified as PII and can only be accessed by federal entities (such
as the FAA themselves).
For DRIP the Registration Data Access Protocol (RDAP) ([RFC7480],
[RFC9082] and [RFC9083]) is the selected protocol to provide policy
driven differentiated access for queries of information.
A standard interface over HTTPS MUST be provided for clients to
access with JSON/CBOR encoding of objects being sent to the DIA.
There MUST also be a standardized interface for the DPA or Registry
to add, update or delete information into the DIA. Both of these
interfaces are out of scope for this document.
An interface defined by the Registration Data Directory Service
(RDDS) (Section 5.5) is also required as specified by the RDDS.
5.5. Registration Data Directory Service (RDDS)
This is the primary information database for the DIA. An interface
MUST be provided to the DIA but its specification is out of scope for
this document.
6. Registration/Provisioning Process
The general process for a registering party is as follows:
1. Verify input Endorsement(s) from registering party
2. Check for collision of DET and HI
3. Populate Registry/Name Server with required/optional resource
records using the FQDN
4. Populate RDDS via DIA with PII and other info
Wiethuechter & Reid Expires 8 June 2023 [Page 12]
Internet-Draft DETIM Architecture December 2022
5. Generate and return required/optional DRIP Endorsements
In the following subsections an abbreviated form of Section 5 using
co-located components is used to describe the flow of information.
The data elements being transmitted between entities is marked
accordingly in each figure for the specific examples.
6.1. Serial Number
Serial Numbers are primarily registered to MRA's (Section 4.3.1) by
the Manufacturers. Could be also registered to CAA's (using their
HDA functionality) as part of Operator registration or to USS's in
their capacity as HDAs. In the later two cases no DNS RRs are made
to protect the privacy of the registering parties.
When the Serial Number is really an encoded DET the DET FQDN is used
to point to HIP and CERT RRs rather than the Serial Number FQDN.
Instead a CNAME is made between the Serial Number FQDN and the DET
FQDN. The same can still happen if the manufacturer chooses to use
their own Serial Number formatting (still within the specification of
[CTA2063A]) and create the CNAME back to a DET loaded into the
unmanned aircraft.
Wiethuechter & Reid Expires 8 June 2023 [Page 13]
Internet-Draft DETIM Architecture December 2022
+-------------------+
| Unmanned Aircraft |
+--o---o------------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: MRA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Serial Number,
UA Information,
Self-Endorsement: UA
(b) Success Code,
Broadcast Endorsement: MRA on UA
(c) HIP RR,
CERT RRs
(d) UA Information
Figure 3: Example DIME:MRA with Serial Number (DET) Registration
The unmanned aircraft, intending to use DRIP, generates a keypair,
DET and Self-Endorsement: UA using the RAA and HDA values specified
by the manufacturers DIME (running as an MRA). The DET is converted
into a Serial Number (per [drip-rid]) or the manufacturer creates
their own Serial Number.
The Serial Number, UA information and the Self-Endorsement: UA are
sent to the manufacturers DIME. The DIME validates the Self-
Endorsement and checks for DET and HI collisions in the Name Server/
DIA. A Broadcast Endorsement: DIME on UA is generated which is
provisioned into the aircraft for use when using the Serial Number as
its UAS ID. In the Name Server HIP RRs are created using the DET
FQDN while a CNAME points the Serial Number FQDN to the DET FQDN.
Wiethuechter & Reid Expires 8 June 2023 [Page 14]
Internet-Draft DETIM Architecture December 2022
Note: Figure 3 is specific for a DET encoded Serial Number. The
Endorsements in (a) and (b) as well as RRs in (c) would not be
present for non-DET based Serial Numbers.
Additional UA Information has a set of valid item keys defined in
Section 11.1.2. The items present for a given interaction is defined
by future documents, local regulations and implementation specific
capabilities.
6.2. Operator
Provided either by USS or CAA run HDAs. Regulation might require
interaction between them. An Operator can request that certain
information normally generated and provisioned into DNS be omitted
due to privacy concerns.
+----------+
| Operator |
+--o---o---+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: HDA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Operator Information,
Operator Self-Endorsement
(b) Success Code,
Generic Endorsement: HDA on Operator
(c) HIP RR,
CERT RRs
(d) Operator Information
Figure 4: Example DIME:HDA with Operator (DET) Registration
Wiethuechter & Reid Expires 8 June 2023 [Page 15]
Internet-Draft DETIM Architecture December 2022
The Operator generates a keypair and DET as specified in [drip-rid]
along with a self-signed endorsement (Self-Endorsement: Operator).
The RAA and HDA values used in the DET generation for the Operator
are found by referencing their selected DIME of choice (in Figure 4
an HDA).
The self-signed endorsement along with other relevant information
(such as Operator PII) is sent to the DIME over a secure channel.
The specification of this secure channel is out of scope for this
document.
The DIME cross checks any personally identifiable information as
required. Self-Endorsement: Operator is verified. The DET and HI is
searched in the DIME DIA and Name Server to confirm that no
collisions occur. A new endorsement is generated (Generic
Endorsement: DIME on Operator) and sent securely back to the
Operator. Resource Records for the HI and Endorsements are added to
the DIME Registry/Name Server.
With the receipt of Generic Endorsement: DIME on Operator the
registration of the Operator is complete.
Note: (c) in Figure 4 MAY be requested by the Operator to be
omitted due to PII concerns.
The definition of Operator Information is out of scope of this
document and left to local regulations.
6.3. Session ID
Session IDs are generally handled by HDAs, specifically RIDRs. In
Figure 5 the UAS comprises of an unmanned aircraft and a Ground
Control Station (GCS). Both parties are involved in the registration
process.
Wiethuechter & Reid Expires 8 June 2023 [Page 16]
Internet-Draft DETIM Architecture December 2022
+---------+
| UAS |
+--o---o--+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: RIDR *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Mutual Endorsement: RIDR on GCS,
Generic Endorsement: GCS on UA,
Session ID Information
(b) Success Code,
Broadcast Endorsement: RIDR on UA,
Generic Endorsement: RIDR on UAS
(c) HIP RR,
TLSA, RR,
CERT RRs
(d) Session ID Information
Figure 5: Example DIME:RIDR with Session ID (DET) Registration
Through mechanisms not specified in this document the Operator should
have methods (via the GCS) to instruct the unmanned aircraft onboard
systems to generate a keypair, DET and Self-Endorsement: UA. The
Self-Endorsement: UA is extracted by the Operator onto the GCS.
The GCS is already pre-provisioned and registered to the DIME with
its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement:
RIDR on GCS. The GCS creates a new Generic Endorsement: GCS on UA
and also creates Mutual Endorsement: RIDR on GCS. These new
endorsements along with Session ID Information are sent to the DIME
via a secure channel.
Wiethuechter & Reid Expires 8 June 2023 [Page 17]
Internet-Draft DETIM Architecture December 2022
The DIME validates all the endorsements and checks for DET and HI
collisions in the Name Server/DIA using the proposed UA DET. A
Broadcast Endorsement: DIME on UA is generated. An Generic
Endorsement: RIDR on UAS is generated using the Generic Endorsement:
GCS on UA. HIP and CERT RRs are provisioned into the Registry/Name
server. Both endorsements are back to the GCS on a secure channel.
The GCS then injects the Broadcast Endorsement: RIDR on UA securely
into the unmanned aircraft. Endorsement: RIDR on GCS is securely
stored by the GCS.
Note: in Figure 5 the Session ID Information is expected to
contain the Serial Number along with other PII specific
information (such as UTM data) related to the Session ID.
Session ID Information is defined as the current model:
sessionid_info = {
serial: tstr .size 20,
session_id: tstr,
operational_intent: tstr,
intent_src: tstr,
operator_id: tstr,
* tstr: any
}
Future standards or implementations MAY add other keys to this list
(for local features and/or local regulation).
6.3.1. UA Based
There may be some unmanned aircraft that have their own Internet
connectivity allowing them to register a Session ID themselves
without outside help from other devices such as a GCS. When such a
system is in use its imperative that the Operator has some method to
create the Generic Endorsement: Operator on UA to send to the DIME.
The process and methods to perform this are out of scope for this
document but MUST be done in a secure fashion.
6.3.2. UAS Based
Most unmanned aircraft will not have their own Internet connectivity
but will have a connection to a GCS. Typically a GCS is an
application on a user device (such as smartphone) that allow the user
to fly their aircraft. For the Session ID registration the DIME MUST
be provided with an Generic Endorsement: GCS on UA which implies
there is some mechanism extracting and inserting information from the
unmanned aircraft to the GCS. These methods MUST be secure but are
Wiethuechter & Reid Expires 8 June 2023 [Page 18]
Internet-Draft DETIM Architecture December 2022
out of scope for this document.
With this system it is also possible to have the GCS generate the DET
based Session ID and insert it securely into the unmanned aircraft
after registration is done. This is NOT RECOMMENDED as this
invalidates the objective of the asymmetric cryptography in the
underlying DET as the private key MAY get in the possession of
another entity other than the unmanned aircraft. See Section 12.2
for more details.
6.4. Child DIME
Handled by the Apex and RAA's. This is an endpoint that handles
dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to
Apex and HDAs to RAAs) in the hierarchy.
+---------------+
| DIME: HDA |
+--o---o--------+
| ^
(a) | | (b)
| |
*******|***|*****************************
* | | DIME: RAA *
* | | *
* v | +----------+ *
* +--o---o--+ | | *
* | DPA o--------->o | *
* +----o----+ (d) | | *
* | | | *
* | (c) | DIA/RDDS | *
* v | | *
* +----o--------+ | | *
* | Registry/NS | | | *
* +-------------+ | | *
* +----------+ *
* *
*****************************************
(a) Self-Endorsement: HDA,
HDA Information or
Generic Endorsement: old HDA, new HDA
(b) Success Code,
Broadcast Endorsement: RAA on HDA
(c) HIP RR,
CERT RRs
(d) HDA Information
Wiethuechter & Reid Expires 8 June 2023 [Page 19]
Internet-Draft DETIM Architecture December 2022
Figure 6: Example DIME:RAA with DIME:HDA Registration
It should be noted that this endpoint DOES NOT hand out dynamically
RAA/HDA values to systems that hit the endpoint. This is done out-
of-band through processes specified by local regulations and
performed by cognizant authorities. The endpoint MUST NOT accept
queries it is not previously informed of being expected via
mechanisms not defined in this document.
It is OPTIONAL to implement this endpoint. This MAY be used to
handle lower-level DIME key roll-over.
7. Differentiated Access Process
Differentiated access, as a process, is a requirement for DIMEs as
defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4,
REG-2 and REG-4. [drip-arch] further elaborates on the concept by
citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential
means of fulfilling this requirement.
Typically the cognizant authority is the primary querant of private
information from a DIME if a Session ID is reported (the case of the
owner of the private information is ignored for the moment). This
capability MAY be delegated to other parties at the authorities
discretion (be it to a single user or many), thus requiring a
flexible system to delegate, determine and revoke querent access
rights for information. XACML MAY be a good technology choice for
this flexibility.
It is noted by the authors that as this system scales the problem
becomes a, well known and tricky, key management problem. While
recommendations for key management are useful they are not
necessarily in scope for this document as BCPs around key management
should already be mandated and enforced by the cognizant authorities
in their existing systems. This document instead focuses on finding
a balance for generic wide-spread interoperability between DIMEs and
authorities and their existing systems in a Differentiated Access
Process (DAP).
A system where cognizant authorities would require individual
credentials to each HDA is not scalable, nor practical. Any change
in policy would require the authority to interact with every single
HDA (active or inactive) to grant or revoke access; this would be
tedious and prone to mistakes. A single credential for a given
authority is also strongly NOT RECOMMENDED due to the security
concerns it would entail if it leaked.
Wiethuechter & Reid Expires 8 June 2023 [Page 20]
Internet-Draft DETIM Architecture December 2022
A zero-trust model would be the most appropriate for a DAP; being
highly flexible and robust. Most authorities however use "oracle"
based systems with specific user credentials and the oracle knowing
the access rights for a given user. This would require the DAP the
have some standard mechanism to locate and query a given oracle for
information on the querent to determine if access is granted.
DRIP has no intention to develop a new "art" of key management,
instead hoping to leverage existing systems and be flexible enough to
adapt as new ones become popular.
8. DRIP in the Domain Name System
The individual DETs may be potentially too numerous (e.g., 60 - 600M)
and dynamic (e.g., new DETs every minute for some HDAs) to store in a
signed, DNS zone. The HDA SHOULD provide DNS service for its zone
and provide the DET detail response.
DNSSEC is strongly recommended (especially for RAA-level and higher
zones). Frequency of updates, size of the zone, and registry policy
may impact its use.
Per [drip-arch] all public information is stored in the DNS to
satisfy REG-1 from [RFC9153]. CERT RRs (Section 8.2.3) contain
public Endorsements or X.509 Certificate relevant to a given Session
ID. SVR RRs (Section 8.2.4) point an Observer to a service to obtain
further information if they have and can prove duly constituted
authority.
The REQUIRED mechanism is to place any information into ip6.arpa sub-
zones. This zone typically contains PTR RRs, however there is no
mandate that this is the only RR allowed in the zone. For DRIP this
means that the HIP, CERT and SVR RRs MUST be added and use the
nibble-reversed DET. The TLSA RR is RECOMMENDED for other uses cases
where DTLS is used (such as in Network RID).
For DRIP, the prefix 2001:0030/28 is slated for DETs being used in
UAS as defined in [drip-rid]. Other prefixes may be allocated by
IANA in future for different use cases that do not fit cleanly into
an existing prefix.
8.1. DRIP Fully Qualified Domain Names
8.1.1. DRIP Entity Tag
The DET can be translated to the following FQDN form:
{hash}.{oga_id}.{hda}.{raa}.{prefix}.hhit.arpa.
Wiethuechter & Reid Expires 8 June 2023 [Page 21]
Internet-Draft DETIM Architecture December 2022
When building a DET FQDN the following two things must be done:
1. The RAA, HDA and OGA ID values MUST be converted from hexadecimal
to decimal form.
2. The FQDN must be built using the exploded (all padding present)
form of the IPv6 address.
Below is an example:
DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e
ID: a3ad:1952:0ad0:a69e
OGA: 5
HDA: 0014 = 20
RAA: 000a = 10
Prefix: 2001003
FQDN: a3ad19520ad0a69e.5.20.10.2001003.hhit.arpa.
Note: any of the fields in the FQDN could be CNAME'd to more human
readable interpretations. For example the DET FQDN
204.2001003.hhit.arpa. may have a CNAME to uas.faa.gov; if RAA 204
was delegated to the FAA.
8.1.2. Serial Number
Serial Number: 8653FZ2T7B8RA85D19LX
ICAO Mfr Code: 8653
Length Code: F
ID: FZ2T7B8RA85D19LX
FQDN: Z2T7B8RA85D19LX.8653.mfr.hhit.arpa.
Serial Number pose a unique problem. If we explicitly only allow
HHITs be under the hhit.arpa. domain structure how do we standardize
the lookup of Serial Numbers? Perhaps to look up Serial Numbers one
must go to a different tree like mfr.icao.int.? We can have CNAMEs in
MRAs for this but they probably need the same TLD (hhit.arpa.) to be
found properly and these are clearly not HHITs.
Serial Numbers MAY be a direct encoding of a DET (as defined in
Section 4.2 of [drip-rid]). A Serial Number MAY also be a simple
linking to a DET using a CNAME. DNAMEs (or PTRs) could be used to
redirect a Serial Number that is not part of an public MRA but is
instead registered by the operator to their HDA. The operator in
this scenario MAY generate a DET for the Serial Number themselves -
also stored in the HDA. The mapping of the Serial Number to this
'private' DET MUST NOT be made public.
Wiethuechter & Reid Expires 8 June 2023 [Page 22]
Internet-Draft DETIM Architecture December 2022
8.2. Supported DNS Records
8.2.1. HIP
All DIMEs MUST use HIP RR [RFC8005] as the primary public source of
DET HIs. DIMEs have their own DET associated with them and their
respective name server will hold a HIP RR that is pointed to by their
DET FQDN.
MRA (Section 4.3.1) and RIDR (Section 4.3.1.1) DIMEs will also have
HIP RRs for their registered parties (aircraft and operators
respectfully).
8.2.2. TLSA
This RR, [RFC6698], is mainly used to support DTLS deployments where
the DET is used (e.g. Network RID and the wider UTM system). The HI
is encoded using the SubjectPublicKeyInfo selector. DANE [RFC6698]
is for servers, DANCE [dane-clients] is for clients.
The TLSA RR MAY be used in place of the HIP RR, where to primary need
of the DET HI is for DTLS authentication. This DNS server side
optimization is for where the overhead of both RR is onerous. Thus
all clients that work with the HIP RR SHOULD be able to able to
extract the HI from the TLSA RR.
8.2.3. CERT
Endorsements MAY be placed into DNS in the CERT RRs [RFC4398].
Endorsements will be stored in Certificate Type OID Private (value
254) with a base OID of 1.3.6.1.4.1.6715.2 and further classified by
the Endorsement/Certificate Type and then Entities involved.
Wiethuechter & Reid Expires 8 June 2023 [Page 23]
Internet-Draft DETIM Architecture December 2022
+=======================+===========+
| Endorsement Type | OID Value |
+=======================+===========+
| Self-Endorsement | 1 |
+-----------------------+-----------+
| Generic Endorsement | 2 |
+-----------------------+-----------+
| Concise Endorsement | 3 |
+-----------------------+-----------+
| Mutual Endorsement | 4 |
+-----------------------+-----------+
| Link Endorsement | 5 |
+-----------------------+-----------+
| Broadcast Endorsement | 6 |
+-----------------------+-----------+
Table 1
+==============================+===========+
| Entity Type | OID Value |
+==============================+===========+
| Unmanned Aircraft (UA) | 1 |
+------------------------------+-----------+
| Ground Control Station (GCS) | 2 |
+------------------------------+-----------+
| Operator (OP) | 3 |
+------------------------------+-----------+
| HDA | 4 |
+------------------------------+-----------+
| RAA | 5 |
+------------------------------+-----------+
| Root | 6 |
+------------------------------+-----------+
Table 2
As an example the following OID: 1.3.6.1.4.1.6715.2.6.4.1 would
decompose into: the base OID (1.3.6.1.4.1.6715.2), the Endorsement
Type (6: Broadcast Endorsement) and then the parties involved (4:
HDA, 1: UA)
Certificate Type X.509 as per PKIX (value 1) MAY be used to store
X.509 certificates as discussed in (Appendix B).
Editor Note: This OID is an initial allocation under the IANA
Enterprise Number OID. It is expect that a general OID will be
allocated at some point.
Wiethuechter & Reid Expires 8 June 2023 [Page 24]
Internet-Draft DETIM Architecture December 2022
8.2.4. SVR
The SVR RR for DRIP always is populated at the "local" registry
level. That is an HDA's DNS would hold the SVR RR that points to
that HDAs private registry for all data it manages. This data
includes data being stored on its children.
The best example of this is RIDR (Section 4.3.1.1) would have a SVR
RR that points to a database that contains any extra information of a
Session ID it has registered. Another example is the MRA
(Section 4.3.1) has a SVR RR pointing to where the metadata of a UA
registered in the MRA can be located.
In all cases the server being pointed to MUST be protected using AAA,
such as using RDAP.
9. Endorsements
Under DRIP Endorsements are defined in a CDDL [RFC8610] structure
that can be encoded to CBOR, JSON or have their keys removed and be
sent as a binary blob. When the latter is used very specific forms
are defined with naming conventions to know the data fields and their
lengths for parsing.
The first subsection defines the structure of an Endorsement while
the remain subsections define specific forms that are commonly used.
The binary forms of the subsections can be found in Appendix A.
Note: this section uses the term HHIT instead of DET as the
Endorsements are designed to be generic and re-useable for other
HHIT use-cases. Specific use-case SHOULD add new keys for each
section (if required) and define the valid keys and encoding forms
for their use-case.
9.1. Endorsement Structure
Wiethuechter & Reid Expires 8 June 2023 [Page 25]
Internet-Draft DETIM Architecture December 2022
endorsement = {
identity: {
(hit: bstr .size 16, ? hi: bstr) // (hhit: bstr .size 16, ? hi: bstr)
* tstr: any
},
evidence: bstr,
scope: {
vnb: number,
vna: number,
* tstr: any
}
signature: {
sig: bstr
* tstr: any
}
}
Figure 7: Endorsement CDDL
9.1.1. Identity
The identity section is where the main identity information of the
signer of the Endorsement is found. The identity can take many forms
such as a handle to the identity (an HHIT), and can include more
explicit data such as the public key (an HI). Other keys can be
provided and MUST be defined in their specific Endorsement.
The length of the hi can be determined when using hhit or hi by
decoding the provided IPv6 address. The prefix will inform of the
ORCHID construction being used, which informs the locations of the
OGA ID in the address. The OGA ID will then inform the user of the
key algorithm selected which has the key length defined.
9.1.2. Evidence
The evidence section contain a byte string of evidence. Specific
content of evidence (such as subfields, length and ordering) is
defined in specific Endorsement structures.
9.1.3. Scope
The scope section is more formally "the scope of validity of the
endorsement". The scope can come in various forms but MUST always
have a "valid not before" (vnb) and "valid not after" (vna)
timestamps.
Wiethuechter & Reid Expires 8 June 2023 [Page 26]
Internet-Draft DETIM Architecture December 2022
Other forms of the scope could for example be a 4-dimensional volume
definition. This could be in raw latitude, longitude, altitude pairs
or may be a URI pointing to scope information.
9.1.4. Signature
The signature section contain the signature data for the endorsement.
The signature itself MUST be provided under the sig key. Other forms
or data elements could also be present in the signature section if
specified in a specific endorsement. Signatures MUST be generated
using the preceding sections in their binary forms (i.e. no keys).
9.2. Self-Endorsement (SE-x)
self_endorsement = {
identity: {
hhit: bstr .size 16,
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 8: Self-Endorsement CDDL Structure
In a Self-Endorsement the identity is a HHIT/DET and the evidence is
the associate HI. The HI could be removed, resulting in an "empty"
Endorsement, when obtaining the HI via other means (such as DNS) is
guaranteed. This behavior is NOT RECOMMENDED as the data being
signed would be very short.
9.3. Generic Endorsement (GE-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 27]
Internet-Draft DETIM Architecture December 2022
generic_endorsement = {
identity: {
hhit: bstr .size 16,
hi: bstr
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 9: Endorsement CDDL Structure
An endorsement used to sign over evidence that is being endorsed.
Typically the evidence is filled with a byte string of a Self-
Endorsement (Section 9.2) of another party.
9.4. Concise Endorsement (CE-x.y)
concise_endorsement = {
identity: {
hhit: bstr .size 16,
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 10: Concise Endorsement CDDL Structure
An endorsement signing over only the HHIT/DET of Y (as evidence) and
the HHIT/DET of X (as identity). In constrained environments and
when there is the guarantee of being able to lookup the HHITs/DETs to
obtain HIs this endorsement can be used.
9.5. Mutual Endorsement (ME-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 28]
Internet-Draft DETIM Architecture December 2022
mutual_endorsement = {
identity: {
hhit: bstr .size 16,
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 11: Mutual Endorsement CDDL Structure
An endorsement that perform a sign over an existing Generic
Endorsement (as a byte string of evidence) where the signer is the
second party of the embedded endorsement. The HHIT/DET of party Y is
used as the identity.
9.6. Link Endorsement (LE-x.y)
link_endorsement = {
identity: {
hhit: bstr .size 16,
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 12: Link Endorsement CDDL Structure
An endorsement that performs a sign over an existing Concise
Endorsement (in byte string form for evidence) where the signer is
the second party of the embedded endorsement. The HHIT/DET of party
Y is used as the identity.
9.7. Broadcast Endorsement (BE-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 29]
Internet-Draft DETIM Architecture December 2022
broadcast_endorsement = {
identity: {
hhit: bstr .size 16,
},
evidence": bstr,
scope: {
vnb: number,
vna: number
}
signature: {
sig: bstr
}
}
Figure 13: Broadcast Endorsement CDDL Structure
This endorsement is required by DRIP Authentication Formats &
Protocols for Broadcast RID ([drip-auth]) to satisfy [RFC9153] GEN-1
and GEN-3 and is sent in its binary form (Appendix A.6).
The evidence is a concatenated byte string of the HHIT/DET of Y and
the HI of Y in HHIT/HI order. The identity is the HHIT/DET of X.
9.8. Abbreviations & File Naming Conventions
The names of endorsements can become quite long and tedious to write
out. As such this section provides a guide to a somewhat
standardized way they are written in text.
9.8.1. In Text Abbreviation
In a long form the name of a particular endorsement can be written as
follows:
* Self-Endorsement: Unmanned Aircraft
* Generic Endorsement: Operator on Aircraft or Generic Endorsement:
Operator, Aircraft
When multiple entities are listed they can be separated by either on
or by ,. These long forms can be shortened:
* SE(Unmanned Aircraft) or SE-ua
* GE(Operator, Unmanned Aircraft) or GE-op.ua
Typical abbreviations for the entity can be used such as Unmanned
Aircraft being shorthanded to ua.
Wiethuechter & Reid Expires 8 June 2023 [Page 30]
Internet-Draft DETIM Architecture December 2022
9.8.2. File Naming
For file naming of various endorsements a similar format to the short
form is used:
* se-{hash of entity}
* ge-{hash of entity x}_{hash of entity y}
Some examples of file names:
* se-79d8a404d48f2ef9.cert
* ge-120b8f25b198c1e1_79d8a404d48f2ef9.cert
10. X.509 Certificates
10.1. Certificate Policy and Certificate Stores
X.509 certificates are optional for the DRIP entities covered in this
document. DRIP endpoint entities (EE) (i.e., UA, GCS, and Operators)
may benefit from having X.509 certificates. Most of these
certificates will be for their DET and some will be for other UAS
identities. To provide for these certificates, some of the other
entities covered in this document will also have certificates to
create and manage the necessary PKI structure.
Any Certificate Authority (CA) supporting DRIP entities SHOULD adhere
to the ICAO's International Aviation Trust Framework (IATF)
Certificate Policy [ICAO-IATF-CP-draft]. The CA(s) supporting this
CP MUST either be a part of the IATF Bridge PKI or part of the IATF
CA Trust List.
EEs may use their X.509 certificates, rather than their rawPublicKey
(i.e. HI) in authentication protocols (as not all may support
rawPublicKey identities). Some EE HI may not be 'worth' supporting
the overhead of X.509. Short lived DETs like those used for a single
operation or even for a day's operations may not benefit from X.509.
Creating then almost immediately revoking these certificates is a
considerable burden on all parts of the system. Even using a short
not AfterDate will completely mitigate the burden of managing these
certificates. That said, many EEs will benefit to offset the effort.
It may also be a regulator requirement to have these certificates.
Wiethuechter & Reid Expires 8 June 2023 [Page 31]
Internet-Draft DETIM Architecture December 2022
Typically an HDA either does or does not issue a certificate for all
its DETs. An RAA may specifically have some HDAs for DETs that do
not want/need certificates and other HDAs for DETs that do need them.
These types of HDAs could be managed by a single entity thus
providing both environments for its customers.
It is recommended that DRIP X.509 certificates be stored as DNS TLSA
Resource Records. This not only generally improves certificate
lookups, but also enables use of DANE [RFC6698] for the various
servers in the UTM and particularly DRIP registry environment and
DANCE [dane-clients] for EEs (e.g. [drip-secure-nrid-c2]). All DRIP
certificates MUST be available via RDAP. LDAP/OCSP access for other
UTM and ICAO uses SHOULD also be provided.
10.2. Certificate Management
(mostly TBD still)
PKIX standard X.509 issuance practices should be used. The
certificate request SHOULD be included in the DET registration
request. A successful DET registration then MUST include certificate
creation, store, and return to the DET registrant.
Certificate revocation will parallel DET revocation. TLSA RR MUST be
deleted from DNS and RDAP, LDAP, and OCSP return revoked responses.
CRLs SHOULD be maintained per the CP.
Details of this are left out, as there are a number of approaches and
further research and experience will be needed.
10.3. Examples
TBD
10.4. Alternative Certificate Encoding
(CBOR encoded certs here. TBD)
11. IANA Considerations
11.1. IANA DRIP Registry
11.1.1. DRIP Endorsement Subregistries
This document requests a new subregistries for Endorsement Type and
Entity Type under the DRIP registry
(https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-
28#section-8.2).
Wiethuechter & Reid Expires 8 June 2023 [Page 32]
Internet-Draft DETIM Architecture December 2022
DRIP Endorsement Type: This 8-bit valued subregistry is for
Endorsement Types to be used in OID's for CERT Resource Records.
Future additions to this subregistry are to be made through Expert
Review (Section 4.5 of [RFC8126]). The following values are
defined:
+=======================+=======+
| Endorsement Type | Value |
+=======================+=======+
| Self-Endorsement | 1 |
+-----------------------+-------+
| Generic Endorsement | 2 |
+-----------------------+-------+
| Concise Endorsement | 3 |
+-----------------------+-------+
| Mutual Endorsement | 4 |
+-----------------------+-------+
| Link Endorsement | 5 |
+-----------------------+-------+
| Broadcast Endorsement | 6 |
+-----------------------+-------+
Table 3
DRIP Entity Type: This 8-bit valued subregistry is for Entity Types
to be used in OID's for CERT Resource Records. Future additions
to this subregistry are to be made through Expert Review
(Section 4.5 of [RFC8126]). The following values are defined:
+==============================+=======+
| Entity Type | Value |
+==============================+=======+
| Unmanned Aircraft (UA) | 1 |
+------------------------------+-------+
| Ground Control Station (GCS) | 2 |
+------------------------------+-------+
| Operator (OP) | 3 |
+------------------------------+-------+
| HDA | 4 |
+------------------------------+-------+
| RAA | 5 |
+------------------------------+-------+
| Root | 6 |
+------------------------------+-------+
Table 4
Wiethuechter & Reid Expires 8 June 2023 [Page 33]
Internet-Draft DETIM Architecture December 2022
11.1.2. Aircraft Information Subregistry
This document requests a new subregistry for aircraft information
fields under the DRIP registry
(https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-
28#section-8.2).
Aircraft Information Fields: list of acceptable keys to be used in
UA Information during a UA registration to a DIME. Future
additions to this subregistry are to be made through Expert Review
(Section 4.5 of [RFC8126]). The following values are defined:
+======================+=======+========================+
| Key Name | Type | Description |
+======================+=======+========================+
| length | float | length, in millimeters |
+----------------------+-------+------------------------+
| width | float | width, in millimeters |
+----------------------+-------+------------------------+
| height | float | height, in millimeters |
+----------------------+-------+------------------------+
| constructionMaterial | tstr | materials, comma |
| | | separated if multiple |
+----------------------+-------+------------------------+
| color | tstr | colors, comma |
| | | separated if multiple |
+----------------------+-------+------------------------+
| serial | tstr | ANSI CTA 2063-A Serial |
| | | Number |
+----------------------+-------+------------------------+
| manufacturer | tstr | manufacturer name |
+----------------------+-------+------------------------+
| make | tstr | aircraft make |
+----------------------+-------+------------------------+
| model | tstr | aircraft model |
+----------------------+-------+------------------------+
| dryWeight | float | weight of aircraft |
| | | with no payloads |
+----------------------+-------+------------------------+
| numRotors | int | Number of rotators |
+----------------------+-------+------------------------+
| propLength | float | Length of props, in |
| | | centimeters |
+----------------------+-------+------------------------+
| numBatteries | int | |
+----------------------+-------+------------------------+
| batteryCapacity | float | in milliampere hours |
+----------------------+-------+------------------------+
Wiethuechter & Reid Expires 8 June 2023 [Page 34]
Internet-Draft DETIM Architecture December 2022
| batteryWeight | float | in kilograms |
+----------------------+-------+------------------------+
| batteryVoltage | float | in volts |
+----------------------+-------+------------------------+
| batteryChemistry | tstr | |
+----------------------+-------+------------------------+
| maxTakeOffWeight | float | in kilograms |
+----------------------+-------+------------------------+
| maxPayloadWeight | float | in kilograms |
+----------------------+-------+------------------------+
| maxFlightTime | float | in minutes |
+----------------------+-------+------------------------+
| minOperatingTemp | float | in Celsius |
+----------------------+-------+------------------------+
| maxOperatingTemp | float | in Celsius |
+----------------------+-------+------------------------+
| ipRating | tstr | standard IP rating |
+----------------------+-------+------------------------+
| engineType | tstr | |
+----------------------+-------+------------------------+
| fuelType | tstr | |
+----------------------+-------+------------------------+
| fuelCapacity | float | in liters |
+----------------------+-------+------------------------+
| previousSerial | tstr | legacy serial |
| | | number(s) |
+----------------------+-------+------------------------+
Table 5
12. Security Considerations
12.1. Key Rollover & Federation
During key rollover the DIME MUST inform all children and parents of
the change - using best standard practices of a key rollover. At
time of writing this is signing over the new key with the previous
key in a secure fashion and it being validated by others before
changing any links (in DRIPs case the NS RRs in the parent registry).
A DET has a natural ability for a single DIME to hold different
cryptographic identities under the same HID values. This is due to
the lower 64-bits of the DET being a hash of the public key and the
HID of the DET being generated. As such during key rollover, only
the lower 64-bits would change and a check for a collision would be
required.
Wiethuechter & Reid Expires 8 June 2023 [Page 35]
Internet-Draft DETIM Architecture December 2022
This attribute of the DET to have different identities could also
allow for a single registry to be "federated" across them if they
share the same HID value. This method of deployment has not been
thoroughly studied at this time. An endpoint such as in Section 6.4
is a possible place to have these functions.
12.2. DET Generation
Under the FAA [NPRM], it is expecting that IDs for UAS are assigned
by the UTM and are generally one-time use. The methods for this
however are unspecified leaving two options.
Option 1:
The entity generates its own DET, discovering and using the RAA
and HDA for the target registry. The method for discovering a
registry's RAA and HDA is out of scope here. This allows for the
device to generate an DET to send to the registry to be accepted
(thus generating the required Self-Endorsement) or denied.
Option 2:
The entity sends to the registry its HI for it to be hashed and
result in the DET. The registry would then either accept
(returning the DET to the device) or deny this pairing.
Keypairs are expected to be generated on the device hardware it will
be used on. Due to hardware limitations and connectivity it is
acceptable, though not recommended, under DRIP to generate keypairs
for the Aircraft on Operator devices and later securely inject them
into the Aircraft. The methods to securely inject and store keypair
information in a "secure element" of the Aircraft is out of scope of
this document.
13. Contributors
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT
Consulting, LLC) for their early work on the DRIP registries concept.
Their early contributions laid the foundations for the content and
processes of this architecture and document. Bob Moskowitz is also
instrumental in the PKIX work defined in this document with his
parallel work in ICAO.
14. References
14.1. Normative References
Wiethuechter & Reid Expires 8 June 2023 [Page 36]
Internet-Draft DETIM Architecture December 2022
[drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-29, 16 August 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-arch-
29.txt>.
[drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-uas-rid-01, 9 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
01.txt>.
[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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
14.2. Informative References
[CTA2063A] "ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers",
September 2019, <https://shop.cta.tech/products/small-
unmanned-aerial-systems-serial-numbers>.
[dane-clients]
Huque, S., Dukhovni, V., and A. Wilson, "TLS Client
Authentication via DANE TLSA records", Work in Progress,
Internet-Draft, draft-ietf-dance-client-auth-01, 8
November 2022, <https://www.ietf.org/archive/id/draft-
ietf-dance-client-auth-01.txt>.
Wiethuechter & Reid Expires 8 June 2023 [Page 37]
Internet-Draft DETIM Architecture December 2022
[drip-auth]
Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-26, 14 October 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-auth-
26.txt>.
[drip-secure-nrid-c2]
Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "Secure UAS Network RID and C2 Transport", Work in
Progress, Internet-Draft, draft-moskowitz-drip-secure-
nrid-c2-11, 23 July 2022,
<https://www.ietf.org/archive/id/draft-moskowitz-drip-
secure-nrid-c2-11.txt>.
[NPRM] "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", December 2019.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
<https://www.rfc-editor.org/info/rfc4398>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Wiethuechter & Reid Expires 8 June 2023 [Page 38]
Internet-Draft DETIM Architecture December 2022
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
Appendix A. Binary Endorsements
A.1. Self-Endorsement (SE-x)
Wiethuechter & Reid Expires 8 June 2023 [Page 39]
Internet-Draft DETIM Architecture December 2022
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| Host Identity |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before |
+---------------+---------------+---------------+---------------+
| Valid Not After |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag: 16-bytes
Host Identity: 32-bytes
Valid Not Before: 4-bytes
Valid Not After: 4-bytes
Signature: 64-bytes
Figure 14: Binary Self-Endorsement (Length: 120-bytes)
Wiethuechter & Reid Expires 8 June 2023 [Page 40]
Internet-Draft DETIM Architecture December 2022
A.2. Generic Endorsement (GE-x.y)
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of X |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| Host Identity of X |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| |
. .
. SE-y .
. .
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before by X |
+---------------+---------------+---------------+---------------+
| Valid Not After by X |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by X |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag of X: 16-bytes
Wiethuechter & Reid Expires 8 June 2023 [Page 41]
Internet-Draft DETIM Architecture December 2022
Host Identity: 32-bytes
SE-y: 120-bytes
Valid Not Before by X: 4-bytes
Valid Not After by X: 4-bytes
Signature by X: 64-bytes
Figure 15: Binary Generic Endorsement (Length: 240-bytes)
A.3. Concise Endorsement (CE-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 42]
Internet-Draft DETIM Architecture December 2022
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of X |
| |
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of Y |
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before by X |
+---------------+---------------+---------------+---------------+
| Valid Not After by X |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by X |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag of X: 16-bytes
DRIP Entity Tag of Y: 16-bytes
Valid Not Before by X: 4-bytes
Valid Not After by X: 4-bytes
Signature by X: 64-bytes
Figure 16: Binary Concise Endorsement (Length: 104-bytes)
A.4. Mutual Endorsement (ME-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 43]
Internet-Draft DETIM Architecture December 2022
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of Y |
| |
+---------------+---------------+---------------+---------------+
| |
. .
. GE-x.y .
. .
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before by Y |
+---------------+---------------+---------------+---------------+
| Valid Not After by Y |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by Y |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag of Y: 16-bytes
GE-x.y: 16-bytes
Valid Not Before by Y: 4-bytes
Valid Not After by Y: 4-bytes
Signature by Y: 64-bytes
Figure 17: Binary Mutual Endorsement (Length: 328-bytes
A.5. Link Endorsement (LE-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 44]
Internet-Draft DETIM Architecture December 2022
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of Y |
| |
+---------------+---------------+---------------+---------------+
| |
. .
. CE-x.y .
. .
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before by Y |
+---------------+---------------+---------------+---------------+
| Valid Not After by Y |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by Y |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag of Y: 16-bytes
CE-x.y: 16-bytes
Valid Not Before by Y: 4-bytes
Valid Not After by Y: 4-bytes
Signature by Y: 64-bytes
Figure 18: DRIP Link Endorsement (Length: 192-bytes)
A.6. Broadcast Endorsement (BE-x.y)
Wiethuechter & Reid Expires 8 June 2023 [Page 45]
Internet-Draft DETIM Architecture December 2022
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
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of X |
| |
+---------------+---------------+---------------+---------------+
| |
| DRIP |
| Entity Tag of Y |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| Host Identity of Y |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| Valid Not Before by X |
+---------------+---------------+---------------+---------------+
| Valid Not After by X |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by X |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
DRIP Entity Tag of X: 16-bytes
DRIP Entity Tag of Y: 16-bytes
Host Identity of Y: 32-bytes
Valid Not Before by X: 4-bytes
Wiethuechter & Reid Expires 8 June 2023 [Page 46]
Internet-Draft DETIM Architecture December 2022
Valid Not After by X: 4-bytes
Signature by X: 64-bytes
Figure 19: DRIP Broadcast Endorsement (Length: 136-bytes)
Authors' Addresses
Adam Wiethuechter
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com
Wiethuechter & Reid Expires 8 June 2023 [Page 47]