draft-ietf-drip-registries-03.txt   draft-ietf-drip-registries-04.txt 
drip Working Group A. Wiethuechter (Editor) drip Working Group A. Wiethuechter (Editor)
Internet-Draft S. Card Internet-Draft S. Card
Intended status: Standards Track AX Enterprize, LLC Intended status: Standards Track AX Enterprize, LLC
Expires: 12 November 2022 R. Moskowitz Expires: 26 December 2022 R. Moskowitz
HTT Consulting HTT Consulting
J. Reid J. Reid
RTFM llp RTFM llp
11 May 2022 24 June 2022
DRIP Entity Tag Registration & Lookup DRIP Entity Tag Registration & Lookup
draft-ietf-drip-registries-03 draft-ietf-drip-registries-04
Abstract Abstract
This document creates the DRIP DET registration and discovery This document creates the DRIP DET registration and discovery
ecosystem. This includes all components in the ecosystem (e.g., RAA, ecosystem. This includes all components in the ecosystem (e.g., RAA,
HDA, UA, GCS, USS). The registration process will use the Extensible HDA, UA, GCS, USS). The registration process will use the Extensible
Provisioning Protocol (EPP) and other protocols. The discovery Provisioning Protocol (EPP) and other protocols. The discovery
process will leverage DNS and DNSSEC and related technology. The process will leverage DNS and DNSSEC and related technology. The
DETs can be registered with as their "raw public keys" or in X.509 DETs can be registered with as their "raw public keys" or in X.509
certificates. certificates.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 12 November 2022. This Internet-Draft will expire on 26 December 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Registered Assigning Authorities . . . . . . . . . . 7 3.1.2. Registered Assigning Authorities . . . . . . . . . . 7
3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7 3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7
3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 8 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 8
4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 9 4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 9
4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 9
4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 10
5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 10 5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 10
5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 11 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registering a Registry . . . . . . . . . . . . . . . . . 11 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 12
6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 12 6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 12
6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 13 6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 13
6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 14 6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 14
6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 15 6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 15
6.2. Registering a Serial Number . . . . . . . . . . . . . . . 16 6.2. Registering a Serial Number . . . . . . . . . . . . . . . 16
6.3. Registering an Operator . . . . . . . . . . . . . . . . . 18 6.3. Registering an Operator . . . . . . . . . . . . . . . . . 18
6.4. Registering a Session ID . . . . . . . . . . . . . . . . 19 6.4. Registering a Session ID . . . . . . . . . . . . . . . . 19
6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 21 6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 21
6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 23 6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 23
6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 24 6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 22 skipping to change at page 3, line 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 31 10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 34 Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 34
A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 34 A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 34
A.1.1. Attestor Identity Information . . . . . . . . . . . . 35 A.1.1. Attestor Identity Information . . . . . . . . . . . . 36
A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 36 A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 36
A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 36 A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 36
A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 36 A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 36
A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 36 A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 36 A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 37
A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 37 A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 37
A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 38 A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 38
A.2.3. Concise Attestation (CA-x.y) . . . . . . . . . . . . 39 A.2.3. Concise Attestation (CA-x.y) . . . . . . . . . . . . 39
A.2.4. Mutual Attestation (MA-x.y) . . . . . . . . . . . . . 40 A.2.4. Mutual Attestation (MA-x.y) . . . . . . . . . . . . . 40
A.2.5. Link Attestation (LA-x.y) . . . . . . . . . . . . . . 41 A.2.5. Link Attestation (LA-x.y) . . . . . . . . . . . . . . 41
A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 42 A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 42
A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 44
A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 44 A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 44
A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 45 A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 45
A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 45 A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 45
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 48 Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 48
B.1. Certificate Policy and Certificate Stores . . . . . . . . 49 B.1. Certificate Policy and Certificate Stores . . . . . . . . 49
B.2. Certificate Management . . . . . . . . . . . . . . . . . 49 B.2. Certificate Management . . . . . . . . . . . . . . . . . 49
B.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 50 B.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 50
B.4. Alternative Certificate Encoding . . . . . . . . . . . . 50 B.4. Alternative Certificate Encoding . . . . . . . . . . . . 50
Appendix C. Blockchain-based Registries . . . . . . . . . . . . 50 Appendix C. Blockchain-based Registries . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Registries are fundamental to RID. Only very limited information can Registries are fundamental to Remote ID (RID). Only very limited
be Broadcast, but extended information is sometimes needed. The most operational information can be Broadcast, but extended information is
essential element of information sent is the UAS ID itself, the sometimes needed. The most essential element of information sent is
unique key for lookup of extended information in registries. the UAS ID itself, the unique key for lookup of extended information
in registries.
While it is expected that registry functions will be integrated with While it is expected that registry functions will be integrated with
USS, who will provide them is not yet determined in most, and is USS, who will provide them is not yet determined in most, and is
expected to vary between, jurisdictions. However this evolves, the expected to vary between, jurisdictions. However this evolves, the
essential registry functions, starting with management of essential registry functions, starting with management of
identifiers, are expected to remain the same, so are specified identifiers, are expected to remain the same, so are specified
herein. herein.
While most data to be sent via Broadcast or Network RID is public, While most data to be sent via Broadcast or Network RID is public,
much of the extended information in registries will be private. Thus much of the extended information in registries will be private. Thus
skipping to change at page 4, line 41 skipping to change at page 4, line 42
The intent of the negative and positive access control requirements The intent of the negative and positive access control requirements
on registries is to ensure that no member of the public would be on registries is to ensure that no member of the public would be
hindered from accessing public information, while only duly hindered from accessing public information, while only duly
authorized parties would be enabled to access private information. authorized parties would be enabled to access private information.
Mitigation of Denial of Service attacks and refusal to allow database Mitigation of Denial of Service attacks and refusal to allow database
mass scraping would be based on those behaviors, not on identity or mass scraping would be based on those behaviors, not on identity or
role of the party submitting the query per se, but querant identity role of the party submitting the query per se, but querant identity
information might be gathered (by security systems protecting DRIP information might be gathered (by security systems protecting DRIP
implementations) on such misbehavior. implementations) on such misbehavior.
Registration under DRIP is vital as the worry of collisions in the Registration under DRIP is vital to manage the inevitable collisions
hash portion of the DET. Forgery of the DET is still possible, but in the hash portion of the DET. Forgery of the DET is still
including it as a part of a public registration mitigates a lot of possible, but including it as a part of a public registration
the risk. This document creates the DRIP DET registration and mitigates this risk. This document creates the DRIP DET registration
discovery ecosystem. This includes all components in the ecosystem and discovery ecosystem. This includes all components in the
(e.g., RAA, HDA, UA, GCS, USS). The registration process will use ecosystem (e.g., RAA, HDA, UA, GCS, USS). The registration process
the Extensible Provisioning Protocol (EPP) and other protocols. The will use the Extensible Provisioning Protocol (EPP) and other
discovery process will leverage DNS and DNSSEC and related protocols. The discovery process will leverage DNS and DNSSEC and
technology. The DETs can be registered with as their "raw public related technology. The DETs can be registered with as their "raw
keys" or in X.509 certificates. public keys" or in X.509 certificates.
1.1. Abstract Process & Reasoning 1.1. Abstract Process & Reasoning
In DRIP each entity (registry, operator and aircraft) is expected to In DRIP each entity (registry, operator and aircraft) is expected to
generate a full DRIP Entity ID [drip-rid] on the local device their 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 key is expected to be used. These are registered with a Public
Information Registry within the hierarchy along with whatever data is Information Registry within the hierarchy along with whatever data is
required by the cognizant CAA and the registry. Any PII is stored in required by the cognizant CAA and the registry. Any PII is stored in
a Private Information Registry protected through industry practice a Private Information Registry protected through industry practice
AAA or better. In response, the entity will obtain an attestation or AAA or better. In response, the entity will obtain an attestation or
skipping to change at page 7, line 19 skipping to change at page 7, line 19
manages a registry of HDAs (Section 3.1.3). Most are contemplated to manages a registry of HDAs (Section 3.1.3). Most are contemplated to
be Civil Aviation Authorities (CAA), such as the Federal Aviation be Civil Aviation Authorities (CAA), such as the Federal Aviation
Authority (FAA), that then delegate HDAs to manage their NAS. This Authority (FAA), that then delegate HDAs to manage their NAS. This
is does not preclude other entities to operate an RAA if the Root is does not preclude other entities to operate an RAA if the Root
server allows it. server allows it.
The ICAO registration process will be available from ICAO. Once ICAO The ICAO registration process will be available from ICAO. Once ICAO
accepts an RAA, it will assign a number and create a zone delegation accepts an RAA, it will assign a number and create a zone delegation
under the uas.icao.int. DNS zone for the RAA. under the uas.icao.int. DNS zone for the RAA.
As HHITs may be used in many different domains, RAA should be As DETs may be used in many different domains, RAA should be
allocated in blocks with consideration on the likely size of a allocated in blocks with consideration on the likely size of a
particular usage. Alternatively, different prefixes can be used to particular usage. Alternatively, different prefixes can be used to
separate different domains of use of HHITs. separate different domains of use of HHITs.
An RAA must provide a set of services to allocate HDAs to An RAA must provide a set of services to allocate HDAs to
organizations. It must have a public policy on what is necessary 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 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 HID RVS servers. All RAA's use an HDA value of 0 and have their RAA
value delegated to them by the Root. value delegated to them by the Root.
3.1.2.1. ICAO Registry of Manufacturer's (IRM) 3.1.2.1. ICAO Registry of Manufacturer's (IRM)
A special RAA that hands out HDA values to participating An RAA-level registry that hands out HDA values to participating
Manufacturer's that hold an ICAO Manufacturer Code used in ANSI Manufacturer's that hold an ICAO Manufacturer Code used in ANSI
CTA2063-A Serial Numbers. CTA2063-A Serial Numbers.
It is holds the RAA value of 1 and HDA value of 0. It is holds the RAA value of 1 and HDA value of 0.
3.1.3. Hierarchial HIT Domain Authorities 3.1.3. Hierarchial HIT Domain Authorities
An HDA may be an ISP or any third party that takes on the business to An HDA may be an USS, ISP, or any third party that takes on the
provide RVS and other needed services such as those required for HIP- business to register the actual UAS entities that need DETs. This
enabled devices. 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 an 14-bit field (16,384 HDAs per RAA) of a DET assigned by 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 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 that may use HIP. How this is done and scales to the potentially
millions of customers are outside the scope of this document. This millions of customers are outside the scope of this document. This
service should be discoverable through the DNS zone maintained by the service should be discoverable through the DNS zone maintained by the
HDA's RAA. HDA's RAA.
An RAA may assign a block of values to an individual organization. An RAA may assign a block of values to an individual organization.
This is completely up to the individual RAA's published policy for This is completely up to the individual RAA's published policy for
delegation. Such policy is out of scope. delegation. Such policy is out of scope.
3.1.3.1. Manufacturer's Registry of Aircraft (MRA) 3.1.3.1. Manufacturer's Registry of Aircraft (MRA)
A registry (HDA) run by a manufacturer of UAS systems that An HDA-level registry run by a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific participate in Remote ID. Stores UAS Serial Numbers under a specific
ICAO Manufacturer Code (assigned to the manufacturer by ICAO). ICAO Manufacturer Code (assigned to the manufacturer by ICAO).
A DET can be encoded into a Serial Number (see [drip-rid]) and this 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 registry would hold a mapping from the Serial Number to the DET and
its artifacts. its artifacts.
Hold RAA value of 1 and HDA values of 1+. Hold RAA value of 1 and HDA values of 1+.
3.1.3.2. Remote ID Registries (RIDR) 3.1.3.2. Remote ID Registries (RIDR)
Registry that holds the binding between a UAS Session ID (for DRIP An HDA-level registry that holds the binding between a UAS Session ID
the DET) and the UA Serial Number. The Serial Number MUST have its (for DRIP the DET) and the UA Serial Number. The Serial Number MUST
access protected to allow only authorized parties to obtain. The have its access protected to allow only authorized parties to obtain.
Serial Number SHOULD be encrypted in a way only the authorized party The Serial Number SHOULD be encrypted in a way only the authorized
can decrypt. party can decrypt.
As part of the UTM system they also hold a binding between a UAS ID As part of the UTM system they also hold a binding between a UAS ID
(Serial Number or Session ID) and an Operational Intent. (Serial Number or Session ID) and an Operational Intent.
Hold RAA values of 2+ and HDA values of 1+. Hold RAA values of 2+ and HDA values of 1+.
3.2. Key Rollover & Federation 3.2. Key Rollover & Federation
During key rollover the entity MUST inform all children and parents During key rollover the entity MUST inform all children and parents
of the change - using best standard practices of a key rollover. At of the change - using best standard practices of a key rollover. At
skipping to change at page 9, line 13 skipping to change at page 9, line 13
thoroughly studied at this time. thoroughly studied at this time.
4. DRIP Fully Qualified Domain Names 4. DRIP Fully Qualified Domain Names
Under DRIP there are a number of FQDN forms used to allow lookups to Under DRIP there are a number of FQDN forms used to allow lookups to
take place. take place.
The individual DETs may be potentially too numerous (e.g., 60 - 600M) 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 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 signed, DNS zone. The HDA SHOULD provide DNS service for its zone
and provide the HHIT detail response. A secure connection (e.g., DNS and provide the DET detail response.
over TLS) to the authoritative zone may be a viable alternative to
DNSSEC. DNSSEC is strongly recommended (especially for RAA-level zones).
Frequency of updates, size of the zone, and registry policy may
impact its use.
4.1. Serial Number 4.1. Serial Number
See Section 4.2 of [drip-rid] for how to encode DETs as Serial
Numbers.
Serial Number: 8653FZ2T7B8RA85D19LX Serial Number: 8653FZ2T7B8RA85D19LX
ICAO Mfr Code: 8653 ICAO Mfr Code: 8653
Length Code: F Length Code: F
ID: FZ2T7B8RA85D19LX ID: FZ2T7B8RA85D19LX
FQDN: Z2T7B8RA85D19LX.F.8653.mfr.uas.icao.int FQDN: Z2T7B8RA85D19LX.8653.mfr.uas.icao.int
4.2. DET 4.2. DET
The DET reverse lookup can be a standard IPv6 reverse look up, or it DETs SHOULD be discoverable in DNS via a hash.oga.hda.raa.prefix.
can leverage off the HHIT structure. If we assume a prefix of structure under a ICAO managed DNS aviation tree. This document
2001:30::/28: proposes a .det.uas.icao.int. branch in the current ICAO DNS domain.
This is subject of discussions with ICAO. Thus if we assume a DET
prefix of 2001:30::/28, the following example shows the resultant DNS
entry:
DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e
ID: a3ad:1952:0ad0:a69e ID: a3ad:1952:0ad0:a69e
OGA: 5 OGA: 5
HDA: 0014 = 20 HDA: 0014 = 20
RAA: 000a = 10 RAA: 000a = 10
Prefix: 20010030 Prefix: 20010030
FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int
When building a DET FQDN the following two things must be done: When building a DET FQDN the following two things must be done:
1. The RAA and HDA values MUST be converted from hexadecimal to 1. The RAA and HDA values MUST be converted from hexadecimal to
decimal form decimal form.
2. The FQDN must be built using the expanded form of the IPv6 2. The FQDN must be built using the expanded form of the IPv6
address address.
The prefix is included in the FQDN form to support other potential The prefix is included in the FQDN form to support other potential
prefixes being used. prefixes being used.
4.3. Reverse DET 4.3. Reverse DET
The DET reverse lookup should be a standard IPv6 reverse address in
ip6.arpa.
$ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa. $ORIGIN 5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR
5. Supported DNS Records 5. Supported DNS Records
DRIP requires a number of resource records, some specific to certain DRIP requires a number of resource records, some specific to certain
registries to function. registries to function.
5.1. HIP RR 5.1. HIP RR
All registries will have their own DET associated with them and their All registries will have their own DET associated with them and their
respective DNS server will hold a HIP RR that is pointed to by their respective DNS server will hold a HIP RR [RFC8005] that is pointed to
DET FQDN. by their DET FQDN.
MRA and RIDR servers will also have HIP RRs for their registered MRA and RIDR servers will also have HIP RRs for their registered
parties (aircraft and operators). parties (aircraft and operators).
5.2. CERT RR 5.2. CERT RR
Most attestations can be placed into DNS. An exception to this is Most attestations can be placed into DNS. An exception to this is
the Attestation Certificate made during Session ID registration. the Attestation Certificate made during Session ID registration.
This is as this particular certificate acts similar to a car This is as this particular certificate acts similar to a car
registration and should be held safe by the operator. registration and should be held safe by the operator.
These should be held in CERT RRs [RFC4398].
5.3. NS RR 5.3. NS RR
Along with their associated "glue" record (A/AAAA) supports the Along with their associated "glue" record (A/AAAA) supports the
traversal in DNS across the tree. traversal in DNS across the tree.
1. <mfr.remoteid.aero> on Root points to specific DET FQDN of IRM 1. <mfr.remoteid.aero> on Root points to specific DET FQDN of IRM
2. <icao_mfr_code>.mfr.remoteid.aero on IRM points to specific DET 2. <icao_mfr_code>.mfr.remoteid.aero on IRM points to specific DET
FQDN of MRA FQDN of MRA
skipping to change at page 11, line 20 skipping to change at page 11, line 30
includes data being stored on its children. includes data being stored on its children.
The best example of this is RIDR would have a SVR RR that points to a The best example of this is RIDR would have a SVR RR that points to a
database that contains any extra information of a Session ID it has database that contains any extra information of a Session ID it has
registered. Another example is the MRA has a SVR RR pointing to registered. Another example is the MRA has a SVR RR pointing to
where the metadata of a UA registered in the MRA can be located. 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, In all cases the server being pointed to MUST be protected using AAA,
specifically using RDAP. specifically using RDAP.
##
5.6. TLSA RR 5.6. TLSA RR
This RR is mainly used to support DTLS deployments where the DET is This RR [RFC6698] is mainly used to support DTLS deployments where
used in Network RID and the wider UTM system. 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.
6. Registry Operations 6. Registry Operations
As a general rule the following processing performed for any As a general rule the following processing performed for any
registration operation: registration operation:
1. Verify input Attestations from registering party 1. Verify input Attestations from registering party
2. Check for collision of DET and HI 2. Check for collision of DET and HI
skipping to change at page 33, line 18 skipping to change at page 33, line 18
Huque, S., Dukhovni, V., and A. Wilson, "TLS Client Huque, S., Dukhovni, V., and A. Wilson, "TLS Client
Authentication via DANE TLSA records", Work in Progress, Authentication via DANE TLSA records", Work in Progress,
Internet-Draft, draft-ietf-dance-client-auth-00, 24 March Internet-Draft, draft-ietf-dance-client-auth-00, 24 March
2022, <https://www.ietf.org/archive/id/draft-ietf-dance- 2022, <https://www.ietf.org/archive/id/draft-ietf-dance-
client-auth-00.txt>. client-auth-00.txt>.
[drip-arch] [drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S., Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft, (DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-22, 21 March 2022, draft-ietf-drip-arch-24, 10 June 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-arch- <https://www.ietf.org/archive/id/draft-ietf-drip-arch-
22.txt>. 24.txt>.
[drip-auth] [drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Entity
Authentication Formats & Protocols for Broadcast Remote Tag Authentication Formats & Protocols for Broadcast
ID", Work in Progress, Internet-Draft, draft-ietf-drip- Remote ID", Work in Progress, Internet-Draft, draft-ietf-
auth-09, 30 April 2022, <https://www.ietf.org/archive/id/ drip-auth-14, 21 June 2022,
draft-ietf-drip-auth-09.txt>. <https://www.ietf.org/archive/id/draft-ietf-drip-auth-
14.txt>.
[drip-requirements] [drip-requirements]
Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP) Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153, Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022, DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>. <https://www.rfc-editor.org/info/rfc9153>.
[drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-uas-rid-01, 9 September 2020, draft-ietf-drip-uas-rid-01, 9 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid- <https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
01.txt>. 01.txt>.
[drip-secure-nrid-c2] [drip-secure-nrid-c2]
Moskowitz, R., Card, S. W., Wiethuechter, A., and A. Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "Secure UAS Network RID and C2 Transport", Work in Gurtov, "Secure UAS Network RID and C2 Transport", Work in
Progress, Internet-Draft, draft-moskowitz-drip-secure- Progress, Internet-Draft, draft-moskowitz-drip-secure-
nrid-c2-06, 5 May 2022, <https://www.ietf.org/archive/id/ nrid-c2-09, 17 June 2022,
draft-moskowitz-drip-secure-nrid-c2-06.txt>. <https://www.ietf.org/archive/id/draft-moskowitz-drip-
secure-nrid-c2-09.txt>.
[hhit-registries] [hhit-registries]
Moskowitz, R., Card, S. W., and A. Wiethuechter, Moskowitz, R., Card, S. W., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet- "Hierarchical HIT Registries", Work in Progress, Internet-
Draft, draft-moskowitz-hip-hhit-registries-02, 9 March Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
2020, <https://www.ietf.org/archive/id/draft-moskowitz- 2020, <https://www.ietf.org/archive/id/draft-moskowitz-
hip-hhit-registries-02.txt>. hip-hhit-registries-02.txt>.
[NPRM] "Notice of Proposed Rule Making on Remote Identification [NPRM] "Notice of Proposed Rule Making on Remote Identification
of Unmanned Aircraft Systems", December 2019. 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>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[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>.
[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>.
[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>.
Appendix A. DRIP Attestations & Certificates Appendix A. DRIP Attestations & Certificates
See [drip-arch] for definitions of claim, assertion, attestation and See [drip-arch] for definitions of claim, assertion, attestation and
certificate as used in this document. certificate as used in this document.
A.1. Attestation Structure A.1. Attestation Structure
 End of changes. 34 change blocks. 
57 lines changed or deleted 88 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/