draft-ietf-drip-arch-14.txt | draft-ietf-drip-arch-15.txt | |||
---|---|---|---|---|
drip S. Card | drip S. Card | |||
Internet-Draft A. Wiethuechter | Internet-Draft A. Wiethuechter | |||
Intended status: Informational AX Enterprize | Intended status: Informational AX Enterprize | |||
Expires: 10 January 2022 R. Moskowitz | Expires: 26 January 2022 R. Moskowitz | |||
HTT Consulting | HTT Consulting | |||
S. Zhao (Editor) | S. Zhao (Editor) | |||
Tencent | Tencent | |||
A. Gurtov | A. Gurtov | |||
Linköping University | Linköping University | |||
9 July 2021 | 25 July 2021 | |||
Drone Remote Identification Protocol (DRIP) Architecture | Drone Remote Identification Protocol (DRIP) Architecture | |||
draft-ietf-drip-arch-14 | draft-ietf-drip-arch-15 | |||
Abstract | Abstract | |||
This document describes an architecture for protocols and services to | This document describes an architecture for protocols and services to | |||
support Unmanned Aircraft System Remote Identification and tracking | support Unmanned Aircraft System Remote Identification and tracking | |||
(UAS RID), plus RID-related communications. This architecture | (UAS RID), plus RID-related communications. This architecture | |||
adheres to the requirements listed in the DRIP Requirements document. | adheres to the requirements listed in the DRIP Requirements document. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 10 January 2022. | This Internet-Draft will expire on 26 January 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) | 1.1. Overview of Unmanned Aircraft System (UAS) Remote ID (RID) | |||
and Standardization . . . . . . . . . . . . . . . . . . . 3 | and Standardization . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 | 1.2. Overview of Types of UAS Remote ID . . . . . . . . . . . 4 | |||
1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 | 1.2.1. Broadcast RID . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 | 1.2.2. Network RID . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3. Overview of USS Interoperability . . . . . . . . . . . . 6 | 1.3. Overview of USS Interoperability . . . . . . . . . . . . 7 | |||
1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 7 | 1.4. Overview of DRIP Architecture . . . . . . . . . . . . . . 8 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 9 | |||
3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 9 | 2.1. Architecture Terminology . . . . . . . . . . . . . . . . 9 | |||
3.1. Additional Definitions . . . . . . . . . . . . . . . . . 9 | 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 9 | 2.3. Additional Definitions . . . . . . . . . . . . . . . . . 10 | |||
3.3. Claims, Assertions, Attestations, and Certificates . . . 10 | 3. Claims, Assertions, Attestations, and Certificates . . . . . 10 | |||
4. HHIT as the Primary DRIP Entity Identifier . . . . . . . . . 11 | 4. HHIT as the DRIP Entity Identifier . . . . . . . . . . . . . 11 | |||
4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 11 | 4.1. UAS Remote Identifiers Problem Space . . . . . . . . . . 11 | |||
4.2. HIT as A Trustworthy DRIP Entity Identifier . . . . . . . 12 | 4.2. HIT as A Trustworthy DRIP Entity Identifier . . . . . . . 11 | |||
4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 14 | 4.3. HHIT for DRIP Identifier Registration and Lookup . . . . 13 | |||
4.4. HHIT for DRIP Identifier Cryptographic . . . . . . . . . 14 | 4.4. HHIT for DRIP Identifier Cryptographic . . . . . . . . . 13 | |||
5. DRIP Identifier Registration and Registries . . . . . . . . . 14 | 5. DRIP Identifier Registration and Registries . . . . . . . . . 13 | |||
5.1. Public Information Registry . . . . . . . . . . . . . . . 15 | 5.1. Public Information Registry . . . . . . . . . . . . . . . 13 | |||
5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 15 | 5.1.1. Background . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.1.2. Proposed Approach . . . . . . . . . . . . . . . . . . 15 | 5.1.2. DNS as the Public DRIP Identifier Registry . . . . . 14 | |||
5.2. Private Information Registry . . . . . . . . . . . . . . 15 | 5.2. Private Information Registry . . . . . . . . . . . . . . 14 | |||
5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 15 | 5.2.1. Background . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.2.2. Proposed Approach . . . . . . . . . . . . . . . . . . 16 | 5.2.2. EPP and RDAP as the Private DRIP Identifier | |||
6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 16 | Registry . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 17 | 5.2.3. Alternative Private DRIP Registry methods . . . . . . 15 | |||
6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 17 | 6. Harvesting Broadcast Remote ID messages for UTM Inclusion . . 15 | |||
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 | 6.1. The CS-RID Finder . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 6.2. The CS-RID SDSP . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Privacy & Transparency Considerations . . . . . . . . . . . . 18 | 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 16 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 | 9. Privacy & Transparency Considerations . . . . . . . . . . . . 17 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 18 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 | ||||
10.2. Informative References . . . . . . . . . . . . . . . . . 17 | ||||
Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic | Appendix A. Overview of Unmanned Aircraft Systems (UAS) Traffic | |||
Management (UTM) . . . . . . . . . . . . . . . . . . . . 21 | Management (UTM) . . . . . . . . . . . . . . . . . . . . 20 | |||
A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 21 | A.1. Operation Concept . . . . . . . . . . . . . . . . . . . . 20 | |||
A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 22 | A.2. UAS Service Supplier (USS) . . . . . . . . . . . . . . . 21 | |||
A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 22 | A.3. UTM Use Cases for UAS Operations . . . . . . . . . . . . 21 | |||
Appendix B. Automatic Dependent Surveillance Broadcast | ||||
(ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 | Appendix B. Automatic Dependent Surveillance Broadcast | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | (ADS-B) . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
1. Introduction | 1. Introduction | |||
This document describes an architecture for protocols and services to | This document describes an architecture for protocols and services to | |||
support Unmanned Aircraft System Remote Identification and tracking | support Unmanned Aircraft System Remote Identification and tracking | |||
(UAS RID), plus RID-related communications. The architecture takes | (UAS RID), plus RID-related communications. The architecture takes | |||
into account both current (including proposed) regulations and non- | into account both current (including proposed) regulations and non- | |||
IETF technical standards. | IETF technical standards. | |||
The architecture adheres to the requirements listed in the DRIP | The architecture adheres to the requirements listed in the DRIP | |||
skipping to change at page 5, line 20 ¶ | skipping to change at page 5, line 24 ¶ | |||
1.2.2. Network RID | 1.2.2. Network RID | |||
A RID data dictionary and data flow for Network RID are defined in | A RID data dictionary and data flow for Network RID are defined in | |||
[F3411-19]. This data flow is emitted from an UAS via unspecified | [F3411-19]. This data flow is emitted from an UAS via unspecified | |||
means (but at least in part over the Internet) to a Network Remote ID | means (but at least in part over the Internet) to a Network Remote ID | |||
Service Provider (Net-RID SP). A Net-RID SP provides the RID data to | Service Provider (Net-RID SP). A Net-RID SP provides the RID data to | |||
Network Remote ID Display Providers (Net-RID DP). It is the Net-RID | Network Remote ID Display Providers (Net-RID DP). It is the Net-RID | |||
DP that responds to queries from Network Remote ID Observers | DP that responds to queries from Network Remote ID Observers | |||
(expected typically, but not specified exclusively, to be web-based) | (expected typically, but not specified exclusively, to be web-based) | |||
specifying airspace volumes of interest. Network RID depends upon | specifying airspace volumes of interest. Network RID depends upon | |||
connectivity, in several segments, via the Internet, from the UAS to | internet connectivity to fulfill Observers the RID data query to the | |||
the Observer. | NET-RID DP. The summary of network RID data flows work as follows: | |||
Editor-note 1: + list all the segments mentioned above + specify | * The UA's RID data is generated from a UAS which consists of UAs | |||
how DRIP provide solutions for each segment | and GCSs. | |||
* The RID data is transferred from the UA to the GCS via a RF (Radio | ||||
Frequency) link. | ||||
* The GCS or UA (e.g. BVLOS and autonomous operation) provides the | ||||
UA's RID data to a NET_RID_SP via a secure internet connection. | ||||
* NET_RID_DP as a NET_RID_SP subscriber and satisfies the Observer's | ||||
query request also via a secure internet connection. | ||||
The mimunum Network RID data flow is illustrated in Figure 2: | The mimunum Network RID data flow is illustrated in Figure 2: | |||
x x UA | x x UA | |||
xxxxx ******************** | xxxxx ******************** | |||
| \ * ------*---+------------+ | | \ * ------*---+------------+ | |||
| \ * / * | NET_RID_SP | | | \ * / * | NET_RID_SP | | |||
| \ * ------------/ +---*--+------------+ | | \ * ------------/ +---*--+------------+ | |||
| RF \ */ | * | | RF \ */ | * | |||
| * INTERNET | * +------------+ | | * INTERNET | * +------------+ | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 30 ¶ | |||
x x x x | x x x x | |||
Figure 2 | Figure 2 | |||
Command and Control (C2) must flow from the GCS to the UA via some | Command and Control (C2) must flow from the GCS to the UA via some | |||
path, currently (in the year of 2021) typically a direct RF link, but | path, currently (in the year of 2021) typically a direct RF link, but | |||
with increasing beyond Visual Line of Sight (BVLOS) operations | with increasing beyond Visual Line of Sight (BVLOS) operations | |||
expected often to be wireless links at either end with the Internet | expected often to be wireless links at either end with the Internet | |||
between. | between. | |||
Editor-note 2: Explain the difference with wireless and RF link | Telemetry (at least UA's position and heading) flows from the UA to | |||
includes what are the end entities, usages for each transport | the GCS via some path, typically the reverse of the C2 path. Thus, | |||
media. | RID information pertaining to both the GCS and the UA can be sent, by | |||
whichever has Internet connectivity, to the Net-RID SP, typically the | ||||
For all but the simplest hobby aircraft, telemetry (at least position | USS managing the UAS operation. | |||
and heading) flows from the UA to the GCS via some path, typically | ||||
the reverse of the C2 path. Thus, RID information pertaining to both | ||||
the GCS and the UA can be sent, by whichever has Internet | ||||
connectivity, to the Net-RID SP, typically the USS managing the UAS | ||||
operation. | ||||
Editor-note 3: Does all UAS support telemetry? explain what are | ||||
simplsest hobby aircraft vs UAS in general. Is it necessary to | ||||
keep "For all but the simplest hobby aircraft"? | ||||
The Net-RID SP forwards RID information via the Internet to | The Net-RID SP forwards RID information via the Internet to | |||
subscribed Net-RID DP, typically USS. Subscribed Net-RID DP forward | subscribed Net-RID DP, typically USS. Subscribed Net-RID DP forward | |||
RID information via the Internet to subscribed Observer devices. | RID information via the Internet to subscribed Observer devices. | |||
Regulations require and [F3411-19] describes RID data elements that | Regulations require and [F3411-19] describes RID data elements that | |||
must be transported end-to-end from the UAS to the subscribed | must be transported end-to-end from the UAS to the subscribed | |||
Observer devices. | Observer devices. | |||
[F3411-19] prescribes the protocols only between the Net-RID SP, Net- | [F3411-19] prescribes the protocols only between the Net-RID SP, Net- | |||
RID DP, and the Discovery and Synchronization Service (DSS). DRIP | RID DP, and the Discovery and Synchronization Service (DSS). DRIP | |||
may also address standardization of protocols between the UA and GCS, | can address standardization of protocols between the UA and GCS, | |||
between the UAS and the Net-RID SP, and/or between the Net-RID DP and | between the UAS and the Net-RID SP, and/or between the Net-RID DP and | |||
Observer devices. | Observer devices. | |||
Editor-note 4: "DRIP may also..." Specify what protocol DRIP can | [F3411-19] prescribes the protocols between the Net-RID SP, Net-RID | |||
or will standardize. | DP, and the Discovery and Synchronization Service (DSS). It also | |||
prescribes data elements (in JSON) between Observer and DSS. DRIP | ||||
addresses standardization of secure protocols between the UA and GCS | ||||
(over direct wireless and Internet connection), between the UAS and | ||||
the Net-RID SP, and/or between the Net-RID DP and Observer devices. | ||||
Informative note: Neither link layer protocols nor the use of | Informative note: Neither link layer protocols nor the use of | |||
links (e.g., the link often existing between the GCS and the | links (e.g., the link often existing between the GCS and the | |||
UA) for any purpose other than carriage of RID information is | UA) for any purpose other than carriage of RID information is | |||
in the scope of [F3411-19] Network RID. | in the scope of [F3411-19] Network RID. | |||
1.3. Overview of USS Interoperability | 1.3. Overview of USS Interoperability | |||
With Net-RID, there is direct communication between the UAS and its | With Net-RID, there is direct communication between the UAS and its | |||
USS. With Broadcast-RID, the UAS Operator has either pre-filed a 4D | USS. With Broadcast-RID, the UAS Operator has either pre-filed a 4D | |||
skipping to change at page 9, line 16 ¶ | skipping to change at page 9, line 24 ¶ | |||
[RFC1034]), Extensible Provisioning Protocol (EPP [RFC5731]) | [RFC1034]), Extensible Provisioning Protocol (EPP [RFC5731]) | |||
and Registration Data Access Protocol (RDAP) ([RFC7482]) for | and Registration Data Access Protocol (RDAP) ([RFC7482]) for | |||
publishing public and private information (see Section 5.1 and | publishing public and private information (see Section 5.1 and | |||
Section 5.2). | Section 5.2). | |||
- Harvesting broadcast RID messages for UTM inclusion | - Harvesting broadcast RID messages for UTM inclusion | |||
(Section 6). | (Section 6). | |||
- Privacy in RID messages (PII protection) (Section 9). | - Privacy in RID messages (PII protection) (Section 9). | |||
2. Conventions | 2. Terms and Definitions | |||
2.1. Architecture Terminology | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown above. | capitals, as shown above. | |||
3. Definitions and Abbreviations | 2.2. Abbreviations | |||
Editor-note 13: 1) should we merge Section 2 and Section 3 2) how | ||||
should we list abbr in the Arch? Previous WG agreement is that | ||||
all the DRIP terms shall be defined in -reqs, which may or may not | ||||
be used in -reqs itself, but other documents such as Arch-. And | ||||
arch- can list terms when they are used in the arch- only. So | ||||
which is which ? | ||||
3.1. Additional Definitions | ||||
This document uses terms defined in [I-D.ietf-drip-reqs]. | ||||
3.2. Abbreviations | ||||
ADS-B: Automatic Dependent Surveillance Broadcast | ADS-B: Automatic Dependent Surveillance Broadcast | |||
DSS: Discovery & Synchronization Service | DSS: Discovery & Synchronization Service | |||
EdDSA: Edwards-Curve Digital Signature Algorithm | EdDSA: Edwards-Curve Digital Signature Algorithm | |||
GCS: Ground Control Station | GCS: Ground Control Station | |||
HHIT: Hierarchical HIT Registries | HHIT: Hierarchical HIT Registries | |||
skipping to change at page 10, line 24 ¶ | skipping to change at page 10, line 20 ¶ | |||
SDSP: Supplemental Data Service Provider | SDSP: Supplemental Data Service Provider | |||
UA: Unmanned Aircraft | UA: Unmanned Aircraft | |||
UAS: Unmanned Aircraft System | UAS: Unmanned Aircraft System | |||
USS: UAS Service Supplier | USS: UAS Service Supplier | |||
UTM: UAS Traffic Management | UTM: UAS Traffic Management | |||
3.3. Claims, Assertions, Attestations, and Certificates | 2.3. Additional Definitions | |||
This document uses terms defined in [I-D.ietf-drip-reqs]. | ||||
3. Claims, Assertions, Attestations, and Certificates | ||||
This section introduces the terms "Claims", "Assertions", | This section introduces the terms "Claims", "Assertions", | |||
"Attestations", and "Certificates" as used in DRIP. DRIP certificate | "Attestations", and "Certificates" as used in DRIP. DRIP certificate | |||
has a different context compared with security certificates and | has a different context compared with security certificates and | |||
Public Key Infrastructure used in X.509. | Public Key Infrastructure used in X.509. | |||
Editor-note 5: To be confirmed | ||||
Claims: | Claims: | |||
A claim in DRIP is a predicate (e.g., "X is Y", "X has property | A claim in DRIP is a predicate (e.g., "X is Y", "X has property | |||
Y", and most importantly "X owns Y" or "X is owned by Y"). | Y", and most importantly "X owns Y" or "X is owned by Y"). | |||
Assertions: | Assertions: | |||
An assertion in DRIP is a set of claims. This definition is | An assertion in DRIP is a set of claims. This definition is | |||
borrowed from JWT [RFC7519] and CWT [RFC8392]. | borrowed from JWT [RFC7519] and CWT [RFC8392]. | |||
skipping to change at page 11, line 8 ¶ | skipping to change at page 11, line 8 ¶ | |||
claimant or a third party. Under DRIP this is normally used when | claimant or a third party. Under DRIP this is normally used when | |||
an entity asserts a relationship with another entity, along with | an entity asserts a relationship with another entity, along with | |||
other information, and the asserting entity signs the assertion, | other information, and the asserting entity signs the assertion, | |||
thereby making it an attestation. | thereby making it an attestation. | |||
Certificates: | Certificates: | |||
A certificate in DRIP is an attestation, strictly over identity | A certificate in DRIP is an attestation, strictly over identity | |||
information, signed by a third party. | information, signed by a third party. | |||
4. HHIT as the Primary DRIP Entity Identifier | 4. HHIT as the DRIP Entity Identifier | |||
This section describes the DRIP architectural approach to meeting the | This section describes the DRIP architectural approach to meeting the | |||
basic requirements of a DRIP entity identifier within external | basic requirements of a DRIP entity identifier within external | |||
technical standard ASTM [F3411-19] and regulatory constraints. It | technical standard ASTM [F3411-19] and regulatory constraints. It | |||
justifies and explains the use of Hierarchical Host Identity Tags | justifies and explains the use of Hierarchical Host Identity Tags | |||
(HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type | (HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type | |||
and more generally as trustworthy multipurpose remote identifiers. | and more generally as trustworthy multipurpose remote identifiers. | |||
A HHIT, together with the Host Identity (HI) from which it is partly | Self-asserting in this usage is given the Host Identity (HI), the | |||
derived, self-attests to its included explicit registration | HHIT ORCHID construction and a signature of the HHIT by the HI can | |||
hierarchy, providing Registrar discovery for a 3rd-party who is | both be validated. The explicit registration hierarchy within the | |||
looking for ID attestation retrieves the necessary information to the | HHIT provides registry discovery (managed by a Registrar) to either | |||
registrar via a DNS request HHIT. | yield the HI for 3rd-party (who is looking for ID attestation) | |||
validation or prove the HHIT and HI have uniquely been registered. | ||||
Editor-note 6: Is there a need to specify how self-attest works? | ||||
if yes then where? possible a new section under Section 4} | ||||
4.1. UAS Remote Identifiers Problem Space | 4.1. UAS Remote Identifiers Problem Space | |||
Editor-note 14: Good to have: adding match requirment numbering | A DRIP entity identifier needs to be "Trustworthy" (See DRIP | |||
from requirement document | Requirement about GEN-1, ID-4 and ID-5 in [I-D.ietf-drip-reqs]). | |||
This means that within the framework of the RID messages, an Observer | ||||
A DRIP entity identifier needs to be "Trustworthy". This means that | can establish that the DRIP identifier uniquely belong to the UAS. | |||
within the framework of the RID messages, an Observer can establish | That the only way for any other UAS to assert this DRIP identifier | |||
that the DRIP identifier uniquely belong to the UAS. That the only | would be to steal something from within the UAS. The DRIP identifier | |||
way for any other UAS to assert this DRIP identifier would be to | is self-generated by the UAS (either UA or GCS) and registered with | |||
steal something from within the UAS. The DRIP identifier is self- | the USS. | |||
generated by the UAS (either UA or GCS) and registered with the USS. | ||||
The Broadcast RID data exchange faces extreme challenges due to the | The Broadcast RID data exchange faces extreme challenges due to the | |||
limitation of the demanding support for Bluetooth. The ASTM | limitation of the demanding support for Bluetooth. The ASTM | |||
[F3411-19] defines the basic RID message which is expected to contain | [F3411-19] defines the basic RID message which is expected to contain | |||
certain RID data and the Authentication message. The Basic RID | certain RID data and the Authentication message. The Basic RID | |||
message has a maximum payload of 25 bytes and the maximum size | message has a maximum payload of 25 bytes and the maximum size | |||
allocated by ASTM for the RID is 20 bytes and only 3 bytes are left | allocated by ASTM for the RID is 20 bytes. currently, the | |||
unused. currently, the authentication maximum payload is defined to | authentication maximum payload is defined to be 201 bytes (9 paged | |||
be 201 bytes. | Bluetooth 4 messages). | |||
Editor-note 7: To be more specific about the RID message header | ||||
and payload structure, such as 1) list different type of BRID | ||||
messages defined in ASTM F3411, 2) how many bytes for each filed. | ||||
Standard approaches like X.509 and PKI will not fit these | ||||
constraints, even using the new EdDSA [RFC8032] algorithm cannot fit | ||||
within the maximum 201 byte limit, due in large measure to ASN.1 | ||||
encoding format overhead. | ||||
An example of a technology that will fit within these limitations is | ||||
an enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] | ||||
using Hierarchical HITs (HHITs) for UAS RID [I-D.ietf-drip-rid]. As | ||||
PKI with X.509 is being used in other systems with which UAS RID must | ||||
interoperate (e.g. Discovery and Synchronization Service and any | ||||
other communications involving USS) mappings between the more | ||||
flexible but larger X.509 certificates and the HHIT-based structures | ||||
can must be devised. This could be as in [RFC8002] or simply the | ||||
HHIT as Subject Alternative Name (SAN) and no Distinguished Name | ||||
(DN). | ||||
Editor-note 8: is there a need to explain the how binding/proxy/ | ||||
translation between the HHIT and X509? Should this be addressed | ||||
in Arch- or solution? | ||||
A self-attestation of the HHIT RID can be done in as little as 84 | ||||
bytes, by avoiding an explicit encoding technology like ASN.1 or | ||||
Concise Binary Object Representation (CBOR [RFC8949]). This | ||||
compressed attestation consists of only the HHIT, a timestamp, and | ||||
the EdDSA signature on them. | ||||
Editor-note 9: to be more specific regarding how HHIT can only use | ||||
as little as 84 bytes to address the crypto concern. | ||||
The HHIT prefix and suiteID provide crypto agility and implicit | ||||
encoding rules. Similarly, a self-attestation of the Hierarchical | ||||
registration of the RID (an attestation of a RID third-party | ||||
registration "certificate") can be done in 200 bytes. Both these are | ||||
detailed in UAS RID [I-D.ietf-drip-rid]. | ||||
Editor-note 10: to be more specific why 200 bytes is sufficient. | ||||
An Observer would need Internet access to validate a self- | ||||
attestations claim. A third-party Certificate can be validated via a | ||||
small credential cache in a disconnected environment. This third- | ||||
party Certificate is possible when the third-party also uses HHITs | ||||
for its identity and the UA has the public key and the Certificate | ||||
for that HHIT. | ||||
4.2. HIT as A Trustworthy DRIP Entity Identifier | 4.2. HIT as A Trustworthy DRIP Entity Identifier | |||
Editor-note 15: general comments about rewrite of this section due | ||||
to lack of coherence. | ||||
A Remote ID that can be trustworthily used in the RID Broadcast mode | A Remote ID that can be trustworthily used in the RID Broadcast mode | |||
can be built from an asymmetric keypair. Rather than using a key | can be built from an asymmetric keypair. Rather than using a key | |||
signing operation to claim ownership of an ID that does not guarantee | signing operation to claim ownership of an ID that does not guarantee | |||
name uniqueness, in this method the ID is cryptographically derived | name uniqueness, in this method the ID is cryptographically derived | |||
directly from the public key. The proof of ID ownership (verifiable | directly from the public key. The proof of ID ownership (verifiable | |||
attestation, versus mere claim) is guaranteed by signing this | attestation, versus mere claim) is guaranteed by signing this | |||
cryptographic ID with the associated private key. The association | cryptographic ID with the associated private key. The association | |||
between the ID and the private key is ensured by cryptographically | between the ID and the private key is ensured by cryptographically | |||
binding the public key with the ID, more specifically the ID results | binding the public key with the ID, more specifically the ID results | |||
from the hash of the public key. It is statistically hard for | from the hash of the public key. It is statistically hard for | |||
skipping to change at page 13, line 28 ¶ | skipping to change at page 12, line 20 ¶ | |||
The HITs is designed statistically unique through the cryptographic | The HITs is designed statistically unique through the cryptographic | |||
hash feature of second-preimage resistance. The cryptographically- | hash feature of second-preimage resistance. The cryptographically- | |||
bound addition of the Hierarchy and an HHIT registration process | bound addition of the Hierarchy and an HHIT registration process | |||
(e.g. based on Extensible Provisioning Protocol, [RFC5730]) provide | (e.g. based on Extensible Provisioning Protocol, [RFC5730]) provide | |||
complete, global HHIT uniqueness. This registration forces the | complete, global HHIT uniqueness. This registration forces the | |||
attacker to generate the same public key rather than a public key | attacker to generate the same public key rather than a public key | |||
that generates the same HHIT. This is in contrast to general IDs | that generates the same HHIT. This is in contrast to general IDs | |||
(e.g. a UUID or device serial number) as the subject in an X.509 | (e.g. a UUID or device serial number) as the subject in an X.509 | |||
certificate. | certificate. | |||
Editor-note 11: Explain how HIT itself and HHIT registry address | ||||
naming collision. | ||||
A DRIP identifier can be assigned to a UAS as a static HHIT by its | A DRIP identifier can be assigned to a UAS as a static HHIT by its | |||
manufacturer, such as a single HI and derived HHIT encoded as a | manufacturer, such as a single HI and derived HHIT encoded as a | |||
hardware serial number per [CTA2063A]. Such a static HHIT can only | hardware serial number per [CTA2063A]. Such a static HHIT can only | |||
be used to bind one-time use DRIP identifiers to the unique UA. | be used to bind one-time use DRIP identifiers to the unique UA. | |||
Depending upon implementation, this may leave a HI private key in the | Depending upon implementation, this may leave a HI private key in the | |||
possession of the manufacturer (more details in Section 8). | possession of the manufacturer (more details in Section 8). | |||
In another case, a UAS equipped for Broadcast RID can be provisioned | In another case, a UAS equipped for Broadcast RID can be provisioned | |||
not only with its HHIT but also with the HI public key from which the | not only with its HHIT but also with the HI public key from which the | |||
HHIT was derived and the corresponding private key, to enable message | HHIT was derived and the corresponding private key, to enable message | |||
skipping to change at page 14, line 11 ¶ | skipping to change at page 12, line 44 ¶ | |||
device can be provisioned either with public keys of the DRIP | device can be provisioned either with public keys of the DRIP | |||
identifier root registries or certificates for subordinate | identifier root registries or certificates for subordinate | |||
registries. | registries. | |||
HHITs can also be used throughout the USS/UTM system. The Operators, | HHITs can also be used throughout the USS/UTM system. The Operators, | |||
Private Information Registries, as well as other UTM entities, can | Private Information Registries, as well as other UTM entities, can | |||
use HHITs for their IDs. Such HHITs can facilitate DRIP security | use HHITs for their IDs. Such HHITs can facilitate DRIP security | |||
functions such as used with HIP to strongly mutually authenticate and | functions such as used with HIP to strongly mutually authenticate and | |||
encrypt communications. | encrypt communications. | |||
A self-attestation of the HHIT RID can be done in as little as 84 | ||||
bytes, by avoiding an explicit encoding technology like ASN.1 or | ||||
Concise Binary Object Representation (CBOR [RFC8949]). This | ||||
attestation consists of only the HHIT, a timestamp, and the EdDSA | ||||
signature on them. | ||||
An Observer would need Internet access to validate a self- | ||||
attestations claim. A third-party Certificate can be validated via a | ||||
small credential cache in a disconnected environment. This third- | ||||
party Certificate is possible when the third-party also uses HHITs | ||||
for its identity and the UA has the public key and the Certificate | ||||
for that HHIT. | ||||
4.3. HHIT for DRIP Identifier Registration and Lookup | 4.3. HHIT for DRIP Identifier Registration and Lookup | |||
Remote ID needs a deterministic lookup mechanism that rapidly | Remote ID needs a deterministic lookup mechanism that rapidly | |||
provides actionable information about the identified UA. Given the | provides actionable information about the identified UA. Given the | |||
size constraints imposed by the Bluetooth 4 broadcast media, the | size constraints imposed by the Bluetooth 4 broadcast media, the | |||
Remote ID itself needs to be the inquiry input into the lookup. An | Remote ID itself needs to be a non-spoofable inquiry input into the | |||
HHIT DRIP identifier contains cryptographically embedded registration | lookup. | |||
information. This HHIT registration hierarchy, along with the IPv6 | ||||
prefix, is trustable and sufficient information that can be used to | ||||
perform such a lookup. Additionally, the IPv6 prefix can enhance the | ||||
HHITs use beyond the basic Remote ID function (e.g use in HIP, | ||||
[RFC7401]). | ||||
Editor-note 12: more description regarding 1) Is that something we | ||||
should address in the Arch- 2) if yes, then adding more text about | ||||
how a trustable lookup is performed | ||||
Therefore, a DRIP identifier can be represented as a HHIT. It can be | A DRIP registration process based on the explicit hierarchy within a | |||
self-generated by a UAS (either UA or GCS) and registered with the | HHIT provides manageable uniqueness of the HI for the HHIT (defense | |||
Private Information Registry (More details in Section 5.2) identified | against a cryptographic hash second pre-image attack on the HHIT; | |||
in its hierarchy fields. Each DRIP identifier represented as an HHIT | e.g. multiple HIs yielding the same HHIT). A lookup of the HHIT into | |||
can not be used more than once. | this registration data provides the registered HI for HHIT proof. A | |||
first-come-first-serve registration for a HHIT provides deterministic | ||||
access to any other needed actionable information based on inquiry | ||||
access authority (more details in Section 5.2). | ||||
4.4. HHIT for DRIP Identifier Cryptographic | 4.4. HHIT for DRIP Identifier Cryptographic | |||
The only (known to the authors of this document at the time of its | The only (known to the authors of this document at the time of its | |||
writing) extant fixed-length ID cryptographically derived from a | writing) extant fixed-length ID cryptographically derived from a | |||
public key are the Host Identity Tag [RFC7401], HITs, and | public key are the Host Identity Tag [RFC7401], HITs, and | |||
Cryptographically Generated Addresses [RFC3972], CGAs. However, both | Cryptographically Generated Addresses [RFC3972], CGAs. However, both | |||
HITs and CGAs lack registration/retrieval capability. HHIT, on the | HITs and CGAs lack registration/retrieval capability. HHIT, on the | |||
other hand, is capable of providing a cryptographic hashing function, | other hand, is capable of providing a cryptographic hashing function, | |||
along with a registration process to mitigate the probability of a | along with a registration process to mitigate the probability of a | |||
hash collision (first registered, first allowed). | hash collision (first registered, first allowed). | |||
5. DRIP Identifier Registration and Registries | 5. DRIP Identifier Registration and Registries | |||
Editor-note 16: Fundamentally disagree with not actually | DRIP registries hold both public and private UAS information | |||
specifying an architecture in the DRIP Architecture document (From | ||||
Stuart Card) | ||||
UAS registries can hold both public and private UAS information | ||||
resulting from the DRIP identifier registration process. Given these | resulting from the DRIP identifier registration process. Given these | |||
different uses, and to improve scalability, security, and simplicity | different uses, and to improve scalability, security, and simplicity | |||
of administration, the public and private information can be stored | of administration, the public and private information can be stored | |||
in different registries. A DRIP identifier is amenable to handling | in different registries. This section introduces the public and | |||
as an Internet domain name (at an arbitrary level in the hierarchy). | private information registries for DRIP identifiers. | |||
It also can be registered in at least a pseudo-domain (e.g. .ip6.arpa | ||||
for reverse lookup), or as a sub-domain (for forward lookup). This | ||||
section introduces the public and private information registries for | ||||
DRIP identifiers. | ||||
5.1. Public Information Registry | 5.1. Public Information Registry | |||
5.1.1. Background | 5.1.1. Background | |||
The public registry provides trustable information such as | The public registry provides trustable information such as | |||
attestations of RID ownership and HDA registration. Optionally, | attestations of RID ownership and registration with the HDA | |||
pointers to the repositories for the HDA and RAA implicit in the RID | (Hierarchical HIT Domain Authority). Optionally, pointers to the | |||
can be included (e.g. for HDA and RAA HHIT|HI used in attestation | repositories for the HDA and RAA (Registered Assigning | |||
signing operations). This public information will be principally | Authority)implicit in the RID can be included (e.g., for HDA and RAA | |||
used by Observers of Broadcast RID messages. Data on UAS that only | HHIT|HI used in attestation signing operations). This public | |||
use Network RID, is only available via an Observer's Net-RID DP that | information will be principally used by Observers of Broadcast RID | |||
would tend to provide all public registry information directly. The | messages. Data on UAS that only use Network RID, is available via an | |||
Observer can visually "see" these UAS, but they are silent to the | Observer's Net-RID DP that would tend to directly provide all public | |||
Observer; the Net-RID DP is the only source of information based on a | registry information. The Observer may visually "see" these Net-RID | |||
query for an airspace volume. | UAS, but they may be silent to the Observer. The Net-RID DP is the | |||
only source of information based on a query for an airspace volume. | ||||
5.1.2. Proposed Approach | 5.1.2. DNS as the Public DRIP Identifier Registry | |||
A DRIP public information registry can respond to standard DNS | A DRIP identifier is amenable to handling as an Internet domain name | |||
queries, in the definitive public Internet DNS hierarchy. If a DRIP | (at an arbitrary level in the hierarchy, e.g. in .ip6.arpa). Thus | |||
public information registry lists, in a HIP RR, any HIP RVS servers | DNS can provide all the needed public DRIP information. A | |||
for a given DRIP identifier, those RVS servers can restrict relay | standardized HHIT FQDN (Fully Qualified Domain Name) can deliver the | |||
services per AAA policy; this requires extensions to [RFC8004]. | HI via a HIP RR (Resource Record) [RFC8005] and other public | |||
These public information registries can use secure DNS transport | information (e.g., RRA and HDA ptrs, and HIP RVS (Rendezvous Servers) | |||
(e.g. DNS over TLS) to deliver public information that is not | [RFC8004]). These public information registries can use secure DNS | |||
inherently trustable (e.g. everything other than attestations). | transport (e.g. DNS over TLS) to deliver public information that is | |||
not inherently trustable (e.g. everything other than attestations). | ||||
5.2. Private Information Registry | 5.2. Private Information Registry | |||
5.2.1. Background | 5.2.1. Background | |||
The private information required for DRIP identifiers is similar to | The private information required for DRIP identifiers is similar to | |||
that required for Internet domain name registration. A DRIP | that required for Internet domain name registration. A DRIP | |||
identifier solution can leverage existing Internet resources: | identifier solution can leverage existing Internet resources: | |||
registration protocols, infrastructure and business models, by | registration protocols, infrastructure, and business models, by | |||
fitting into an ID structure compatible with DNS names. This implies | fitting into an ID structure compatible with DNS names. The HHIT | |||
some sort of hierarchy, for scalability, and management of this | hierarchy can provide the needed scalability and management | |||
hierarchy. It is expected that the private registry function will be | structure. It is expected that the private registry function will be | |||
provided by the same organizations that run a USS, and likely | provided by the same organizations that run a USS, and likely | |||
integrated with a USS. | integrated with a USS. The lookup function may be implemented by the | |||
Net-RID DPs. | ||||
5.2.2. Proposed Approach | 5.2.2. EPP and RDAP as the Private DRIP Identifier Registry | |||
A DRIP private information registry can support essential Internet | A DRIP private information registry supports essential registry | |||
domain name registry operations (e.g. add, delete, update, query) | operations (e.g. add, delete, update, query) using interoperable open | |||
using interoperable open standard protocols. It can also support the | standard protocols. It can accomplish this by using the Extensible | |||
Extensible Provisioning Protocol (EPP) and the Registry Data Access | Provisioning Protocol (EPP [RFC5730]) and the Registry Data Access | |||
Protocol (RDAP) with access controls. It might be listed in a DNS: | Protocol (RDAP RFC7480] [RFC7482] [RFC7483]). The DRIP private | |||
that DNS could be private; but absent any compelling reasons for use | information registry in which a given UAS is registered needs to be | |||
of private DNS, a public DNS hierarchy needs to be in place. The | findable, starting from the UAS ID, using the methods specified in | |||
DRIP private information registry in which a given UAS is registered | [RFC7484]. | |||
needs to be findable, starting from the UAS ID, using the methods | ||||
specified in [RFC7484]. A DRIP private information registry can also | 5.2.3. Alternative Private DRIP Registry methods | |||
support WebFinger as specified in [RFC7033]. | ||||
A DRIP private information registry might be an access controlled DNS | ||||
(e.g. via DNS over TLS). Additionally, WebFinger [RFC7033] can be | ||||
deployed. These alternative methods may be used by Net-RID DP with | ||||
specific customers. | ||||
6. Harvesting Broadcast Remote ID messages for UTM Inclusion | 6. Harvesting Broadcast Remote ID messages for UTM Inclusion | |||
ASTM anticipated that regulators would require both Broadcast RID and | ASTM anticipated that regulators would require both Broadcast RID and | |||
Network RID for large UAS, but allow RID requirements for small UAS | Network RID for large UAS, but allow RID requirements for small UAS | |||
to be satisfied with the operator's choice of either Broadcast RID or | to be satisfied with the operator's choice of either Broadcast RID or | |||
Network RID. The EASA initially specified Broadcast RID for UAS of | Network RID. The EASA initially specified Broadcast RID for UAS of | |||
essentially all UAS and is now also considering Network RID. The FAA | essentially all UAS and is now also considering Network RID. The FAA | |||
RID Final Rules [FAA_RID] only specify Broadcast RID for UAS, | RID Final Rules [FAA_RID] only specify Broadcast RID for UAS, | |||
however, still encourages Network RID for complementary | however, still encourages Network RID for complementary | |||
skipping to change at page 19, line 29 ¶ | skipping to change at page 18, line 29 ¶ | |||
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | <https://www.govinfo.gov/content/pkg/FR-2021-01-15/ | |||
pdf/2020-28948.pdf>. | pdf/2020-28948.pdf>. | |||
[FAA_UAS_Concept_Of_Ops] | [FAA_UAS_Concept_Of_Ops] | |||
United States Federal Aviation Administration (FAA), | United States Federal Aviation Administration (FAA), | |||
"Unmanned Aircraft System (UAS) Traffic Management (UTM) | "Unmanned Aircraft System (UAS) Traffic Management (UTM) | |||
Concept of Operations (V2.0)", 2020, | Concept of Operations (V2.0)", 2020, | |||
<https://www.faa.gov/uas/research_development/ | <https://www.faa.gov/uas/research_development/ | |||
traffic_management/media/UTM_ConOps_v2.pdf>. | traffic_management/media/UTM_ConOps_v2.pdf>. | |||
[I-D.ietf-drip-rid] | ||||
Moskowitz, R., Card, S. W., Wiethuechter, A., and A. | ||||
Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, | ||||
draft-ietf-drip-rid-07, 28 January 2021, | ||||
<https://www.ietf.org/archive/id/draft-ietf-drip-rid- | ||||
07.txt>. | ||||
[Implementing] | [Implementing] | |||
European Union Aviation Safety Agency (EASA), "EU | European Union Aviation Safety Agency (EASA), "EU | |||
Commission Implementing Regulation 2019/947 of 24 May 2019 | Commission Implementing Regulation 2019/947 of 24 May 2019 | |||
on the rules and procedures for the operation of unmanned | on the rules and procedures for the operation of unmanned | |||
aircraft", 2019. | aircraft", 2019. | |||
[LAANC] United States Federal Aviation Administration (FAA), "Low | [LAANC] United States Federal Aviation Administration (FAA), "Low | |||
Altitude Authorization and Notification Capability", n.d., | Altitude Authorization and Notification Capability", n.d., | |||
<https://www.faa.gov/uas/programs_partnerships/ | <https://www.faa.gov/uas/programs_partnerships/ | |||
data_exchange/>. | data_exchange/>. | |||
skipping to change at page 20, line 36 ¶ | skipping to change at page 19, line 28 ¶ | |||
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. | [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. | |||
Henderson, "Host Identity Protocol Version 2 (HIPv2)", | Henderson, "Host Identity Protocol Version 2 (HIPv2)", | |||
RFC 7401, DOI 10.17487/RFC7401, April 2015, | RFC 7401, DOI 10.17487/RFC7401, April 2015, | |||
<https://www.rfc-editor.org/info/rfc7401>. | <https://www.rfc-editor.org/info/rfc7401>. | |||
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access | [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access | |||
Protocol (RDAP) Query Format", RFC 7482, | Protocol (RDAP) Query Format", RFC 7482, | |||
DOI 10.17487/RFC7482, March 2015, | DOI 10.17487/RFC7482, March 2015, | |||
<https://www.rfc-editor.org/info/rfc7482>. | <https://www.rfc-editor.org/info/rfc7482>. | |||
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the | ||||
Registration Data Access Protocol (RDAP)", RFC 7483, | ||||
DOI 10.17487/RFC7483, March 2015, | ||||
<https://www.rfc-editor.org/info/rfc7483>. | ||||
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data | [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data | |||
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March | (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March | |||
2015, <https://www.rfc-editor.org/info/rfc7484>. | 2015, <https://www.rfc-editor.org/info/rfc7484>. | |||
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token | |||
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7519>. | <https://www.rfc-editor.org/info/rfc7519>. | |||
[RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol | ||||
Certificates", RFC 8002, DOI 10.17487/RFC8002, October | ||||
2016, <https://www.rfc-editor.org/info/rfc8002>. | ||||
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) | [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) | |||
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, | Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, | |||
October 2016, <https://www.rfc-editor.org/info/rfc8004>. | October 2016, <https://www.rfc-editor.org/info/rfc8004>. | |||
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name | |||
Signature Algorithm (EdDSA)", RFC 8032, | System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, | |||
DOI 10.17487/RFC8032, January 2017, | October 2016, <https://www.rfc-editor.org/info/rfc8005>. | |||
<https://www.rfc-editor.org/info/rfc8032>. | ||||
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, | |||
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, | |||
May 2018, <https://www.rfc-editor.org/info/rfc8392>. | May 2018, <https://www.rfc-editor.org/info/rfc8392>. | |||
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
Representation (CBOR)", STD 94, RFC 8949, | Representation (CBOR)", STD 94, RFC 8949, | |||
DOI 10.17487/RFC8949, December 2020, | DOI 10.17487/RFC8949, December 2020, | |||
<https://www.rfc-editor.org/info/rfc8949>. | <https://www.rfc-editor.org/info/rfc8949>. | |||
End of changes. 40 change blocks. | ||||
232 lines changed or deleted | 170 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |