# drafts

name: draft-wiethuechter-drip-det-tada
rev: 01
title: Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness
time: 2025-10-02T17:42:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-05T17:42:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.326892+00:00
source: ietf
source_id: 148848
source_url: https://datatracker.ietf.org/doc/draft-wiethuechter-drip-det-tada/
doc_status: active
abstract:
  This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

full_text:
  drip Working Group                                       A. Wiethuechter
  Internet-Draft                                        AX Enterprize, LLC
  Intended status: Standards Track                            R. Moskowitz
  Expires: 5 April 2026                                     HTT Consulting
                                                            2 October 2025


    Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain
                                 Awareness
                    draft-wiethuechter-drip-det-tada-01

  Abstract

     This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

  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 5 April 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 1]


  Internet-Draft                  det-tada                    October 2025


     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
       1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Additional Definitions  . . . . . . . . . . . . . . . . .   5
     3.  Interactions & Responsibilities . . . . . . . . . . . . . . .   6
       3.1.  UAS Observers . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  UAS Operators . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  UAS Manufacturers . . . . . . . . . . . . . . . . . . . .   8
       3.4.  HDA Operators . . . . . . . . . . . . . . . . . . . . . .   9
       3.5.  RAA Operators . . . . . . . . . . . . . . . . . . . . . .  10
       3.6.  Apex Operators  . . . . . . . . . . . . . . . . . . . . .  11
     4.  Requirements for DIME Operation . . . . . . . . . . . . . . .  11
       4.1.  Common UAS RID Data Model . . . . . . . . . . . . . . . .  11
       4.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .  13
         4.2.1.  Disclaimer  . . . . . . . . . . . . . . . . . . . . .  13
         4.2.2.  Interaction Model . . . . . . . . . . . . . . . . . .  13
         4.2.3.  Interface & Encoding  . . . . . . . . . . . . . . . .  15
         4.2.4.  Registration Model  . . . . . . . . . . . . . . . . .  17
         4.2.5.  Response Model  . . . . . . . . . . . . . . . . . . .  19
       4.3.  Query . . . . . . . . . . . . . . . . . . . . . . . . . .  20
         4.3.1.  Public Information Registries . . . . . . . . . . . .  21
         4.3.2.  Private Information Registries  . . . . . . . . . . .  21
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
       5.1.  RAA Delegation for CAAs . . . . . . . . . . . . . . . . .  23
       5.2.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . .  23
       5.3.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .  23
       5.4.  Media Types . . . . . . . . . . . . . . . . . . . . . . .  24
         5.4.1.  application/drip+cwt Registration . . . . . . . . . .  24
         5.4.2.  application/drip+jwt Registration . . . . . . . . . .  25
       5.5.  DRIP CBOR/JSON Keys . . . . . . . . . . . . . . . . . . .  25
         5.5.1.  Review Criteria . . . . . . . . . . . . . . . . . . .  26
         5.5.2.  CBOR/JSON Key Fields  . . . . . . . . . . . . . . . .  27
         5.5.3.  Registration Form . . . . . . . . . . . . . . . . . .  27
         5.5.4.  Initial Values  . . . . . . . . . . . . . . . . . . .  27
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
       6.1.  Cryptographic Materials . . . . . . . . . . . . . . . . .  30
     7.  Privacy & Transparency Considerations . . . . . . . . . . . .  30
       7.1.  DETs as Session ID and Authentication Key ID  . . . . . .  31
       7.2.  Selective Encryption  . . . . . . . . . . . . . . . . . .  31
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 2]


  Internet-Draft                  det-tada                    October 2025


       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  33
     Appendix A.  DRIP CDDL Prelude  . . . . . . . . . . . . . . . . .  36
     Appendix B.  HID Abbreviation . . . . . . . . . . . . . . . . . .  37
     Appendix C.  Compliance Testing . . . . . . . . . . . . . . . . .  39
       C.1.  Registration Interface  . . . . . . . . . . . . . . . . .  39
       C.2.  Public Query Interface  . . . . . . . . . . . . . . . . .  40
       C.3.  Private Query Interface . . . . . . . . . . . . . . . . .  40
       C.4.  Compliance Submission Forms . . . . . . . . . . . . . . .  40
     Appendix D.  DRIP Key Infrastructure X.509 (DKIX) . . . . . . . .  40
       D.1.  Signing Request . . . . . . . . . . . . . . . . . . . . .  41
       D.2.  Lite Profile  . . . . . . . . . . . . . . . . . . . . . .  42
       D.3.  Full Profile  . . . . . . . . . . . . . . . . . . . . . .  44
       D.4.  Certificate Fields  . . . . . . . . . . . . . . . . . . .  46
         D.4.1.  Serial Number . . . . . . . . . . . . . . . . . . . .  46
         D.4.2.  Subject . . . . . . . . . . . . . . . . . . . . . . .  46
         D.4.3.  Issuer  . . . . . . . . . . . . . . . . . . . . . . .  47
         D.4.4.  Subject Alternative Name IP6  . . . . . . . . . . . .  47
         D.4.5.  Subject Alternative Name URI  . . . . . . . . . . . .  47
         D.4.6.  Subject Key Identifier  . . . . . . . . . . . . . . .  48
         D.4.7.  Authority Key Identifier  . . . . . . . . . . . . . .  48
         D.4.8.  CA Policy OIDs  . . . . . . . . . . . . . . . . . . .  48
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  51

  1.  Introduction

  1.1.  Purpose

     This document provides to stakeholders in a National Airspace System
     (NAS), such as a Civil Aviation Authority (CAA) and its constituents,
     a point of entry into a set of relevant standards.  These standards
     provide guidance to enable trustworthy Air Domain Awareness (ADA)
     primarily via cooperative technologies.  Such technologies can
     include, but are not limited to, Unmanned Aircraft (UA) Systems (UAS)
     Remote Identification (RID), UAS Traffic Management (UTM) and
     Advanced Air Mobility (AAM).

     This document specifies an interoperable manner of achieving the
     stated objectives in an international context to be used by CAAs in a
     relevant Means of Compliance (MOC).  One such MOC is ASTM [F3586] for
     UAS RID to comply with the United States (US) CAA regulations.

     A CAA MAY override any technical specification in this document but
     MUST, if claiming compliance with this document, provide the reason
     and an alternative specification satisfying the same objective.






  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 3]


  Internet-Draft                  det-tada                    October 2025


  1.2.  Background

     [RFC9153] provides comprehensive background on the UAS RID use-case
     and the UTM/AAM context.

     Trustworthiness revolves around identification and authentication.
     [RFC9374] defines the Drone Remote Identification Protocol (DRIP)
     Entity Tag (DET), a trustable identifier backed by asymmetric
     cryptography.  [RFC9575] standardizes authentication of DETs and
     associated information using strong cryptography suited for
     constrained mobile wireless links (typical of Broadcast RID).
     Broadcast and Network RID are defined by ASTM [F3411] which
     designates the International Civil Aviation Organization (ICAO) to
     maintain code-points for Specific Session ID Types and Specific
     Authentication Methods (SAMs) [ICAO-NUMBERS].  ICAO includes DETs as
     a Specific Session ID Type and lists the four DRIP SAMs.

     DETs generated by registrants (typically a UAS Operator or UAS) are
     merely proposed until they are registered within the hierarchy
     consisting of at least two levels above the leaf DET: Registered
     Assigning Authority (RAA) and Hierarchial Host Identity Tag (HHIT)
     Domain Authority (HDA).  The registry system, made up of DRIP
     Identity Management Entities (DIMEs) acting as either RAAs or HDAs,
     ensures uniqueness within the hierarchy, endorses inclusion through
     X.509 certificates, and provides access to public and private
     information associated with a DET registration.  Public information
     is served using the Domain Name System (DNS) and is specified in
     [DET-DNS].  Private information, such as Personally Identifiable
     Information (PII), is served using the Registration Data Access
     Protocol (RDAP, [STD95]) and protected through policy based
     differentiated access.

     This document specifies fundamental registration processes and
     interactions surrounding the Private Information Registry function
     defined in the DRIP Architecture ([RFC9434]).

  1.3.  Scope

     Participating entities are assumed in this document to be in
     compliance with relevant existing UAS standards such as ASTM [F3411],
     [F3548] and [ICAO-ACCP].

     This document governs use of a DET in the following cases:

     1.  An entity that uses a Session ID (some participating entities,
         e.g. HDAs, may not need Session IDs), MUST use a DET for that
         Session ID.




  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 4]


  Internet-Draft                  det-tada                    October 2025


     2.  An entity that participates in DRIP interactions (even if not
         needing a Session ID), MUST use a DET for the DRIP public
         authentication key ID in those interactions.

     3.  An entity that requires a strongly cryptographically verifiable
         IP compatible identifier, MAY use a DET for any other legal
         purpose.

     4.  An entity SHOULD NOT use a DET as a locator in physical or
         logical space (e.g. as a globally routable IPv6 address outside
         of an overlay network), as deconflation is intended, see
         [RFC9063].

     The archetypal case is a UAS for which the DET serves as both the UAS
     ID (first case above) and the Authentication Key ID (second case).

        Author Note: narrow context for at least first bullet above.

  2.  Terminology

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

  2.1.  Additional Definitions

     This document makes use of terms (PII, USS, etc.) defined in
     [RFC9153], [RFC9434] and [RFC9374].  For convenience of the reader,
     some of the major definitions are restated here.

     DRIP Identity Management Entity (DIME):  Originally defined in
        [RFC9434] and expanded technically in [DET-DNS].  An entity
        providing registrar and registry services specifically for DETs.
        They can act as either an Registered Assigning Authority (RAA) or
        Hierarchial Host Identity Tag (HHIT) Domain Authority (HDA).

     Web Token:  In the context of this specification; a Web Token can be
        either a Concise Binary Object Representation (CBOR, [STD94]) Web
        Token (CWT, [RFC8392]) or JavaScript Object Notation (JSON,
        [STD90]) Web Token (JWT, [RFC7519]).









  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 5]


  Internet-Draft                  det-tada                    October 2025


  3.  Interactions & Responsibilities

     This section outlines the various entity roles in the ecosystem.  For
     each, it summarizes motivations for participating in that DRIP role,
     as well as the interactions and responsibilities they have in doing
     so.  All entity roles, except as otherwise noted, MUST register a DET
     with a parent entity in the corresponding parental role (e.g. an HDA
     must register with an RAA), as per Section 4.2, and MUST use it
     subsequently in all DRIP interactions requiring an entity ID.

  3.1.  UAS Observers

     An Observer is typically an individual who has a device capable of
     wirelessly receiving Broadcast RID whether it be an opportunistic
     passerby with a local-only (i.e. non-Internet connected) smartphone
     application or a widely deployed sensing system with various IP-based
     back-hauls.  Each has their own motivations for detecting a UAS in
     their area and querying for additional information.  Typically in
     DRIP, Observers are expected to use DNS (when able) to obtain at
     least the public keys of unknown DETs and use it to validate
     signatures found in ASTM [F3411] Authentication Messages.  Some
     Observers may be granted, by cognizant authorities, authorization to
     perform more detailed queries of further information, that is
     considered private (as not explicitly classified as public, placed in
     DNS, and/or transmitted in cleartext in Broadcast RID).

        Author Note: Broadcast RID here can be dropped or substituted for
        some phrase comparing Observers to a sensor head, but distinct
        from a Display-only Observer.  If that makes sense and if it is a
        good distinction to have?  One could say Display Applications are
        in a way Observers (albeit very far removed from the field in most
        cases where the term is used).  Unless we make them their own
        class of users that could use DETs (and for what?)

     All Observers supporting DRIP:

     *  MUST adhere to relevant details of Section 6.4.2 of [RFC9575] with
        regards to receive processing of DRIP SAMs.

        -  Processing of SAMs MAY be deferred or outsourced to a dedicated
           system.

     *  RECOMMEND display all DETs following [RFC5952] or as described in
        Appendix B.







  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 6]


  Internet-Draft                  det-tada                    October 2025


        Author Note: as justification for "processing MAY be deferred":
        Intention here was to allow for Observers not needing to fully
        process data if desired and push said processing to SDSPs.  An
        example is a slim Finder concept that does no parsing of RID data,
        just extraction out of transport framing.

     Observers authorized by cognizant authorities to access any private
     (in addition to all public) information recorded as part of the
     registration process also:

     *  MUST support RDAP authentication/authorization mechanisms allowed
        by the cognizant authority.

        -  Those RECOMMENDED for global harmonization are identified in
           Section 4.3.2.4.

     *  MUST register to authentication systems as required by the
        cognizant authority.

        -  A DIME MAY be used as part of an authentication system.

  3.2.  UAS Operators

     UAS Operators is used herein as a catch-all term for several more
     specific UAS related roles: Remote Pilot, Pilot In Command (PIC),
     party (typically an organization) to whom or which the UAS is
     registered with the cognizant CAA, etc.  DRIP does not attempt to
     clarify the definition of Operator to match any specific CAA, instead
     using the ambiguity to group these roles based on their similar DRIP
     interactions.

     A UAS Operator's desire to use DETs can be any number of the
     following operational factors:

     *  Confidentiality of flights through Session IDs.

     *  Privacy of Remote Pilots by encrypting their Ground Control
        Station (GCS) position.

        -  This option may be constrained by their jurisdiction's RID
           regulations.

     *  Reputation of their UAS based on observation and reports of
        behavior supported by Authentication.

     To participate a UAS Operator SHOULD use a DET, registered either
     with an RAA or HDA, as part of any interactions in DRIP, such as
     registering a UAS Session ID for their UA.  A UAS Operator MAY use



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 7]


  Internet-Draft                  det-tada                    October 2025


     another cryptographic scheme for interactions but it MUST be
     asymmetric with their public key accessible to all domain
     participants via a standardized method for the cryptographic purpose
     of signature verification.

  3.3.  UAS Manufacturers

     While UAS Manufactures do not have a direct requirement for DRIP,
     they typically wish to maintain good reputation of their brands and
     are often driven by market forces.  Such forces include requirements
     and preferences of both UAS Observers and Operators.

     This document assumes a UAS Manufacturer is already in compliance
     with ASTM [F3411].  Thus those that wish to support DRIP also:

     *  MUST provide a mechanism, typically through a GCS, to generate and
        register a DET for use as either a Session ID, Authentication Key
        ID or both.

        -  MUST bind DET to both UAS Serial Number and Operator.  Binding
           MAY be indirect if system can verify Serial Number already
           registered to Operator.

        -  SHOULD be issued in a manner that keeps private key ONLY ever
           on UA, does not expose it to GCS etc., but MAY be done in
           manner that exposes it to GCS or Operator if necessary.

        -  SHOULD allow user selection of a parent DIME (typically HDA)
           using a URI, Hierarchy ID (HID) value, or both

        -  MAY support registering multiple DETs in a batch transaction

     *  SHOULD provide a mechanism to enable, during registration,
        subsequent encryption of selected fields (e.g. pilot/GCS
        location), only if the CAA allows it.

     *  MUST follow Section 6 of [RFC9575] as it relates to transmission
        of SAMs, when using DET as an Authentication Key ID

     *  MUST, in the [F3411] Basic ID Message, set the UAS ID Type to
        Specific Session ID, Specific Session ID Type to DRIP Entity ID,
        and encode the DET in network byte order, when using DET as a UAS
        Session ID

     *  MAY use a DET, following Section 4.2 of [RFC9374], as a UAS Serial
        Number





  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 8]


  Internet-Draft                  det-tada                    October 2025


        -  It is expected that the UAS Manufacturer runs their own HDA,
           under which these DETs are registered

  3.4.  HDA Operators

     In the UTM context, it is expected that the HDA function will be
     provided by a UAS Service Supplier (USS) to its clients (e.g. UAS
     Operators).  This can be in-house or out-sourced to a service bureau
     more specialized in cryptographically verifiable identifiers usable
     to access data and systems on networks.  Outside the UTM context, an
     HDA can be a stand-alone provider to any registrant desiring a DET,
     or more generally HHIT.

     Being associated with a USS has some operational benefits:

     *  Ease for UAS Operators to use both Session IDs and UTM together

     *  Binding between the DET and Operational Intent

        -  Enables safer use of encryption

        -  Ability to keep DET private until just before an operation goes
           active

     An HDA Operator:

     *  MUST register, with its parent RAA, one or more DETs, and use it
        or them in DRIP interactions

     *  MUST implement interfaces and functions described in Section 4

     *  MUST maintain DET registrations with relevant PII as required by
        their jurisdiction

     *  MUST fulfill the requirements of their jurisdiction

     *  SHOULD NOT provide to clients the ability to enable encryption of
        data elements considered PII, especially in Broadcast RID

     As part of a USS an HDA Operator also:

     *  MAY provide encryption ID services, if allowed by jurisdiction

     *  MAY have its registration interfaces (Section 4.2) be integrated
        into relevant USS interfaces and functions

     *  SHOULD defer the publishing of a client DET in DNS when it is
        bound with an Operational Intent until it is "active"



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 9]


  Internet-Draft                  det-tada                    October 2025


        -  Methods to sync an Operational Intent in a USS state and DET
           state in HDA are out of scope for this document

  3.5.  RAA Operators

     In the context of this document, RAA Operators are typically CAAs or
     other cognizant authorities of a Nation State.  Each Nation State is
     allocated four RAA values that are used at their discretion.  To
     obtain these allocations, a Nation State contacts the Apex operator
     for the UAS or other applicable hierarchy, currently IANA on behalf
     of ICAO, requesting their provisioning providing any details required
     by the Apex Operator to configure domain delegations.

     Each RAA has the responsibility to delegate HDAs under them.
     Allocation methods of HDA values are at the discretion of the RAA
     Operator and their policies.  Any requirements to operate under an
     RAA, beyond those as defined in this document to operate as an HDA,
     are out of scope for this document.

     An RAA Operator:

     *  MUST obtain an RAA value(s) from the Apex Operator and provide
        content for NS RRType(s), see Section 5

     *  MUST register, with its parent (if any), one or more DETs, and use
        it or them in DRIP interactions

     *  MUST implement interfaces and functions described in Section 4

     *  MUST maintain DET registrations with relevant PII as required by
        their jurisdiction

     *  MUST provide requirements for prospective HDA Operators, and
        SHOULD do so publicly via an easily located web site

     *  MUST ensure HDA Operator compliance with this specification

        Author Note: subsection or appendix on a potential RAA scheme for
        CAA? i.e. 1x MIL, 1x GOV, 1x COMMERCIAL, 1x SPARE with some
        example guidance on HDA allocation?











  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 10]


  Internet-Draft                  det-tada                    October 2025


  3.6.  Apex Operators

     The Apex role is the administration root and the domain apex for a
     specific IPv6 prefix which are typically associated with an industry
     sector (i.e. DETs being for aviation).  This translates to the
     technical tasking of delegating RAA values and maintaining the
     reverse DNS zone associated with the allocated IPv6 prefix which
     contain the DNS delegations to RAAs.  An Apex in its capacity as the
     administration root MAY endorse the required RAA delegation in the
     hierarchy.

     Currently IANA performs the functions of RAA delegation (with no
     endorsement) and DNS zone maintenance for the DET prefix.  This is
     largely a custodial task as critical portions of the RAA range, with
     regards to aviation, are already reserved or allocated with the rest
     of the range unassigned.

     In the context of aviation pre-allocated RAAs to CAAs are currently
     expected to mutually cross-certify as specified in [ICAO-ACCP].

  4.  Requirements for DIME Operation

     The requirements below apply to both RAA and HDA Operators with a
     focus on how HDA Operators provide registration and related services
     for their clients (i.e. UAS Operators and their UAS).  All data
     models are represented in this document using the Concise Data
     Definition Language (CDDL, [RFC8610]) using the prelude defined in
     Appendix E of [RFC8610] as well as an additional DRIP-specific
     prelude defined in Appendix A.

  4.1.  Common UAS RID Data Model

     A common data model is specified by DRIP for various UAS RID elements
     typically transmitted over ASTM [F3411].

     The field names and their general typing of Figure 1 are borrowed
     from the ASTM [F3411] data dictionary (Table 1 and Table 2).  See
     that document for additional context and background information on
     aviation application-specific interpretation of the field semantics.
     The contents of this model are considered opaque to DRIP.

     The model is an expansion upon the BRID RRType model, which only
     contained static data, defined in Section 5.2 of [DET-DNS].








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 11]


  Internet-Draft                  det-tada                    October 2025


     uas-datum = {
       ? timestamp => utc,
       ? uas_type => 0..15,
       ? uas_ids => [
         + [
           id_type: 0..15,
           uas_id: uas-id
         ]
       ],
       ? ua_status => 0..15,
       ? ua_position => [
         lla: position,
         barometric_altitude: number / null
       ],
       ? ua_bearing => uint,
       ? ua_speed => [
         vertical: number / null,
         horizontal: number / null
       ],
       ? ua_height => [
         agl: bool,
         height: number
       ],
       ? accuracy => [
         vertical: 0..15,
         horizontal: 0..15,
         altitude: 0..15,
         barometric: 0..15,
         timestamp: 0..15
       ],
       ? auth => [
         + [
           auth_type: 0..15,
           data: auth-data
         ]
       ],
       ? self_id => [
         desc_type: 0..255,
         desc: tstr .size 23
       ],
       ? operator_position => position,
       ? classification => [
         region: 0..8,
         category: 0..15,
         class: 0..15
       ],
       ? area => [
         count: 1..255,



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 12]


  Internet-Draft                  det-tada                    October 2025


         radius: number,
         floor: number,
         ceiling: number
       ],
       ? operator_id => [
         operator_type: 0..255,
         operator_id: tstr .size 20
       ],
       ? compliance => [+ uint]
     }

                         Figure 1: Common UAS RID CDDL

     The mapping between JSON keys (as strings) and CBOR keys (as unsigned
     integers) for Figure 1 are defined in Section 5.5.

        Author Note: do we specify the enumeration for compliance in this
        document?  Is it an IANA registry?

  4.2.  Registration

     This section defines the interaction model, data models and methods
     for registration of a DET into a DIME for global interoperability.
     Standardization of additional methods and data models to register to
     a DIME (DETs or otherwise) is out of scope for this document.

  4.2.1.  Disclaimer

     DRIP does NOT provide protection against incorrect (e.g. fraudulent)
     data entered during registration or asserted subsequently.  DRIP does
     protect against alteration (intentional or unintentional) of data
     subsequent to its assertion by the cryptographic signer.  The signer
     might be the proximate sender (e.g. UA transmitting Broadcast RID) or
     might be an attestor far away and long ago (e.g. root Certificate
     Authority).  It is the duty of the operator of each DIME, or the
     party on whose behalf the DIME is being operated, to validate the
     registration data.  The RAA (e.g. CAA) SHOULD provide services to
     obtain this goal, see Section 4.2.4.1.

  4.2.2.  Interaction Model

     Registration of DETs uses the interaction model shown in Figure 2.









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 13]


  Internet-Draft                  det-tada                    October 2025


                       registrant             dime
                           |                   |
           (0) GEN_DET/HI  |                   |
           (1) GEN_CSR     |                   |
                           |----(2) INPUT----->|
                           |                   | (3) VALID_INPUT?
                           |<-------FAIL-------|
                           |                   | (4) DUPE_HI?
                           |<-------FAIL-------|
                           |                   | (5) DUPE_DET?
                           |<-------FAIL-------|
                           |                   | (6) GEN_CERTS
                           |                   | (7) UPDATE_DATABASE
                           |                   | (8) UPDATE_NS
                           |<----(9) OUTPUT----|

                Figure 2: Simplified DET Registration Z-Diagram

     (0) GEN_DET/HI:  The registrant that plans to use the identity and
        its cryptographic properties SHOULD generate the asymmetric key-
        pair of their choosing and MUST protect the private key with Best
        Current Practices.  The registrant MAY derive the corresponding
        DET.  How the registrant obtains the desired HID for DET
        generation is out of scope for this document.

     (1) GEN_CSR:  The registrant MUST generate a Certificate Signing
        Request (CSR) for their HI/DET.  See Appendix D.1 for more
        details.

     (2) INPUT:  The registrant MUST format and send the required
        information for a given service registration as specified by the
        DIME using Section 4.2.3.

     (3) VALID_INPUT?:  The DIME, upon receipt of service registration
        inputs, MUST validate the input data.  This may be simply
        performing syntax checks to ensure the data is properly formatted
        all the way to full semantic validation (see Section 4.2.4.1).
        Signed data MUST have their signatures verified before further
        processing.  Failure of input validation SHOULD returns errors to
        the registrant.

     (4) DUPE_HI?:  The DIME MUST check that the proposed HI is not a
        already in use within the specified HID scope.  The registrant
        SHOULD be notified with an error if duplication is detected.

     (5) DUPE_DET?:  The DIME MUST check that the proposed DET, derived





  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 14]


  Internet-Draft                  det-tada                    October 2025


        from the HI, is not a already in use within the specified HID
        scope.  If the registrant proposed a DET with HID outside that of
        the DIME, it MUST be rejected.  If the registrant only provided
        the HI, the DIME MUST generate the DET using the HID for which
        that DIME is authoritative.  The registrant SHOULD be notified
        with an error if duplication is detected.

     (6) GEN_CERTS:  The DIME, after all the above validation, MUST
        generate a Broadcast Endorsement using the provided HI and DET
        from the registrant as the evidence.  This Endorsement is used in
        [RFC9575].  The DIME MUST also generate a corresponding X.509
        certificate as per Section 4.2.5.1, confirming that the DIME has
        accepted the registrant's DET/HI pair for registration.  Other
        Certificates MAY be generated during registration but are out of
        scope for this document.

     (7) UPDATE_DATABASE:  The DIME MUST update the Private Information
        Registry with all registration data required by the jurisdiction
        or the DIME's own policy, typically including PII, all of which
        must be protected by AAA as per applicable regulation and policy.
        It MAY include additional metadata or public information.  How the
        Private Information Registry is updated is out of scope for this
        document.

     (8) UPDATE_NS:  The DIME MUST update the Authoritative Name Server
        with any public information that was part of the registration.
        This information MUST be stored as described in [DET-DNS].

     (9) OUTPUT:  The DIME, upon successful updates of the Private
        Information Registry and Authoritative Name Server, responds
        according to Section 4.2.3.

  4.2.3.  Interface & Encoding

     Registration request and response data MUST be encapsulated in a Web
     Token (either CWT [RFC8392] or JWT [RFC7519]).  For Session IDs and
     Authentication Key IDs the registrant usually is the Operator (or a
     proxy for the Operator such as the GCS) but MAY be the UA directly if
     the UA has a long term cryptographic identity.

     The method for a registrant to find a DIME is out of scope for this
     document.  DIMEs MUST use [RFC8615] to provide DRIP-related
     interfaces and perform redirects to the relevant URIs.  DIME
     registration endpoints MUST use POST expecting a Web Token from
     registrants.  During a request a registrant MUST encrypt the Web
     Token in accordance with PRIV-2 of Section 4.3.1 of [RFC9153] as
     during a request it typically includes PII.  An example is shown in
     Figure 3.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 15]


  Internet-Draft                  det-tada                    October 2025


        Author Note: /.well-known/ could be a single URI like register-
        hhit or more specific ones like uas-operator and uas-session.  Do
        we have a preference?

     POST /.well-known/register-hhit HTTP/1.1
     Host: uss.example.com
     Accept: application/drip+cwt, application/drip+jwt
     Content-Type: application/drip+cwt
     Content-Length: <CWT length>

     [ CWT from registrant ]

               Figure 3: Example REST Registration API (request)

     The DIME responds, upon successful registration, with their own Web
     Token contain the data model defined in Section 4.2.5.  The Web Token
     SHOULD be encrypted, if containing any PII.  An example is shown in
     Figure 4.

     HTTP/1.1 200 OK
     Accept: application/drip+cwt, application/drip+jwt
     Content-Type: application/drip+cwt

     [ CWT from DIME ]

               Figure 4: Example REST Registration API (response)

     This document allocates application/drip+cwt, application/drip+jwt
     and application/drip to the Media Types registry.  It also allocates
     register-hhit to the /.well-known/ registry.

  4.2.3.1.  Using CoAP for Registration

     Support of the Constrained Application Protocol (CoAP, [RFC7252]) is
     OPTIONAL.

     When using CoAP, DTLS SHOULD be used when possible and MUST send the
     data models (Section 4.2.4 and Section 4.2.5) encoded as CBOR.  When
     DTLS is not possible, and CoAP is instead used with UDP, model data
     MUST be encapsulated, signed and encrypted in a CWT as above.

  4.2.3.2.  Guidance on Registration Errors

     The following registration failure conditions and response are
     informative:

     *  Upon invalid input from the registrant, the DIME SHOULD respond
        with either 400 (Bad Request) or 403 (Forbidden) as appropriate.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 16]


  Internet-Draft                  det-tada                    October 2025


     *  Upon a duplicate HI or DET, the DIME SHOULD respond with 409
        (Conflict).

     *  Any other processing failure of registration by a DIME SHOULD be
        responded with an appropriate Server Error status code.

     Care should be given when responding with 403 (Forbidden) to not
     expose any information that could be used to socially engineer a fake
     request.  For example, when following Section 4.2.4.1, it would be
     unwise for the HDA to detail an exact reason for the rejection.  A
     malicious registrant could spam the endpoint, farming information on
     what UAS Serial Numbers, Operator IDs and their potential bindings
     exist to exploit.

     It should be noted that the above would be avoided with properly
     configured systems since signature validation and denial of service
     mitigations would be before the HDA even attempts to ascertain
     validation from the RAA.

  4.2.4.  Registration Model

     The data sent to the DIME for a given registration is policy driven.
     For example a Session ID registration SHOULD include a CAA specific
     identifier of the Operator to enable the private binding of the
     Session ID to both the Serial Number (found in the CSR, Appendix D.1)
     but also the Operator themselves.

     registration-content = {
       csr_list: [
         + csr: [
           idx: hash,
           entity_type: uint,
           csr: x509,
           vnb: utc / null,
           vna: utc / 1..15638400 / null,
           meta: { metadata }
         ]
       ],
       metadata
     }

                       Figure 5: Registration Model CDDL









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 17]


  Internet-Draft                  det-tada                    October 2025


     The data model defined in Figure 5 is what is minimally required for
     a DIME to be functional.  Additional fields SHOULD be registered to
     IANA under Section 5.5 for global harmonization.  RAAs and HDAs MAY
     use their respective keys and their associated maps to define
     additional keys to be included in a registration.  A dedicated
     Private Use space is provided for RAAs and HDAs to define keys and
     their uses.

     The uas map item uses the data model found in Section 4.1 to carry
     any static information expected to also be found over Broadcast RID.
     It MUST NOT include in the uas_ids key the UAS Serial Number when a
     Session ID is being registered.  It also MUST NOT contain the
     operator_location key, as this information is usually considered PII
     and typically is dynamic or unknown at time of registration.  The
     DIME MUST fill in the auth key with any SAMs related to a
     registration and place the data model into DNS with Section 5.2 of
     [DET-DNS] when the registrant entity is required to use Broadcast RID
     and expecting to use [RFC9575].

     The registrant can select from a number of options to encode the
     values of valid not before (vnb) and valid not after (vna) for time
     of applicability of an individual CSR (csr-data).  The use of the
     time or tdate types allow for absolute time references.  The use of
     the uint type for vna specifies a positive offset in seconds from an
     absolute time.  When null is used the registrant is informing the
     DIME that for vnb the DIME MUST use the current time as vnb during
     registration and for vna the DIME MUST set vna to a time such that
     the default DIME policy for maximum delta between vnb and vna is not
     exceeded.

        Implementation Note: due to not differentiating between integers
        and floats in its number type, implementations using JSON as the
        encoded format MUST check the value of vna to determine if its
        being used as an offset or absolute time.

     As an example of the use of vnb and vna, a registrant may set
     vnb=null and vna=3600.  The DIME in this instance would use the
     current absolute time at receipt of the registration request for vnb
     and then apply the offset specified by vna to obtain an absolute time
     for vna that is 3600 seconds after vnb.  These absolute times of vnb
     and vna are then used in the certificate being created by the DIME to
     endorse the registration Section 4.2.5.1.









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 18]


  Internet-Draft                  det-tada                    October 2025


  4.2.4.1.  Validating Fields

     In certain circumstances field contents may only be properly
     validated by other entities outside of DRIP.  For example the binding
     between UAS Serial Number and Operator ID should already be known by
     the CAA, as typically this information is required out of band of
     DRIP directly to the CAA in some form.  The CAA should provide or
     itself have access to an "oracle" that can validate these claimed
     bindings for registration to proceed.  If such an "oracle" is not
     consulted there is a risk that information being registered is
     fraudulent and DRIP has no method or authority to confirm the claims.
     If such information is accepted, future information queries by
     authorities can result in bogus data being returned, with no binding
     to an actual UAS or Operator.

     The CAA SHOULD, as part of its capacity as an RAA onboarding an HDA,
     provide data models, communication framework and any authentication
     mechanisms to query the oracle directly if the CAA allows HDAs to
     perform the queries themselves.  Otherwise the RAA MUST provide an
     HTTPS POST interface that consumes a Web Token generated by the HDA
     containing the registrant Web Token.  If the RAA is not configured or
     does not wish to handle such requests it MUST respond with 501 (Not
     Implemented), HDAs should proceed without validation as if validation
     was successful.

     If the RAA is configured to validate registration requests, it sends
     the data to the "oracle", via a mechanism out of scope for this
     document.  When the "oracle" marks data as invalid the RAA MUST
     signal to the HDA that the registration is to be denied.  Otherwise
     the RAA returns a Web Token to the HDA containing an X.509
     Certificate with the Subject set to the same contents as the
     registrant CSR.

  4.2.5.  Response Model

     response-content = [
       + [
         idx: hash,
         entity_type: uint,
         certs: {
           canonical_cert: x509,
           ? be_chain: [+ be: endorsement],
           * &(tstr , int) => any
         }
       ]
     ]

                         Figure 6: Response Model CDDL



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 19]


  Internet-Draft                  det-tada                    October 2025


     The canonical_cert key MUST be the certificate defined in
     Section 4.2.5.1.  The be_chain contains the Broadcast Endorsement
     structures defined in Section 4.1 of [RFC9575] and MAY not be sent by
     the DIME if the registrant is not expected to use Broadcast RID.

     Additional items MAY be sent back to the registrant by the DIME.
     Their keys SHOULD be registered under IANA as part of Section 5.5 to
     support global harmonization.

  4.2.5.1.  Canonical Registration Certificate

     Appendix D provides profiles for X.509 certificates adhering to the
     [ICAO-ACCP], developed by the Trust Framework Panel.  At least one of
     the DRIP profiles MUST be used.

     At least one certificate in the chain from an apex node to a leaf
     node MUST contain a URI, as part of the Subject Alternative Name
     Extension [RFC5280], which points to the relevant Private Information
     Registry containing associated PII registered.  This certificate MUST
     be contained in the HHIT RRType defined in Section 5.1 of [DET-DNS].
     The certificate MAY be anywhere on the path and SHOULD be as close to
     the apex in the path as possible for efficiency.

     At the time of publication, the current best practice is for the HDA
     Issue certificate to contain the base URI to be used for all Private
     Information Registry requests under the HDA.  When an HDA supports
     multiple Private Information Registry providers, it SHOULD set the
     appropriate URI in the Operational certificate.  The HDA MAY either
     set all different URIs together in its HDA Issue certificate at cost
     of the querent being then required to perform queries at each
     provided URI until it receives a response or use different Issuer
     DETs for each different Private Information Registry provider.

     When registering a DET to be used as a Session ID, the CSR
     Appendix D.1 MUST contain the UAS Serial Number as the Subject, and
     the certificate placed in the private registry also MUST contain the
     UAS Serial Number as the Subject, but the certificate placed in the
     public registry and used as the basis of the Broadcast Endorsement
     (or otherwise exposed publicly) MUST NOT contain the UAS Serial
     Number.

  4.3.  Query

     A DIME has two query interfaces it MUST support.  One interface is
     used for public information and the other (discoverable from public
     information) is for private information.





  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 20]


  Internet-Draft                  det-tada                    October 2025


  4.3.1.  Public Information Registries

     The information found in these registries has been designated
     (explicitly or implicitly) as public by cognizant authority and/or
     the information owner.  Such information includes asymmetric
     cryptographic public keys needed for authentication in [RFC9575],
     static Broadcast RID data and trustworthy pointers to additional
     information.

     These registries are Authoritative Name Servers in the DNS.  See
     [DET-DNS] for operational requirements, query mechanism and response
     models.

  4.3.2.  Private Information Registries

     The information found in these registries is considered Personally
     Identifiable Information (PII) and/or is stored for potential future
     audit of registration.  Access to Private Information Registries MUST
     be performed using RDAP [STD95].  This section defines RDAP behavior
     for DRIP.

  4.3.2.1.  URI Path Segment

     The URIs to Private Information resources MUST use the specification
     defined in Section 3.1.1 of [RFC9082].  Use of Section 3.1.3 of
     [RFC9082] is OPTIONAL.

  4.3.2.2.  Conformance Literal

     The string literal drip_version_0 MUST be used in the rdapConformance
     section of the RDAP response to signal conformance with this
     specification.

  4.3.2.3.  Extension Model

     Queries of DETs in RDAP SHOULD respond with the appropriate Object
     Class as defined in RFC9083 and MUST include the additional data
     element specified in Figure 7.













  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 21]


  Internet-Draft                  det-tada                    October 2025


     dime = {
       csr: x509,
       canonical_cert: x509,
       hhit: [
         entity_type: uint,
         ipv6: ip6
       ],
       be_chain: [+ be: endorsement]
       registrant: tstr,
       ? raa_approval: x509,
       metadata
     }

                          Figure 7: RDAP Response CDDL

     Additional keys SHOULD be registered to IANA under Section 5.5 for
     global harmonization.  Specification of their usage and syntax in a
     NAS is provided by CAAs using a MOC that references this
     specification.

  4.3.2.4.  Differential Access

     Per REG-2 and REG-4 of Section 4.4.1 of [RFC9153], RDAP queries to
     DRIP Private Information Registries MUST be protected using fine-
     grained AAA policies in a both human- & machine-readable form for
     automated enforcement.  RDAP supports only HTTP based mechanisms for
     authentication as defined in Section 3.2 of [RFC7481].  A federated
     authentication mechanism, such as the examples in Section 3.2.1 of
     [RFC7481], is RECOMMENDED.

     For international and/or global harmonization, DRIP standardizes the
     following RDAP behavior for authentication of clients and servers:

     *  MUST support HTTP Digest Authentication Scheme ([RFC7616]) *AND*

     *  SHOULD NOT support HTTP Basic Authentication Scheme ([RFC7617])
        but MAY accept Basic if peer offers that and nothing stronger
        *AND*

     *  MUST support Mutual TLS Section 7.4.6 of [RFC5246] for global and/
        or international queries *AND*

     *  SHOULD use Mutual TLS Section 7.4.6 of [RFC5246] but MAY do any
        other RDAP compatible AAA for domestic queries

     A DIME when supporting Mutual TLS MUST accept valid DKIX certificates
     (Appendix D) and MAY accept other certificates.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 22]


  Internet-Draft                  det-tada                    October 2025


        Author Note: the selection of Mutual TLS is an initial down
        selection from OpenID Connect for RDAP ([RFC9560]), or Mutual TLS
        (Section 7.4.6 of [RFC5246]) or eXtensible Access Control Markup
        Language (XACML) with Security Assertion Markup Language (SAML).
        This is still a discussion point.

  5.  IANA Considerations

  5.1.  RAA Delegation for CAAs

     As part of [DET-DNS] IANA already has the pre-allocated mapping of
     RAA values for CAAs.  Nations are to follow the guidance in
     Section 6.2.1.4 of [DET-DNS] to request delegation of their DNS zone
     under 3.0.0.1.0.0.2.ip6.arpa..

  5.2.  Well-Known URIs

     IANA is requested to add the following entries in the "Well-Known
     URIs" registry [WELL-KNOWN].

     +===============+============+===========+===========+=============+
     | URI Suffix    | Change     | Reference | Status    | Related     |
     |               | Controller |           |           | Information |
     +===============+============+===========+===========+=============+
     | register-hhit | IETF       | This RFC  | permanent | N/A         |
     +---------------+------------+-----------+-----------+-------------+

                Table 1: Additions to Well-Known URIs Registry

  5.3.  RDAP Extensions Registry

     IANA is request to register the following value in the "RDAP
     Extensions" registry [RDAP-EXT].

     Extension Identifier:
       drip_version_0
     Registry Operator:
       Any
     Specification:
       This specification
     Contact:
       IETF <iesg@ietf.org>
     Intended Usage:
       This extension is used to convey private information
       under an HHIT registration.






  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 23]


  Internet-Draft                  det-tada                    October 2025


  5.4.  Media Types

     IANA is requested to add the following entries in the "Media Types"
     registry [MEDIA-TYPES].

              +==========+======================+===============+
              | Name     | Template             | Reference     |
              +==========+======================+===============+
              | DRIP CWT | application/drip+cwt | Section 5.4.1 |
              +----------+----------------------+---------------+
              | DRIP JWT | application/drip+jwt | Section 5.4.2 |
              +----------+----------------------+---------------+

                   Table 2: Additions to Media Types Registry

  5.4.1.  application/drip+cwt Registration

     Type name:  application

     Subtype name:  drip+cwt

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  binary

     Security considerations:  TODO

     Interoperability considerations:  N/A

     Published specification:  This RFC

     Applications that use this media type:  Applications that access
        DIMEs requesting HHIT registration, as well as DIMEs responding to
        registration requests.

     Fragment identifier considerations:  N/A

     Person & email address to contact for further information:  DRIP WG
        mailing list (drip@ietf.org)

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author/Change controller:  IETF




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 24]


  Internet-Draft                  det-tada                    October 2025


     Provisional registration:  no

  5.4.2.  application/drip+jwt Registration

     Type name:  application

     Subtype name:  drip+jwt

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  binary, JWT values are encoded as a series
        of base64url-encoded values (with trailing '=' characters
        removed), some of which may be the empty string, separated by
        period ('.') characters.

     Security considerations:  TODO

     Interoperability considerations:  N/A

     Published specification:  This RFC

     Applications that use this media type:  Applications that access
        DIMEs requesting HHIT registration, as well as DIMEs responding to
        registration requests.

     Fragment identifier considerations:  N/A

     Person & email address to contact for further information:  DRIP WG
        mailing list (drip@ietf.org)

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author/Change controller:  IETF

     Provisional registration:  no

  5.5.  DRIP CBOR/JSON Keys

     This specification establishes a new sub-registry called "DRIP CBOR/
     JSON Keys" within the "Drone Remote ID Protocol" registry.  This
     registry is to maintain a globally harmonized list of JSON keys (i.e.
     "Names") and CBOR map integer keys (i.e. "Labels") for use in DRIP.
     The following ranges are defined based on the CBOR Label values:




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 25]


  Internet-Draft                  det-tada                    October 2025


       +========+===============+===============+=====================+
       | Range  | Registration  | Range Use     | Comments            |
       |        | Policy        |               |                     |
       +========+===============+===============+=====================+
       | from   | Private Use   | HID Private   | Private use for     |
       | -2^64  | (Section 4.1  | Keys          | RAAs and HDAs       |
       | to -25 | of [RFC8126]) |               |                     |
       +--------+---------------+---------------+---------------------+
       | from   | TODO: TBD     | ASTM UAS Keys | Keys found in ASTM  |
       | -24 to |               |               | UAS Standards such  |
       | 23     |               |               | as [F3411]          |
       +--------+---------------+---------------+---------------------+
       | from   | Specification | Global        | Reserved for future |
       | 24 to  | Required      | Harmonization | registrations to    |
       | 2^64-1 | (Section 4.6  |               | maintain global     |
       |        | of [RFC8126]) |               | harmonization       |
       +--------+---------------+---------------+---------------------+

                Table 3: DRIP CBOR/JSON Key Registry Policies

     Keys in the Private Use and Experimental ranges are RECOMMENDED to
     prepend a _ to the Name to avoid namespace collisions with registered
     Names.

     The HID Private Keys range in this registry provide code-points (used
     in Section 4.2.4 and Section 4.3.2.3 as part of metadata) for each
     RAA and HDA to define their own subset of elements in both
     registration and RDAP responses.  The spec value of this registry
     SHOULD be used to enable the DIME or client to provide a "hint" for
     the data elements included.  Specification of the spec string
     semantics are left to individual RAAs and HDAs to define as they see
     fit.  RAA and HDA Operators SHOULD provide specification for any
     Private Use or Experimental Use values, but this may not be public
     due to policy.

  5.5.1.  Review Criteria

     For registrations, review should note if the Name field matches an
     existing entry, the request should be denied.  A request should also
     be denied if the specification duplicates an existing entry both in
     syntax and semantics.  For example, if an existing key called whee
     already exists with the specification of [+ uint] and a new request
     comes along to register whee_but_mine with specification [+ uint],
     then the latter should be rejected on the grounds of being able to
     use whee instead.  This denial can be overruled if shown that the new
     registration has clear justification, as part of the specification
     citing technical reasoning, to exist.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 26]


  Internet-Draft                  det-tada                    October 2025


  5.5.2.  CBOR/JSON Key Fields

     Name (JSON Key Value):  A string value, to be used as a key in the
        key: value pair of a JSON object.  No specific rules apply for
        syntax beyond being a valid JSON string for a object key, but it
        is recommended to use all lower-case and snake-case with
        underscores.  Care should be given to the length of a Name to
        reduce wire size of JSON encodings for constrained environments.

     Label (CBOR Integer Key Value):  A integer value, ranging from -2^64
        to 2^64 - 1, to be used as a key in a CBOR map.  Different ranges
        of values use different registration policies, see Table 3.

     Description:  A short description of the entry providing an overview
        of its semantic meaning and its expected use-cases.

     Reference:  A link to a permanent and readily available specification
        defining the value syntax and semantics to be used for this key.

  5.5.3.  Registration Form

     Requested Range:
     Name (JSON Key Value):
     Description:
     Specification:

                                    Figure 8

  5.5.4.  Initial Values

       +===================+=============+=================+===========+
       | Name (JSON Key    | Label (CBOR | Description     | Reference |
       | Value)            | Integer Key |                 |           |
       |                   | Value)      |                 |           |
       +===================+=============+=================+===========+
       | uas_type          | 0           | Enumeration of  | This RFC, |
       |                   |             | UAS Type        | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | uas_ids           | 1           | UAS IDs         | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | auth              | 2           | Authentication  | This RFC, |
       |                   |             | Data            | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | self_id           | 3           | Self ID         | This RFC, |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 27]


  Internet-Draft                  det-tada                    October 2025


       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | classification    | 4           | UA Category &   | This RFC, |
       |                   |             | Class           | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | area              | 5           | Area Count,     | This RFC, |
       |                   |             | Radius, etc.    | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | operator_id       | 6           | Operator ID     | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_status         | 7           | Enumeration of  | This RFC, |
       |                   |             | Status          | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_position       | 8           | UA Position     | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_bearing        | 9           | Bearing / Track | This RFC, |
       |                   |             | Direction       | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_speed          | 10          | Vertical &      | This RFC, |
       |                   |             | Horizontal      | Section   |
       |                   |             | Speeds          | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_height         | 11          | Height Above    | This RFC, |
       |                   |             | Ground or Take- | Section   |
       |                   |             | off             | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | accuracy          | 12          | Enumerations of | This RFC, |
       |                   |             | Accuracies      | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | operator_position | 13          | Operator        | This RFC, |
       |                   |             | Position        | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | timestamp         | 14          | UTC Timestamp   | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | compliance        | 15          | Compliance      | This RFC, |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 28]


  Internet-Draft                  det-tada                    October 2025


       |                   |             | Enumeration     | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | raa               | 23          | RAA             | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | hda               | 24          | HDA             | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | csr               | 25          | DER Encoded     | This RFC  |
       |                   |             | X.509 CSR       |           |
       +-------------------+-------------+-----------------+-----------+
       | uas               | 26          | UAS Datum Map   | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | utm               | 27          | UTM Operational | This RFC  |
       |                   |             | Intent & Source |           |
       +-------------------+-------------+-----------------+-----------+
       | spec              | 28          | CAA             | This RFC  |
       |                   |             | Specification   |           |
       |                   |             | Code            |           |
       +-------------------+-------------+-----------------+-----------+
       | canonical_cert    | 39          | DER Encoded     | This RFC  |
       |                   |             | X.509           |           |
       |                   |             | Certificate     |           |
       +-------------------+-------------+-----------------+-----------+
       | be_chain          | 30          | List of         | This RFC  |
       |                   |             | Broadcast       |           |
       |                   |             | Endorsements    |           |
       +-------------------+-------------+-----------------+-----------+
       | registrant        | 31          | Registrant      | This RFC  |
       |                   |             | Information     |           |
       +-------------------+-------------+-----------------+-----------+
       | hhit              | 32          | Hierarchial     | This RFC  |
       |                   |             | Host Identity   |           |
       |                   |             | Tag             |           |
       +-------------------+-------------+-----------------+-----------+
       | oracle_x509       | 33          | Oracle X.509    | This RFC  |
       |                   |             | Certificate     |           |
       +-------------------+-------------+-----------------+-----------+
       | uas_serial_number | 34          | ANSI/CTA 2063-A | This RFC  |
       |                   |             | UAS Serial      |           |
       |                   |             | Number          |           |
       +-------------------+-------------+-----------------+-----------+
       | caa_assigned_id   | 35          | CAA Assigned ID | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | pilot_license_id  | 36          | Pilot License   | This RFC  |
       |                   |             | Number          |           |
       +-------------------+-------------+-----------------+-----------+



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 29]


  Internet-Draft                  det-tada                    October 2025


                   Table 4: Pre-Allocated DRIP CBOR/JSON Keys

  6.  Security Considerations

     The considerations discussed in [RFC9153], [RFC9374], [RFC9434],
     [RFC9575] and [DET-DNS] apply.

     DIMEs use and provide various methods to protect data through:
     Attestation, Authentication, Authorization, Access Control,
     Attribution, Accounting, and Audit (AAA).  All data, handled under
     DRIP, MUST be protected by AAA, as per applicable regulation and
     policy (which, in some cases, for public data, may impose minimal
     requirements).  All private data MUST also be protected by strong
     encryption where permitted by applicable law etc.  These requirements
     apply to data at rest and in transit in all phases of the process,
     i.e. registration and query.

     Attestation may be mandated by CAAs for devices (such as UA).  Remote
     ATtestation ProcedureS (RATS) [RFC9334] is recommended for DRIP.  The
     specific attestation mechanisms in a given jurisdiction are out of
     scope for this document.

        Author Note: RGM, what else should go here?

  6.1.  Cryptographic Materials

     Best practices dictate that cryptographic materials that should only
     be available to selected parties SHOULD be generated by one or more
     of those parties and stored accessibly only on those parties devices.
     E.g. the asymmetric key-pair from which a DET will be derived SHOULD
     be generated by the entity identified by that DET and the
     corresponding private key should be stored only on that entity's
     device.  There may be scenarios where other parts of the UAS MAY
     generate the cryptographic materials and provision them as needed
     during an operation.  Any such system MUST ensure security of the
     cryptographic material is guaranteed.

  7.  Privacy & Transparency Considerations

     The considerations discussed in [RFC9153] and Section 10 of [RFC9434]
     apply.

        Author Note: do we copy/paste Section 10 of [RFC9434] and update
        here or is below sufficient?







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 30]


  Internet-Draft                  det-tada                    October 2025


  7.1.  DETs as Session ID and Authentication Key ID

     The properties of a DET allow it to be used as a Session ID and/or an
     Authentication Key ID.  There may be scenarios in which Session IDs
     are desired for privacy but Authentication is not; although this may
     reduce transparency and security, a DET MAY be used exclusively as a
     Session ID in such.  There are scenarios in which Authentication is
     desired but Session IDs are not (e.g. where a CAA does not allow
     Session IDs); a DET MAY be used exclusively as an Authentication Key
     ID in such.  In the scenario expected to be most common, both Session
     IDs and Authentication are desired; the same DET SHOULD be used as
     both the Session ID and Authentication Key ID in such.  Consequences
     and operational impact of using different DETs for the Session ID and
     Authentication Key ID of the same entity are unknown and not covered
     in this document.

  7.2.  Selective Encryption

        Author Note: renamed section and/or add more explicit disclaimer?

     Selective encryption may be allowed in some circumstances.  An HHIT
     may be used in a private lookup to access decryption key material or
     obtain decryption as a service.

     Selective encryption of UAS RID using DRIP is only allowed when the
     DET to be used as the Session ID is issued by an HDA associated with
     a USS and that DET is associated with the corresponding Operational
     Intent in UTM.  This enables the encryption of selected data elements
     in Broadcast RID to provide a layer of privacy for operators (e.g.
     their position) without compromising transparency to entities (e.g.
     public safety / law enforcement personnel) that need to know.

     Selective encryption typically requires network connectivity of the
     Observer to perform the private query to obtain the decryption
     service or key material.  CAAs should consider the expected Observer
     environment and prohibit encryption wherever and whenever Observers
     cannot reasonably be expected to have connectivity.  For example
     selective encryption, per CAA regulations, MAY be allowed in dense
     wireless IP connectivity areas (e.g. urban) but prohibited in poor
     wirelessly covered areas (e.g. rural).

     The issue of Observer network connectivity MAY be mitigated with the
     use of a shared decryption key used by multiple Session IDs under a
     given USS/HDA over a period of time, that is preloaded onto the
     Observer device before connectivity is lost.  For example Observers
     MAY query USS/HDAs for flight volumes in which they are interested to
     preload their decryption key(s) for the Operational Intents/Session
     IDs that day.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 31]


  Internet-Draft                  det-tada                    October 2025


  8.  References

  8.1.  Normative References

     [DET-DNS]  Wiethuechter, A. and J. Reid, "DRIP Entity Tags in the
                Domain Name System", Work in Progress, Internet-Draft,
                draft-ietf-drip-registries-33, 19 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                registries-33>.

     [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/rfc/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/rfc/rfc8174>.

     [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/rfc/rfc9153>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/rfc/rfc9374>.

     [RFC9434]  Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
                and A. Gurtov, "Drone Remote Identification Protocol
                (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
                2023, <https://www.rfc-editor.org/rfc/rfc9434>.

     [RFC9575]  Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
                Entity Tag (DET) Authentication Formats and Protocols for
                Broadcast Remote Identification (RID)", RFC 9575,
                DOI 10.17487/RFC9575, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9575>.

     [STD95]    Internet Standard 95,
                <https://www.rfc-editor.org/info/std95>.
                At the time of writing, this STD comprises the following:







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 32]


  Internet-Draft                  det-tada                    October 2025


                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>.

                Hollenbeck, S. and N. Kong, "Security Services for the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 7481, DOI 10.17487/RFC7481, March 2015,
                <https://www.rfc-editor.org/info/rfc7481>.

                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>.

                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>.

                Blanchet, M., "Finding the Authoritative Registration Data
                Access Protocol (RDAP) Service", STD 95, RFC 9224,
                DOI 10.17487/RFC9224, March 2022,
                <https://www.rfc-editor.org/info/rfc9224>.

  8.2.  Informative References

     [F3411]    ASTM International, "Standard Specification for Remote ID
                and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
                2022, <https://www.astm.org/f3411-22a.html>.

     [F3548]    ASTM International, "Standard Specification for UAS
                Traffic Management (UTM) UAS Service Supplier (USS)
                Interoperability", ASTM F3548-21, DOI 10.1520/F3548-21,
                July 2025, <https://www.astm.org/f3548-21.html>.

     [F3586]    ASTM International, "Standard Practice for Remote ID Means
                of Compliance to Federal Aviation Administration
                Regulation 14 CFR Part 89", ASTM F3586-22,
                DOI 10.1520/F3586-22, July 2022,
                <https://www.astm.org/f3411-22a.html>.

     [ICAO-ACCP]
                International Civil Aviation Organization, "ICAO Aviation
                Common Certificate Policy", July 2025.






  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 33]


  Internet-Draft                  det-tada                    October 2025


     [ICAO-NUMBERS]
                International Civil Aviation Organization, "ICAO Remote ID
                Number Registry", July 2025,
                <https://www.icao.int/airnavigation/IATF/Pages/ASTM-
                Remote-ID.aspx>.

     [MEDIA-TYPES]
                IANA, "Media Types", July 2025,
                <https://www.iana.org/assignments/media-types/>.

     [RDAP-EXT] IANA, "RDAP Extensions", July 2025,
                <https://www.iana.org/assignments/rdap-extensions/>.

     [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
                Protect Firmware Packages", RFC 4108,
                DOI 10.17487/RFC4108, August 2005,
                <https://www.rfc-editor.org/rfc/rfc4108>.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246,
                DOI 10.17487/RFC5246, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5246>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
                Address Text Representation", RFC 5952,
                DOI 10.17487/RFC5952, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5952>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
                Digest Access Authentication", RFC 7616,
                DOI 10.17487/RFC7616, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7616>.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 34]


  Internet-Draft                  det-tada                    October 2025


     [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
                RFC 7617, DOI 10.17487/RFC7617, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7617>.

     [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/rfc/rfc8126>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [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/rfc/rfc8610>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9063]  Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
                Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
                <https://www.rfc-editor.org/rfc/rfc9063>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9560]  Hollenbeck, S., "Federated Authentication for the
                Registration Data Access Protocol (RDAP) Using OpenID
                Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
                <https://www.rfc-editor.org/rfc/rfc9560>.

     [STD90]    Internet Standard 90,
                <https://www.rfc-editor.org/info/std90>.
                At the time of writing, this STD comprises the following:

                Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

     [STD94]    Internet Standard 94,
                <https://www.rfc-editor.org/info/std94>.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 35]


  Internet-Draft                  det-tada                    October 2025


                At the time of writing, this STD comprises the following:

                Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/info/rfc8949>.

     [WELL-KNOWN]
                IANA, "Well-Known URIs", July 2025,
                <https://www.iana.org/assignments/well-known-uris/>.

     [_802.1AR] IEEE, "IEEE Standard for Local and Metropolitan Area
                Networks - Secure Device Identity",
                DOI 10.1109/ieeestd.2018.8423794, July 2025,
                <https://doi.org/10.1109/ieeestd.2018.8423794>.

  Appendix A.  DRIP CDDL Prelude

     This appendix is normative.

     ; DRIP Type Definitions
     ; (follow STD94 Section 6 for CBOR/JSON conversion)
     metadata = (
       ? uas: uas-datum,
       ? utm: [
         operational_intent: uuid,
         uss_uri: uri
       ],
       ? raa: {
         ? spec: tstr,
         + &(tstr, int): any
       },
       ? hda: {
         ? spec: tstr,
         + &(tstr, int): any
       }
       * &(tstr, int): any
     )
     x509 = bstr ; DER encoded X.509 object (CSR or Certificate)
     endorsement = bstr .size 136
     hash = bstr .size 8 ; generated with cSHAKE
     auth-data = bstr .size 1..362
     uas-id = bstr .size 20
     utc = tdate / time

     ; DRIP Keys (JSON key = CBOR label)
     ; private_use = -2^64 .. -25
     ; astm = -24 .. 23



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 36]


  Internet-Draft                  det-tada                    October 2025


     uas_type = 0
     uas_ids = 1
     auth = 2
     self_id = 3
     area = 4
     classification = 5
     operator_id = 6
     ua_status = 7
     ua_position = 8
     ua_bearing = 9
     ua_speed = 10
     ua_height = 11
     accuracy = 12
     operator_position = 13
     timestamp = 14
     compliance = 15
     raa = 23
     hda = 24
     csr = 25
     uas = 26
     utm = 27
     spec = 28
     canonical_cert = 29
     be_chain = 30
     registrant = 31 ; jcard or pointer (i.e. hhit of operator)?
     hhit = 32
     oracle_x509 = 33
     uas_serial_number = 34
     caa_assigned_id = 35
     pilot_license_id = 36

     ; External Tags
     uuid = #6.37
     ip6 = #6.54
     position = #6.103([
             latitude: number,
             longitude: number,
             altitude: number
     ])

  Appendix B.  HID Abbreviation

     The DET MAY be abbreviated.  This is useful for display applications
     with limited screen real-estate as the display of the entire 128-bit
     (32 characters in hexadecimal, even without recommended punctuation
     or spacing) IPv6 address can be costly.  Abbreviations SHOULD follow
     the following format rules.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 37]


  Internet-Draft                  det-tada                    October 2025


     Hierarchy Level:  Each hierarchy level (RAA/HDA) is represented by a
        maximum of six alphanumeric characters.  This abbreviation SHOULD
        NOT be a single character in length, for obvious reasons of not
        being very useful.  The decimal representation does fit into the 4
        character restriction but is NOT RECOMMENDED.  The RECOMMENDED
        abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
        code for nations.  This abbreviation MAY be found in DNS under a
        HHIT RRType of the entity or its parents.  If there is no
        abbreviation hint display devices SHOULD use a fixed size four
        character hexadecimal representation of the value.  It is
        RECOMMENDED that display applications specify a default RAA value,
        and only display the RAA abbreviation explicitly when it does not
        match the default.

     Entity Hash:  The entity is represented by a fixed size four
        character hexadecimal string using the last four characters of the
        DET.  If a collision (within the same HID space) on display
        occurs, the four characters SHOULD shift to the left by one
        hexadecimal character until the collision is resolved.  This
        window MUST stay within the last sixteen hexadecimal characters of
        the DET.  The : character found in an IPv6 address string is
        ignored.

        Review(SWC): Do we need to insert a flag character such as "*" to
        indicate when a hash has been shifted?  If the abbreviation is
        used only to avoid conflicts, no; but if anyone actually knows
        some DETs in their operation, if they get shifted, they probably
        won't recognize them.

     Delimiter:  Each section is delimited by a single character.  This
        can be any whitespace character (except newline and tab) or any
        non-alphanumeric character (period, comma, semicolon, etc.).  It
        is RECOMMENDED that the delimiter is consistent between
        components.  The RECOMMENDED delimiter is the colon (:) character.

     For example a DET with the values of RAA 16383 and HDA 1 without any
     abbreviation hint from DNS is represented by the string 3FFF 0001
     xxxx with xxxx representing a entity hash.  If an abbreviation for
     the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
     the DET can be represented with the string of DRIP01 TEST xxxx.

     For an example of the entity hash, let's assume there are two DETs
     with the following hashes in the same HID: 0000:1111:2222:3333 and
     0000:2222:1111:3333.  At first both DETs are represented with the
     same abbreviation: RAA HDA 3333.  One of these DETs is selected by
     the display application to shift the display hash one character to
     avoid the collision resulting in the following two abbreviations: RAA
     HDA 3333 and RAA HDA 1333.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 38]


  Internet-Draft                  det-tada                    October 2025


  Appendix C.  Compliance Testing

     It is the responsibility of each parent node in the tree that a child
     node pass functional interoperability testing prior to issuing a
     certificate for the child node.

        Author: This section is a work in progress.

     All interfaces MUST be tested on valid and invalid data (such as
     being malformed).  When policy is required on an interface all
     essential permutations of the policy MUST be tested and all possible
     permutations SHOULD be tested.  The policy engine MUST be invoked to
     validate proper decisions (including PERMIT and DENY or their
     equivalents) and actions are being made.  All data returned from an
     interface MUST be tested to check that it conforms with
     specifications.

     There is a range in the RAA space allocated for experimentation and
     testing purposes.  Sub-ranges can be delegated to parties, for a
     limited period of time, at the behest of the RAA Designated Expert,
     to test DIME interoperability (e.g. HDA to RAA, and RAA to RAA
     interactions) in any of the below subsections.  The IANA
     Considerations section of [DET-DNS] contains more information on how
     these delegations are to be handled.

     Appendix C.4 provides a set of forms to be filled out and submitted
     as part of a CAA compliance process for using DRIP.

     +-----+           +-----+
     |     |           |     |
     |     o----(1)--->o     |
     |  X  |           |  Y  |
     |     o<---(2)----o     |
     |     |           |     |
     +-----+           +-----+

                    Figure 9: System Interface Test Diagram

  C.1.  Registration Interface

     X, Y pairs: (registrant, HDA), (HDA, RAA)

     1: Ensure that endpoints on Y can be accessed according to Y's policy
     by X.  Ensure that the endpoints conform to the normative
     requirements of Test that Y interface properly handles valid and
     malformed data.  Test that Y securely generates proper artifacts and
     stores them.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 39]


  Internet-Draft                  det-tada                    October 2025


     2: Ensure that the interactions for (1) properly returns data to X
     from Y.  This data MUST include the Broadcast Endorsements, X.509s
     and any other data elements required.

  C.2.  Public Query Interface

     X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that Y has a properly configured and publicly accessible
     Authoritative Name Server for its delegated ip6.arpa domain.

     2: Ensure that Y returns the valid RRTypes defined in [DET-DNS] to X
     based on an ip6.arpa query via standard DNS methods (i.e. using UDP
     on port 53).  Ensure that the HHIT RRType contains the correct
     Certificate with an URI.

  C.3.  Private Query Interface

     X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that the provide URI from the public query interface points
     to a valid URI.  Ensure that the endpoint on Y has proper AAA
     mechanisms as defined in this document and enforces the proper policy
     options.

     2: Ensure that the Y endpoint securely returns the data expected
     according to policy (matrix of authorized, valid request,
     unauthorized and invalid request) to X.

  C.4.  Compliance Submission Forms

     Author Note: talk with AS on this section

  Appendix D.  DRIP Key Infrastructure X.509 (DKIX)

     This appendix is normative.

     The following sections define profiles and any specific field content
     for X.509 certificates that serve as a "shadow" of Endorsements that
     make up the DRIP Key Infrastructure (DKI).  It is recommended that
     DKIX-Full (Appendix D.3) be deployed, as its CA certificates contain
     ICAO policy OIDs the reflect on the whole DKIX deployment.







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 40]


  Internet-Draft                  det-tada                    October 2025


     A DKIX compliant Certificate Authority (CA) MUST implement generation
     of the DKI Endorsements.  It SHOULD also generate both DKIX profiles
     (Appendix D.2 and Appendix D.3).  In this section Endorsing Server
     and CA are interchangeable.

        Author Note: At this point in defining the shadow PKIs,
        alternatives to a strict hierarchy is still an open work item.

  D.1.  Signing Request

     The Certificate Signing Request (CSR) is a mandatory for all DET
     registrations.  Depending on the entity being registered, there is
     specific content rules.

     Certificate Request:
         Data:
             Version: 1 (0x0)
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             Attributes:
             Requested Extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
         Signature Algorithm: ED25519

     Subject:  As defined in Section 4.1.2.6 of [RFC5280].  This field is
        filled in based on the type of entity being registered.  When the
        attribute type is set to SERIAL_NUMBER, it MUST contain the ANSI/
        CTA 2063-A UAS Serial Number encoded as a string.  The value of
        this field for other entity types are subject to policy and are
        out of scope for this document.

     Subject Alternative Name:  When the registrant knows which HID and/or
        Suite ID they want the CSR SHOULD contain the Subject Alternate
        Name extension as defined in Section 4.2.1.6 of [RFC5280] using
        ipAddress containing the fully formed DET and MUST mark the
        extension as critical.  This DIME MUST check to ensure that the
        DET located in the extension is properly generated with the
        included public key of this CSR.  If the registrant does not know
        or care the value of their HID and/or Suite ID, the Extensions
        field MUST NOT appear and the DIME will use its HID for DET
        generation using the public key provided by this CSR.

     The use of other Extension fields are out of scope for this document.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 41]


  Internet-Draft                  det-tada                    October 2025


  D.2.  Lite Profile

     DKIX-Lite is designed to fully mirror the DKI in the smallest
     reasonable X.509 certificates (e.g. 240 bytes for DER), but still
     adhere to [RFC5280] MUST field usage.  The profile can be found in
     Figure 10 and a field matrix found in Table 5.

     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
             Signature Algorithm: ED25519
             Issuer: CN =
             Validity
                 Not Before:
                 Not After :
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             X509v3 extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
         Signature Algorithm: ED25519
         Signature Value:

                          Figure 10: DKIX-Lite Profile























  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 42]


  Internet-Draft                  det-tada                    October 2025


     +================+===============+=========+=============+==========+
     | Field          | Authorization | Issuing | Operational | Comments |
     +================+===============+=========+=============+==========+
     | Serial         | MUST          | MUST    | MUST        | Appendix |
     | Number         |               |         |             | D.4.1.1  |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MUST          | MUST    | MUST NOT    | Appendix |
     |                |               |         |             | D.4.2    |
     +----------------+---------------+---------+-------------+----------+
     | Issuer         | MUST          | MUST    | MUST        | Appendix |
     |                |               |         |             | D.4.3    |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MUST          | MUST    | MUST        | Appendix |
     | Alternative    |               |         |             | D.4.4    |
     | Name (SAN)     |               |         |             |          |
     | IP6            |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MAY           | MAY     | MAY         | Appendix |
     | Alternative    |               |         |             | D.4.5    |
     | Name (SAN)     |               |         |             |          |
     | URI            |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Basic          | MUST          | MUST    | MUST NOT    | CA=True, |
     | Constraints    |               |         |             | flagged  |
     |                |               |         |             | as       |
     |                |               |         |             | Critical |
     +----------------+---------------+---------+-------------+----------+
     | Subject Key    | MUST NOT      | MUST    | MUST NOT    | -        |
     | Identifier     |               | NOT     |             |          |
     | (SKI)          |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Authority      | MUST NOT      | MUST    | MUST NOT    | -        |
     | Key            |               | NOT     |             |          |
     | Identifier     |               |         |             |          |
     | (AKI)          |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Key Usage      | MAY           | MAY     | MAY         | -        |
     +----------------+---------------+---------+-------------+----------+
     | CA Policy      | MAY           | MAY     | MAY         | Appendix |
     | OIDs           |               |         |             | D.4.8    |
     +----------------+---------------+---------+-------------+----------+

                        Table 5: DKIX-Lite Field Matrix








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 43]


  Internet-Draft                  det-tada                    October 2025


  D.3.  Full Profile

     The X.509 certificates are minimalistic (less than 400 bytes for
     DER).  Any DRIP specific OIDs should come from the ICAO arc (see
     Appendix D.4.8).  The profile can be found in Figure 11 and a field
     matrix found in Table 6.

     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
             Signature Algorithm: ED25519
             Issuer: CN =
             Validity
                 Not Before:
                 Not After :
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             X509v3 extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
                     URI:
                 X509v3 Subject Key Identifier:
                 X509v3 Authority Key Identifier:
                 X509v3 Basic Constraints: critical
                 X509v3 Key Usage: critical
         Signature Algorithm: ED25519
         Signature Value:

                          Figure 11: DKIX-Full Profile


















  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 44]


  Internet-Draft                  det-tada                    October 2025


     +=============+===============+=============+=============+========+
     | Field       | Authorization | Issuing     | Operational |Comments|
     +=============+===============+=============+=============+========+
     | Serial      | MUST          | MUST        | MUST        |Appendix|
     | Number      |               |             |             |D.4.1.2 |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MUST          | MUST        | MUST NOT    |Appendix|
     |             |               |             |             |D.4.2   |
     +-------------+---------------+-------------+-------------+--------+
     | Issuer      | MUST          | MUST        | MUST        |Appendix|
     |             |               |             |             |D.4.3   |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MUST          | MUST        | MUST        |Appendix|
     | Alternative |               |             |             |D.4.4   |
     | Name (SAN)  |               |             |             |        |
     | IP6         |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MAY           | MAY         | MAY         |Appendix|
     | Alternative |               |             |             |D.4.5   |
     | Name (SAN)  |               |             |             |        |
     | URI         |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Basic       | MUST          | MUST        | MUST NOT    |CA=True,|
     | Constraints |               |             |             |flagged |
     |             |               |             |             |as      |
     |             |               |             |             |Critical|
     +-------------+---------------+-------------+-------------+--------+
     | Subject Key | MUST          | MUST        | MUST NOT    |Appendix|
     | Identifier  |               |             |             |D.4.6   |
     | (SKI)       |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Authority   | MUST          | MUST        | MUST        |Appendix|
     | Key         |               |             |             |D.4.7   |
     | Identifier  |               |             |             |        |
     | (AKI)       |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Key Usage   | SHOULD        | SHOULD      | SHOULD      |-       |
     +-------------+---------------+-------------+-------------+--------+
     | CA Policy   | RECOMMENDED   | RECOMMENDED | RECOMMENDED |Appendix|
     | OIDs        |               |             |             |D.4.8   |
     +-------------+---------------+-------------+-------------+--------+

                       Table 6: DKIX-Full Field Matrix








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 45]


  Internet-Draft                  det-tada                    October 2025


  D.4.  Certificate Fields

     The following sections contain clarifications on the usage of fields
     in the DKIX when they deviate from "standard" X.509 [RFC5280]
     practice or have specific functions in the context of DRIP.

  D.4.1.  Serial Number

  D.4.1.1.  Lite

     The Serial Number is a MUST field, but it has no usage in this DRIP-
     Lite.  It is 1-byte in size and thus duplicates are guaranteed.  To
     drop this field could make many X.509 parsing libraries fail.

     However, CA certificate's Serial Number MAY be the common 20 bytes.
     This is to avoid possible issues with general software expecting this
     size Serial Numbers for CAs.

     If Serial Numbers are incrementally assigned, 31 bits are sufficient
     for an Issuing CA with 2B DETs active.  A CA should determine its
     best-used Serial Number field size to limit the impact of this field
     on the certificate size.

  D.4.1.2.  Full

     The certificates will contain a 20-byte randomly generated Serial
     Number, compliant with CABForum recommendations.  Serial Numbers are
     included for CRL functionality.

  D.4.2.  Subject

     The Subject field is only used in Authorization and Issuing
     Certificates.  For Operational Certificates, the Subject is Empty and
     the DET will be in Subject Alternative Name (SAN, Appendix D.4.4).
     In the SAN, the DET can be properly encoded as an IPv6 address.

     The format defined in Figure 12 MUST be used.  The CA Subject Name
     serves a dual purpose: foremost, to place the CA within the DKI tree,
     but secondly for outside of DRIP usage to tag that this CA's function
     is to serve DRIP Entities.

     DRIP-{APEX|RAA|HDA}-{A|I}[-RAA#][-HDA#]

                          Figure 12: CA Subject Format

     As examples; an Authorization DET for RAA 16376 would be: DRIP-RAA-
     A-16376 and an Issuing DET for HDA 16376 under the same RAA would be:
     DRIP-HDA-I-16376-16376.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 46]


  Internet-Draft                  det-tada                    October 2025


  D.4.3.  Issuer

     The Issuer MUST be the higher level's DET.

     The Issuer for the Apex Authorization certificate MUST be its DET
     (indicating self-signed).  If the RAA Authorization certificate is
     self-signed (i.e., no Apex), its Issuer is its DET.

     The Issuer content of its DET assists in finding this specific Issuer
     in the DRIP ip6.arpa.  DNS tree and any additional information.

  D.4.4.  Subject Alternative Name IP6

     Subject Alternative Name is only used in Operational certificates.
     It is used to provide the DET as an IP address with an Empty Subject
     (SAN MUST be flagged as Critical).

     The Subject Alternative Name is also used in Manufacturer DET
     certificates.  These may contain the hardwareModuleName as described
     in [_802.1AR] that references [RFC4108].

     Per [RFC5280] and [_802.1AR], Manufacturer DET certificates with
     hardwareModuleName MUST have the notAfter date as 99991231235959Z.

  D.4.5.  Subject Alternative Name URI

     This field contains a pointer in the form of a URI where additional
     information on the CA and certificates under its control can be
     found.  For example, an authorized authority may access end-entity
     PII like an Operator phone number through this URI link using the
     method specified in Section 4.3.2.

     Authorization certificates MAY have a SAN URI and MUST when it is
     self-signed.  Issuing certificates SHOULD have a SAN URI.
     Operational certificates MAY have a SAN URI.

     The RECOMMENDED configuration with respect to Issuing and Operational
     certificates for a CA is to place the SAN URI in the Issuing
     certificate and exclude them in Operational certificates.  When
     multiple providers are used by the CA to handle additional
     information there SHOULD be a unique Issuing certificate with SAN URI
     for each provider, and Operational certificates MUST NOT contain a
     SAN URI.  Otherwise a CA with multiple providers MUST NOT have a SAN
     URI in the Issuing certificate and MUST set the SAN URI to the
     specific provider for each Operational certificate.

     The contents of the SAN URI are the base URI of the host to query for
     additional information of a DET.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 47]


  Internet-Draft                  det-tada                    October 2025


        Author Note: do we want to create a ./well-known/hhit-query?  Then
        base URIs in the certificates can become something like:
        https://hda.example.com, then the clients append /.well-known/
        hhit-query/<ip6> (<ip6> here is a specific DET).  Path
        preservation can then be used by the server to replace /.well-
        known/hhit-query/ with whatever is required on the path for the
        specific server such as /my/bloated/path/to/rdap/ip/.

  D.4.6.  Subject Key Identifier

     The Subject Key Identifier MUST be the DET.  This is a major
     deviation from "standard" X.509 certificates that hash (normally with
     SHA2) the Public Key to fill the Subject Key Identifier.

     The Subject Key Identifier is NOT included in Operational
     certificates.  If needed by some application, it is identical with
     SAN.

  D.4.7.  Authority Key Identifier

     The Authority Key Identifier MUST be the higher level's Subject Key
     Identifier (i.e. DET).  This partially follows standard practice to
     chain up the Authority Key Identifier from the Subject Key
     Identifier, except for how the Subject Key Identifiers are populated.

     The Authority Key Identifier for the Apex Authorization (or self-
     signed RAA Authorization) certificate MUST be the Subject Key
     Identifier (indicating self-signed).

  D.4.8.  CA Policy OIDs

     It is recommended that a CA have policy OIDs defining rules for EEs
     within its domain.  The OIDs used here will tend to be within ICAO's
     arc of 1.3.27.16.

     If the CA certificate has policy OIDs, it MUST include an ICAO LOA
     OID (arc of 1.3.27.16.1.1.0) defining "the confidence in the security
     measures that protect the private key and manage the certificate
     lifecycle".

     +=====+======================+======================================+
     | OID | Description          | Applicability                        |
     +=====+======================+======================================+
     | 1   | Low                  | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | low.  Subscriber Private Keys shall  |
     |     |                      | be stored in software at this        |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 48]


  Internet-Draft                  det-tada                    October 2025


     |     |                      | Identity Assurance Level (IAL).      |
     +-----+----------------------+--------------------------------------+
     | 2   | LowDevice            | This policy is identical to that     |
     |     |                      | defined for the Low Assurance        |
     |     |                      | policy (above) with the exception    |
     |     |                      | of identity proofing, re-key, and    |
     |     |                      | Activation Data.                     |
     +-----+----------------------+--------------------------------------+
     | 3   | Low-TSP Mediated     | This policy is identical to that     |
     |     | Signature            | defined for the Low Assurance        |
     |     |                      | policy (above) with the exception    |
     |     |                      | that the Private key is not in the   |
     |     |                      | possession of the user, but rather   |
     |     |                      | by a Trust Service Provider.         |
     +-----+----------------------+--------------------------------------+
     | 4   | Medium               | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | moderate.  This may include          |
     |     |                      | transactions having substantial      |
     |     |                      | monetary value or Risk of fraud or   |
     |     |                      | involving access to private          |
     |     |                      | information where the likelihood of  |
     |     |                      | malicious access is substantial.     |
     |     |                      | Subscriber Private Keys shall be     |
     |     |                      | stored in software at this IAL.      |
     +-----+----------------------+--------------------------------------+
     | 5   | MediumDevice         | This policy is identical to that     |
     |     |                      | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | of identity proofing, re-key, and    |
     |     |                      | Activation Data.                     |
     +-----+----------------------+--------------------------------------+
     | 6   | Medium-TSP Mediated  | This policy is identical to that     |
     |     | Signature            | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | that the Private key is not in the   |
     |     |                      | possession of the user, but rather   |
     |     |                      | by a Trust Service Provider.         |
     +-----+----------------------+--------------------------------------+
     | 7   | MediumHardware       | This policy is identical to that     |
     |     |                      | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | of Subscriber Cryptographic Module   |
     |     |                      | requirements described in            |
     |     |                      | [ICAO-ACCP].                         |
     +-----+----------------------+--------------------------------------+
     | 8   | MediumDeviceHardware | This policy is identical to that     |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 49]


  Internet-Draft                  det-tada                    October 2025


     |     |                      | defined for the Medium Hardware      |
     |     |                      | Assurance policy (above) with the    |
     |     |                      | exception of identity proofing, re-  |
     |     |                      | key, and Activation Data.            |
     +-----+----------------------+--------------------------------------+
     | 9   | High                 | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | high.  Certificates issued at the    |
     |     |                      | High-CardAuth IAL shall only be      |
     |     |                      | issued for Card Authentication, as   |
     |     |                      | defined by NIST SP 800-73 or         |
     |     |                      | equivalent standard.  Further, this  |
     |     |                      | policy is identical to that defined  |
     |     |                      | for the identical to the             |
     |     |                      | MediumHardware IAL except where      |
     |     |                      | specifically noted in [ICAO-ACCP].   |
     +-----+----------------------+--------------------------------------+
     | 10  | High-CardAuth        | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | high.  Certificates issued at the    |
     |     |                      | High-cardAuth IAL shall only be      |
     |     |                      | issued for Card Authentication, as   |
     |     |                      | defined by NIST SP 800-73 or         |
     |     |                      | equivalent standard.                 |
     +-----+----------------------+--------------------------------------+
     | 11  | High-ContentSigning  | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | High.  This may include              |
     |     |                      | transactions having substantial      |
     |     |                      | monetary value or Risk of fraud or   |
     |     |                      | involving access to private          |
     |     |                      | information where the likelihood of  |
     |     |                      | malicious access is substantial.     |
     |     |                      | Certificates issued at the High IAL  |
     |     |                      | shall only be issued to human        |
     |     |                      | Subscribers.Certificates issued at   |
     |     |                      | the High-contentSigning IAL shall    |
     |     |                      | only be issued to the CMS for        |
     |     |                      | signing the HIGH card security       |
     |     |                      | objects (e.g. Certificates, CRLs,    |
     |     |                      | OCSP responses).  Further, this      |
     |     |                      | policy is identical to that defined  |
     |     |                      | for the identical to the             |
     |     |                      | MediumHardware IAL except where      |
     |     |                      | specifically noted in [ICAO-ACCP].   |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 50]


  Internet-Draft                  det-tada                    October 2025


     +-----+----------------------+--------------------------------------+

            Table 7: ICAO LOA OID Assignments under 1.3.27.16.1.1.0

     In this document, the term “Device” is defined as a Non-Person
     Entity, i.e., an entity with a digital identity that acts in
     cyberspace but is not a human actor.  This can include Organizations,
     hardware devices (e.g. a UA), software applications, and information
     artifacts.

     Operational Certificates issued to Devices shall assert policies
     mapped to LowDevice, MediumDevice, MediumDeviceHardware, or High
     Content Signing policies.  All other policies defined here should be
     reserved for human Subscribers when used in Operational Certificates.
     Thus it is recommended that Issuing CAs/HDAs should be segregated by
     device and human subscribers so policy can be stated at the CA level
     rather in individual certificates.

  Authors' Addresses

     Adam Wiethuechter
     AX Enterprize, LLC
     4947 Commercial Drive
     Yorkville, NY 13495
     United States of America
     Email: adam.wiethuechter@axenterprize.com


     Robert Moskowitz
     HTT Consulting
     Oak Park, MI 48237
     United States of America
     Email: rgm@labs.htt-consult.com


















  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 51]


name: draft-ietf-rats-evidence-trans
rev: 02
title: Evidence Transformations
time: 2025-10-17T17:07:00Z
group_uri: /api/v1/group/group/2231/
expires: 2026-04-20T17:07:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.334267+00:00
source: ietf
source_id: 145452
source_url: https://datatracker.ietf.org/doc/draft-ietf-rats-evidence-trans/
doc_status: active
abstract:
  Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester to decide if continued
     interaction is warrented.  Evidence structures can vary making
     appraisals challenging for Verifiers.  Verifiers need to understand
     Evidence encoding formats and some of the Evidence semantics to
     appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods
     for DiceTcbInfo, concise evidence, and SPDM measurements block
     structures.  These Evidence structures are converted to the CoRIM
     internal representation and follow CoRIM defined appraisal
     procedures.

full_text:
  Remote ATtestation ProcedureS                                 F. D'Amato
  Internet-Draft                                                       AMD
  Intended status: Standards Track                               A. Draper
  Expires: 20 April 2026                                          N. Smith
                                                               Independent
                                                           17 October 2025


                          Evidence Transformations
                     draft-ietf-rats-evidence-trans-02

  Abstract

     Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester to decide if continued
     interaction is warrented.  Evidence structures can vary making
     appraisals challenging for Verifiers.  Verifiers need to understand
     Evidence encoding formats and some of the Evidence semantics to
     appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods
     for DiceTcbInfo, concise evidence, and SPDM measurements block
     structures.  These Evidence structures are converted to the CoRIM
     internal representation and follow CoRIM defined appraisal
     procedures.

  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 20 April 2026.

  Copyright Notice

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




  D'Amato, et al.           Expires 20 April 2026                 [Page 1]


  Internet-Draft                   EvTrans                    October 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language and Terminology . . . . . . . . . . . .   3
     3.  Verifier Reconciliation . . . . . . . . . . . . . . . . . . .   3
     4.  Transforming DICE Certificate Extension Evidence  . . . . . .   4
       4.1.  DiceUeid Transformation . . . . . . . . . . . . . . . . .   4
       4.2.  DiceTcbInfo Transformation  . . . . . . . . . . . . . . .   4
       4.3.  DiceConceptualMessageWrapper Transformation . . . . . . .   8
       4.4.  Authority field in DICE/SPDM ECTs . . . . . . . . . . . .   8
     5.  Transforming TCG Concise Evidence . . . . . . . . . . . . . .   8
       5.1.  Transforming the ce.evidence-triples  . . . . . . . . . .   9
       5.2.  Transforming the ce.identity-triples  . . . . . . . . . .  10
       5.3.  Transforming the ce.attest-key-triples  . . . . . . . . .  11
     6.  DMTF SPDM Structure Definitons  . . . . . . . . . . . . . . .  12
     7.  Transforming SPDM Measurement Block Digest  . . . . . . . . .  14
     8.  Transforming SPDM Measurement Block Raw Value . . . . . . . .  14
     9.  Transforming SPDM RATS EAT CWT  . . . . . . . . . . . . . . .  15
     10. Transforming SPDM Evidence  . . . . . . . . . . . . . . . . .  15
     11. Implementation Status . . . . . . . . . . . . . . . . . . . .  16
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  16
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       14.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     Remote Attestation Procedures (RATS) [RFC9334] enable Relying Parties
     to assess the trustworthiness of a remote Attester to decide if
     continued interaction is warrented.  Evidence structures can vary
     making appraisals challenging for Verifiers.  Verifiers need to
     understand Evidence encoding formats and some of the Evidence
     semantics to appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods



  D'Amato, et al.           Expires 20 April 2026                 [Page 2]


  Internet-Draft                   EvTrans                    October 2025


     for DiceTcbInfo [DICE.Attest], concise evidence [TCG.CE], and SPDM
     measurements block [SPDM] structures.  These Evidence structures are
     converted to the CoRIM internal representation (Section 2.1
     [I-D.ietf-rats-corim]) and follow CoRIM defined appraisal procedures
     (Section 8 [I-D.ietf-rats-corim]).

  2.  Requirements Language and 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.

     This document uses terms and concepts defined by the RATS
     architecture.  For a complete glossary.  See Section 4 of [RFC9334].
     Addintional RATS architecture and terminology is found in
     [I-D.ietf-rats-endorsements].  RATS architecture terms and concepts
     are always referenced as proper nouns, i.e., with Capital Letters.
     Additional terminology from CoRIM [I-D.ietf-rats-corim],
     [DICE.CoRIM], CBOR [STD94], CDDL [RFC8610] and COSE [STD96] may also
     apply.

     In this document, Evidence structures are expressed in their
     respective "external representations".  There are many possible
     Evidence structures including those mentioned above.

     The CoRIM specification defines an "internal representation" for
     Evidence (Section 8.2.1.3 [I-D.ietf-rats-corim]).  This document
     defines mapping operations that convert from an external
     representation to an internal representation.  The conversion steps
     are also known as "transformation".

  3.  Verifier Reconciliation

     This document assumes the reader is familiar with Verifier
     reconciliation as described in Section 2 of [I-D.ietf-rats-corim].
     It describes how a Verifier should process the CoRIM to enable CoRIM
     authors to convey their intended meaning and how a Verifier
     reconciles its various inputs.  Evidence is one of its inputs.  The
     Verifier is expected to create an internal representation from an
     external representation.  By using an internal representation, the
     Verifier processes Evidence inputs such that they can be appraised
     consistently.

     This document defines format transformations for Evidence in DICE
     [DICE.Attest], SPDM [SPDM], and concise evidence [TCG.CE] formats
     that are transformed into a Verifier's internal representation.  This



  D'Amato, et al.           Expires 20 April 2026                 [Page 3]


  Internet-Draft                   EvTrans                    October 2025


     document uses the CoMID internal representation (Section 8.2.1 of
     [I-D.ietf-rats-corim]) as the transformation target.  Other internal
     representations are possible but out of scope for this document.

  4.  Transforming DICE Certificate Extension Evidence

     This section defines how Evidence from an X.509 certificate [RFC5280]
     containing a DICE certificate extension [DICE.Attest] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the DICE certificate Evidence extensions SHOULD
     implement this transformation.

  4.1.  DiceUeid Transformation

     This section defines the transformation method for the DiceUeid
     certificate extension.  This extension is identified by the following
     object identifier:

     *  tcg-dice-Ueid - "2.23.133.5.4.4"

     The DiceUeid extension does not create evidence directly.  The ueid
     OCTET STRING within this extension is used to populate the instance-
     id field within evidence created by other extensions.
     Section Section 4.2 describes extensions which use this value.

  4.2.  DiceTcbInfo Transformation

     This section defines transformation methods for DICE certificate
     extensions DiceTcbInfo, DiceMultiTcbInfo, and DiceMultiTcbInfoComp.

     These extensions are identified by the following object identifiers:

     *  tcg-dice-TcbInfo - "2.23.133.5.4.1"

     *  tcg-dice-MultiTcbInfo - "2.23.133.5.4.5"

     *  tcg-dice-MultiTcbInfoComp - "2.23.133.5.4.8"

     Each DiceTcbInfo entry in a MultiTcbInfo is converted to a CoRIM ECT
     (see Section 8.2.1 of [I-D.ietf-rats-corim]) using the transformation
     steps in this section.  Each DiceMultiTcbInfo entry is independent of
     the others such that each is transformed to a separate ECT entry.  A
     list of Evidence ECTs (i.e., ae = [ + ECT]) is constructed using
     CoRIM attestation evidence internal representation (see
     Section 8.2.1.1 of [I-D.ietf-rats-corim]).  Each DiceMultiTcbInfoComp
     entry is converted to a DiceMultiTcbInfo entry then processed as a
     DiceMultiTcbInfo.



  D'Amato, et al.           Expires 20 April 2026                 [Page 4]


  Internet-Draft                   EvTrans                    October 2025


     For each DiceTcbInfo (DTI) entry in a DiceMultiTcbInfo allocate an
     ECT structure.

     Step 1.  An ae entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The DiceTcbInfo (DTI) entry populates the ae ECT.

     i  The DTI entry populates the ae ECT environment-map

        *copy*(DTI.type, ECT.environment.environment-map.class-
           map.class-id).  The binary representation of DTI.type MUST be
           equivalent to the binary representation of class-id without the
           CBOR tag.

        *copy*(DTI.vendor, ECT.environment.environment-map.class-
           map.vendor).

        *copy*(DTI.model, ECT.environment.environment-map.class-
           map.model).

        *copy*(DTI.layer, ECT.environment.environment-map.class-
           map.layer).

        *copy*(DTI.index, ECT.environment.environment-map.class-
           map.index).

     ii If a DiceUeid (UEID) extension is present, then this populates the
        instance-id field within the ECT environment-map.

        If DiceUeid extension is present: *copy*(UEID.ueid,
           ECT.environment-map.instance-id.tagged-ueid-type).  The CBOR
           tag #6.550 is prepended to the DiceUeid OCTET STRING then
           copied to ECT.environment-map.instance-id.

     iiiThe DTI entry populates the ae ECT elemenet-list.

        *copy*(DTI.version, ECT.element-list.element-map.measurement-
           values-map.version-map.version).

        *copy*(DTI.svn, ECT.element-list.element-map.measurement-
           values-map.svn).

        *copy*(DTI.vendorInfo, ECT.element-list.element-
           map.measurement-values-map.raw-value).





  D'Amato, et al.           Expires 20 April 2026                 [Page 5]


  Internet-Draft                   EvTrans                    October 2025


        Foreach FWID in FWIDLIST: *copy*(DTI.FWID.digest, ECT.element-
           list.element-map.measurement-values-map.digests.digest.val).

        Foreach FWID in FWIDLIST: *copy*(DTI.FWID.hashAlg, ECT.element-
           list.element-map.measurement-values-map.digests.digest.alg).

        Foreach INTEGRITYREGISTER in IRLIST:
           *copy*(DTI.INTEGRITYREGISTER.registerNum, ECT.element-
           list.element-map.measurement-values-map.integrity-
           registers.integrity-register-id-type-choice).

        Foreach FWID in INTEGRITYREGISTER.FWIDLIST:
           *copy*(DTI.FWID.digest, ECT.element-list.element-
           map.measurement-values-map.integrity-registers.digest-
           type.val).

        Foreach FWID in INTEGRITYREGISTER.FWIDLIST:
           *copy*(DTI.FWID.alg, ECT.element-list.element-map.measurement-
           values-map.integrity-registers.digest-type.alg).

     iv The DTI entry populates the ae ECT elemenet-list.flags.  Foreach
        _f_ in DTI.OperationalFlags and each _m_ in
        DTI.OperationalFlagsMask:

        If _m_.notConfigured = 1 AND _f_.notConfigured = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-configured = FALSE).

        If _m_.notConfigured = 1 AND _f_.notConfigured = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-configured = TRUE).

        If _m_.notSecure = 1 AND _f_.notSecure = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-secure =
           FALSE).

        If _m_.notSecure = 1 AND _f_.notSecure = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-secure =
           TRUE).

        If _m_.recovery = 1 AND _f_.recovery = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-recovery =
           FALSE).

        If _m_.recovery = 1 AND _f_.recovery = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-recovery =
           TRUE).




  D'Amato, et al.           Expires 20 April 2026                 [Page 6]


  Internet-Draft                   EvTrans                    October 2025


        If _m_.debug = 1 AND _f_.debug = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-debug =
           FALSE).

        If _m_.debug = 1 AND _f_.debug = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-debug = TRUE).

        If _m_.notReplayProtected = 1 AND _f_.notReplayProtected = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-replay-protected = FALSE).

        If _m_.notReplayProtected = 1 AND _f_.notReplayProtected = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-replay-protected = TRUE).

        If _m_.notIntegrityProtected = 1 AND _f_.notIntegrityProtected
           = 1; *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-integrity-proteccted = FALSE).

        If _m_.notIntegrityProtected = 1 AND _f_.notIntegrityProtected
           = 0; *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-integrity-proteccted = TRUE).

        If _m_.notRuntimeMeasured = 1 AND _f_.notRuntimeMeasured = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-runtime-meas = FALSE).

        If _m_.notRuntimeMeasured = 1 AND _f_.notRuntimeMeasured = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-runtime-meas = TRUE).

        If _m_.notImmutable = 1 AND _f_.notImmutable = 1;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-immutable = FALSE).

        If _m_.notImmutable = 1 AND _f_.notImmutable = 0;
           *set*(ECT.element-list.element-map.measurement-values-
           map.flags.is-immutable = TRUE).

        If _m_.notTcb = 1 AND _f_.notTcb = 1; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-tcb = FALSE).

        If _m_.notTcb = 1 AND _f_.notTcb = 0; *set*(ECT.element-
           list.element-map.measurement-values-map.flags.is-tcb = TRUE).

     Step 4.  The ECT.authority field is set up based on the signer of the
              certificate containing DTI as described in Section 4.4.




  D'Amato, et al.           Expires 20 April 2026                 [Page 7]


  Internet-Draft                   EvTrans                    October 2025


     The completed ECT is added to the ae list.

  4.3.  DiceConceptualMessageWrapper Transformation

     This section defines the transformation method for the
     DiceConceptualMessageWrapper certificate extension.  This extension
     is identified by the following object identifier:

     *  tcg-dice-Ueid - "2.23.133.5.4.9"

     The DiceConceptualMessageWrapper entry OCTET STRING may contain a
     CBOR array, JSON array, or CBOR tagged value.  If the entry contains
     a CBOR tag value of #6.571 or #6.1668557429, or a Content ID of
     10571, or a Media Type of "application/ce+cbor", the contents are
     transformed according to Section 5.

  4.4.  Authority field in DICE/SPDM ECTs

     The ECT authority field is an array of $crypto-keys-type-choice
     values.

     When adding Evidence to the ACS, the Verifier SHALL add the public
     key representing the signer of that Evidence (for example the DICE
     certificate or SPDM MEASUREMENTS response) to the ECT authority
     field.  The Verifier SHALL add the authority of the signers of each
     certificate in the certificate path of the end-entity signing key to
     the ECT authority list.  Having each authority in a certificate path
     in the ECT authority field lets conditional endorsement conditions
     match multiple authorities or match an authority that is scoped more
     broadly than the immediate signer of the Evidence artifact.

     Each signer authority value MUST be represented using tagged-cose-
     key-type.

  5.  Transforming TCG Concise Evidence

     This section defines how Evidence from TCG [TCG.CE] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the TCG Concise Evidence format SHOULD implement
     this transformation.

     Concise evidence may be recognized by any of the following registered
     types:







  D'Amato, et al.           Expires 20 April 2026                 [Page 8]


  Internet-Draft                   EvTrans                    October 2025


         +==========+========+===============+=======================+
         | CBOR tag | C-F ID | TN Tag        | Media Type            |
         +==========+========+===============+=======================+
         | #6.571   | 10571  | #6.1668557429 | "application/ce+cbor" |
         +----------+--------+---------------+-----------------------+

                                    Table 1

     A Concise Evidence entry is converted to a CoRIM ECT (see
     Section 8.2.1 of [I-D.ietf-rats-corim]) using the transformation
     steps in this section.  A list of Evidence ECTs (i.e., ae = [ + ECT])
     is constructed using CoRIM attestation evidence internal
     representation (see Section 8.2.1.1 of [I-D.ietf-rats-corim]).  The
     Concise Evidence scheme uses CoRIM CDDL definitions to define several
     Evidence representations called _triples_. Cases where Concise
     Evidence CDDL is identical to CoRIM CDDL the transformation logic
     uses the structure names in common.

  5.1.  Transforming the ce.evidence-triples

     The ce.evidence-triples structure is a list of evidence-triple-
     record.  An evidence-triple-record consists of an environment-map and
     a list of measurement-map.  For each evidence-triple-record an ae ECT
     is constructed.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.evidence-triple-record.environment-map,
           ECT.environment.environment-map).

     i  For each ce in CE.[ + measurement-map]; and each ect in ECT.[ +
        element-list]:

        *copy*(ce.mkey, ect.element-map.element-id)

        *copy*(ce.mval, ect.element-map.element-claims`)










  D'Amato, et al.           Expires 20 April 2026                 [Page 9]


  Internet-Draft                   EvTrans                    October 2025


     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field as described in Section 4.4.  For
              example, a CE may be wrapped by an EAT token [RFC9711] or
              DICE certificate [DICE.Attest].  The signer identity MUST be
              expressed using $crypto-key-type-choice.  A profile or other
              arrangement is used to coordinate which $crypto-key-type-
              choice is used for both Evidence and Reference Values.

     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.

  5.2.  Transforming the ce.identity-triples

     The ce.identity-triples structure is a list of ev-identity-triple-
     record.  An ev-identity-triple-record consists of an environment-map
     and a list of $crypto-key-type-choice.  For each ev-identity-triple-
     record an ae ECT is constructed where the $crypto-key-type-choice
     values are copied as ECT Evidence measurement values.  The ECT
     internal representation accommodates keys as a type of measurement.
     In order for the $crypto-key-type-choice keys to be verified a CoRIM
     identity-triples claim MUST be asserted.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.ce-identity-triple-record.environment-map,
           ECT.environment.environment-map).

        *copy*(_null_, ECT.element-list.element-map.element-id).

     i  For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in
        ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-
        crypto-key ]:

        *copy*(cek, ect.key)

        *set*( &(identity-key: 1), ect.key-type)

     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field.  For example, a CE may be wrapped by an
              EAT token [RFC9711] or DICE certificate [DICE.Attest].  The
              signer identity MUST be expressed using $crypto-key-type-



  D'Amato, et al.           Expires 20 April 2026                [Page 10]


  Internet-Draft                   EvTrans                    October 2025


              choice.  A profile or other arrangement is used to
              coordinate which $crypto-key-type-choice is used for both
              Evidence and Reference Values.

     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.

  5.3.  Transforming the ce.attest-key-triples

     The ce.attest-key-triples structure is a list of ev-attest-key-
     triple-record.  An ev-attest-key-triple-record consists of an
     environment-map and a list of $crypto-key-type-choice.  For each ev-
     attest-key-triple-record an ae ECT is constructed where the $crypto-
     key-type-choice values are copied as ECT Evidence measurement values.
     The ECT internal representation accommodates keys as a type of
     measurement.  In order for the $crypto-key-type-choice keys to be
     verified a CoRIM attest-key-triples claim MUST be asserted.

     Step 1.  An ae ECT entry is allocated.

     Step 2.  The cmtype of the ECT is set to evidence.

     Step 3.  The Concise Evidence (CE) entry populates the ae ECT
              environment fields.

        *copy*(CE.ce-attest-key-triple-record.environment-map,
           ECT.environment.environment-map).

        *copy*(_null_, ECT.element-list.element-map.element-id).

     i  For each cek in CE.[ + $crypto-key-type-choice ]; and each ect in
        ECT.element-list.element-map.element-claims.intrep-keys.[ + typed-
        crypto-key ]:

        *copy*(cek, ect.key)

        *set*( &(attest-key: 0), ect.key-type)

     Step 4.  The signer of the envelope containing CE is copied to the
              ECT.authority field.  For example, a CE may be wrapped by an
              EAT token [RFC9711] or DICE certificate [DICE.Attest].  The
              signer identity MUST be expressed using $crypto-key-type-
              choice.  A profile or other arrangement is used to
              coordinate which $crypto-key-type-choice is used for both
              Evidence and Reference Values.




  D'Amato, et al.           Expires 20 April 2026                [Page 11]


  Internet-Draft                   EvTrans                    October 2025


     Step 5.  If CE has a profile, the profile is converted to a $profile-
              type-choice then copied to the ECT.profile` field.

     The completed ECT is added to the ae list.

  6.  DMTF SPDM Structure Definitons

     This section defines how a Verifier shall parse a DMTF Measurement
     Block.

     DMTF Measurement Block Definition:

     *  Byte Offset 0: DMTFSpecMeasurementValueType

        -  Bit 7 = 0b Digest / 1b Raw bit stream

        -  Bit [6:0] = Indicate what is measured

           o  0x0 Immutable Rom

           o  0x1 Mutable FW

           o  0x2 HW Config

           o  0x3 FW config

           o  0x4 Freeform Manifest

           o  0x5 Structured Representation of debug and device mode

           o  0x6 Mutable FW Version Number

           o  0x7 Mutable FW Secure Version Number

           o  0x8 Hash-Extend Measurement (new in SPDM 1.3)

           o  0x9 Informational (new in SPDM 1.3)

           o  0xA Structured Measurement Manifest (new in SPDM 1.3)

     *  Byte Offset 1: DMTFSpecMeasurementValueSize

     *  Byte Offset 3: DMTFSpecMeasurementValue

     Structured Manifest Block Definition (only for >=SPDM 1.3):

     *  Byte Offset 0: Standard Body or Vendor Defined Header (SVH)




  D'Amato, et al.           Expires 20 April 2026                [Page 12]


  Internet-Draft                   EvTrans                    October 2025


     *  Byte Offset 2 + VendorIdLen: Manifest

     Standard Body or Vendor Defined Header (SVH) Definition (only for
     >=SPDM 1.3):

     *  Byte Offset 0: ID

     *  Byte Offset 1: VendorIdLen

     *  Byte Offset 2: VendorId

     DMTF Header for Concise Evidence Manifest Block:

     If SPDM Version 1.2:

     *  DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)

     *  DMTFSpecMeasurementValueSize = Size of tagged-spdm-toc CBOR Tag

     *  DMTFSpecMeasurementValue = tagged-spdm-toc CBOR Tag

     if SPDM >=Version 1.3:

     *  DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured
        Manifest)

     *  DMTFSpecMeasurementValueSize = Size of Structured Manifest

     *  DMTFSpecMeasurementValue = Structured Manifest

     SVH for Concise Evidence Manifest Block:

     *  ID = 0xA (IANA CBOR)

     *  VendorIdLen = 2

     *  VendorId = 0x570 #6.570(spdm-toc-map)

     Structured Manifest Block Definition for Concise Evidence:

     *  SVH = SVH for Concise Evidence Manifest Block

     *  Manifest = tagged-spdm-toc CBOR Tag Payload

     DMTF Header for CBor Web Token (CWT):

     If SPDM Version 1.2:




  D'Amato, et al.           Expires 20 April 2026                [Page 13]


  Internet-Draft                   EvTrans                    October 2025


     *  DMTFSpecMeasurementValueType = 0x84 (Raw Bit / Freeform Manifest)

     *  DMTFSpecMeasurementValueSize = Size of CWT

     *  DMTFSpecMeasurementValue = CWT # COSE_Sign1

     if SPDM = Version 1.3:

     *  DMTFSpecMeasurementValueType = 0x8A (Raw Bit / Structured
        Manifest)

     *  DMTFSpecMeasurementValueSize = Size of Structured Manifest

     *  DMTFSpecMeasurementValue = Structured Manifest

     SVH for CBor Web Token (CWT):

     *  ID = 0xA (IANA CBOR)

     *  VendorIdLen = 2

     *  VendorId = 0x18 #6.18

     Structured Manifest Block Definition for CBor Web Token (CWT):

     *  SVH = SVH for CBor Web Token (CWT)

     *  Manifest = COSE_Sign1 Payload

  7.  Transforming SPDM Measurement Block Digest

     Step 1.  if DMTFSpecMeasurementValueType is in range [0x80 - 0x83]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.digests).

     Step 2.  if DMTFSpecMeasurementValueType is in range [0x88]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.integrity-
                 registers).

  8.  Transforming SPDM Measurement Block Raw Value

     Step 1.  if DMTFSpecMeasurementValueType is in range [0x7]:

                 *copy*(SPDM.MeasurementBlock.DMTFSpecMeasurementValue ,
                 ECT.environment.measurement-map.mval.svn).



  D'Amato, et al.           Expires 20 April 2026                [Page 14]


  Internet-Draft                   EvTrans                    October 2025


  9.  Transforming SPDM RATS EAT CWT

     The RATS EAT CWT shall be reported in any of the assigned Measurement
     Block 0xFD The Concise Evidence CBOR Tag is serialized inside eat-
     measurements (273) claim ($measurements-body-cbor /= bytes .cbor
     concise-evidence-map) Subsequently the transformation steps defined
     in Section 5.

  10.  Transforming SPDM Evidence

     This section defines how Evidence from SPDM [SPDM] is transformed
     into an internal representation that can be processed by Verifiers.

     Verifiers supporting the SPDM Evidence format SHOULD implement this
     transformation.  SPDM Responders SHALL support a minimum version of
     1.2

     Theory of Operations:

     *  The SPDM Requestor SHALL retrieve the measurement Manifest at
        Block 0xFD (Manifest Block) and send its payload to the Verifier

        -  The Verifier SHALL decode the payload as a tagged-spdm-toc CBOR
           tag.

        -  The Verifier SHALL extract the tagged-concise-evidence CBOR TAG
           from the tagged-spdm-toc CBOR tag

     Theconcise-evidence has a format that is similar to CoRIM triples-map
     (their semantics follows the matching rules described above).

     *  For every spdm-indirect measurement the Verifier shall ask the
        SPDM Requestor to retrieve the measurement block indicated by the
        index

        -  if the index is in range [0x1 - 0xEF] (refer to #Transforming
           SPDM Measurement Block Digest)

        -  if the index is 0xFD (refer to #Transforming SPDM RATS EAT CWT]
           )

     The TCG DICE Concise Evidence Binding for SPDM specification [TCG.CE]
     describes a process for converting the SPDM Measurement Block to
     Concise Evidence.  Subsequently the transformation steps defined in
     Section 5.






  D'Amato, et al.           Expires 20 April 2026                [Page 15]


  Internet-Draft                   EvTrans                    October 2025


     The keys provided in the ECT.authority field SHOULD include the key
     which signed the SPDM MEASUREMENTS response carrying the Evidence and
     keys which authorized that key as described in Section 4.4.```

  11.  Implementation Status

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in [RFC7942].
     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.  Please note that the listing of any individual implementation
     here does not imply endorsement by the IETF.  Furthermore, no effort
     has been spent to verify the information presented here that was
     supplied by IETF contributors.  This is not intended as, and must not
     be construed to be, a catalogue of available implementations or their
     features.  Readers are advised to note that other implementations may
     exist.

     According to [RFC7942], "this will allow reviewers and working groups
     to assign due consideration to documents that have the benefit of
     running code, which may serve as Evidence of valuable experimentation
     and feedback that have made the implemented protocols more mature.
     It is up to the individual working groups to use this information as
     they see fit".

  12.  Security Considerations

     Evidence appraisal is at the core of any RATS protocol flow,
     mediating all interactions between Attesters and their Relying
     Parties.  The Verifier is effectively part of the Attesters' and
     Relying Parties' trusted computing base (TCB).  Any mistake in the
     appraisal process could have security implications.  For instance, it
     could lead to the subversion of an access control function, which
     creates a chance for privilege escalation.

     Therefore, the Verifier’s code and configuration, especially those of
     the CoRIM processor, are primary security assets that must be built
     and maintained as securely as possible.

     The protection of both the Attester and Verifier systems should be
     considered throughout their entire lifecycle, from design to
     operation.  This includes the following aspects:

     *  Minimizing implementation complexity (see also Section 6.1 of
        [I-D.ietf-rats-endorsements]);

     *  Using memory-safe programming languages;



  D'Amato, et al.           Expires 20 April 2026                [Page 16]


  Internet-Draft                   EvTrans                    October 2025


     *  Using secure defaults;

     *  Minimizing the attack surface by avoiding unnecessary features
        that could be exploited by attackers;

     *  Applying the principle of least privilege to the system's users;

     *  Minimizing the potential impact of security breaches by
        implementing separation of duties in both the software and
        operational architecture;

     *  Conducting regular, automated audits and reviews of the system,
        such as ensuring that users' privileges are correctly configured
        and that any new code has been audited and approved by independent
        parties;

     *  Failing securely in the event of errors to avoid compromising the
        security of the system.

     The appraisal process should be auditable and reproducible.  The
     integrity of the code and data during execution should be made an
     explicit objective, for example ensuring that the appraisal functions
     are computed in an attestable trusted execution environment (TEE).

     The integrity of public and private key material and the secrecy of
     private key material must be ensured at all times.  This includes key
     material carried in attestation key triples and key material used to
     assert or verify the authority of triples (such as public keys that
     identify trusted supply chain actors).  For more detailed information
     on protecting Trust Anchors, refer to Section 12.4 of [RFC9334].

     The Verifier should use cryptographically protected, mutually
     authenticated secure channels to all its trusted input sources (i.e.,
     Attesters, Endorsers, RVPs, Verifier Owners).  The Attester should
     use cryptographically protected, mutually authenticated secure
     channels to all its trusted input sources (i.e., Verifiers, Relying
     Parties).  These links must reach as deep as possible - possibly
     terminating within the Attesting Environment of an Attester or within
     the appraisal session context of a Verifier - to avoid man-in-the-
     middle attacks.  Also consider minimizing the use of intermediaries:
     each intermediary becomes another party that needs to be trusted and
     therefore factored in the Attesters and Relying Parties' TCBs.  Refer
     to Section 12.2 of [RFC9334] for information on Conceptual Messages
     protection.







  D'Amato, et al.           Expires 20 April 2026                [Page 17]


  Internet-Draft                   EvTrans                    October 2025


  13.  IANA Considerations

     There are no IANA considerations.

  14.  References

  14.1.  Normative References

     [DICE.Attest]
                Trusted Computing Group (TCG), "DICE Attestation
                Architecture", Version 1.2, Revision 1 , January 2025,
                <https://trustedcomputinggroup.org/wp-content/uploads/
                DICE-Attestation-Architecture-Version-1.2-rc-
                1_9January25.pdf>.

     [DICE.CoRIM]
                Trusted Computing Group (TCG), "DICE Endorsement
                Architecture for Devices", Version 1.0, Revision 0.38 ,
                November 2022, <https://trustedcomputinggroup.org/wp-
                content/uploads/TCG-Endorsement-Architecture-for-Devices-
                V1-R38_pub.pdf>.

     [I-D.ietf-rats-corim]
                Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
                W. Pan, "Concise Reference Integrity Manifest", Work in
                Progress, Internet-Draft, draft-ietf-rats-corim-08, 7 July
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                rats-corim-08>.

     [I-D.ietf-rats-endorsements]
                Thaler, D., Birkholz, H., and T. Fossati, "RATS
                Endorsements", Work in Progress, Internet-Draft, draft-
                ietf-rats-endorsements-07, 25 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                endorsements-07>.

     [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/rfc/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/rfc/rfc8174>.







  D'Amato, et al.           Expires 20 April 2026                [Page 18]


  Internet-Draft                   EvTrans                    October 2025


     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [SPDM]     Distributed Management Task Force, "Security Protocol and
                Data Model (SPDM)", Version 1.3.0 , May 2023,
                <https://www.dmtf.org/sites/default/files/standards/
                documents/DSP0274_1.3.0.pdf>.

     [TCG.CE]   Trusted Computing Group, "TCG DICE Concise Evidence
                Binding for SPDM", Version 1.00, Revision 0.54 , January
                2024, <https://trustedcomputinggroup.org/wp-
                content/uploads/TCG-DICE-Concise-Evidence-Binding-for-
                SPDM-Version-1.0-Revision-54_pub.pdf>.

  14.2.  Informative References

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.

     [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/rfc/rfc8610>.

     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
                DOI 10.17487/RFC9711, April 2025,
                <https://www.rfc-editor.org/rfc/rfc9711>.

     [STD94]    Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.







  D'Amato, et al.           Expires 20 April 2026                [Page 19]


  Internet-Draft                   EvTrans                    October 2025


     [STD96]    Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

  Contributors

     The authors would like to thank the following people for their
     valuable contributions to the specification.

     Henk Birkholz

     Email: henk.birkholz@ietf.contact

     Yogesh Deshpande

     Email: yogesh.deshpande@arm.com

     Thomas Fossati

     Email: Thomas.Fossati@linaro.org

     Dionna Glaze

     Email: dionnaglaze@google.com

  Acknowledgments

     The authors would like to thank James D.  Beaney, Francisco J.
     Chinchilla, Vincent R.  Scarlata, and Piotr Zmijewski for review
     feedback.

  Authors' Addresses

     Fabrizio D'Amato
     AMD
     Email: fabrizio.damato@amd.com


     Andrew Draper
     Independent
     Email: andrew.draper@freeside.org.uk


     Ned Smith
     Independent
     Email: ned.smith.ietf@outlook.com




  D'Amato, et al.           Expires 20 April 2026                [Page 20]


name: draft-loffredo-regext-rdap-verified-contacts
rev: 03
title: Registration Data Access Protocol (RDAP) Extension for Verified Contact Information
time: 2026-02-23T10:39:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-27T10:39:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.339358+00:00
source: ietf
source_id: 146804
source_url: https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-verified-contacts/
doc_status: active
abstract:
  This document describes an extension to the Registration Data Access
     Protocol (RDAP) that allows the inclusion of verification status
     information for contact fields such as email addresses and phone
     numbers.  The goal is to improve data quality and trustworthiness of
     RDAP responses by indicating which pieces of contact data have been
     verified and how.

full_text:
  Network Working Group                                        M. Loffredo
  Internet-Draft                                             M. Martinelli
  Intended status: Standards Track                     IIT-CNR/Registro.it
  Expires: 27 August 2026                                       J.G. Gould
                                                            VeriSign, Inc.
                                                                P. Kowalik
                                                                  DENIC eG
                                                          23 February 2026


  Registration Data Access Protocol (RDAP) Extension for Verified Contact
                                Information
              draft-loffredo-regext-rdap-verified-contacts-03

  Abstract

     This document describes an extension to the Registration Data Access
     Protocol (RDAP) that allows the inclusion of verification status
     information for contact fields such as email addresses and phone
     numbers.  The goal is to improve data quality and trustworthiness of
     RDAP responses by indicating which pieces of contact data have been
     verified and how.

  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 27 August 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.



  Loffredo, et al.         Expires 27 August 2026                 [Page 1]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     3.  RDAP Conformance  . . . . . . . . . . . . . . . . . . . . . .   3
     4.  JSON Structure  . . . . . . . . . . . . . . . . . . . . . . .   3
     5.  verifiedContacts_data Structure . . . . . . . . . . . . . . .   4
     6.  Combining Evidence and Method . . . . . . . . . . . . . . . .   9
     7.  Extension Version Identifier  . . . . . . . . . . . . . . . .  11
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       8.1.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .  12
       8.2.  RDAP JSON Values Registry . . . . . . . . . . . . . . . .  12
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  23
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  23
       11.2.  Informative References . . . . . . . . . . . . . . . . .  24
     Appendix A.  Change History . . . . . . . . . . . . . . . . . . .  24
       A.1.  Change from 00 to 01  . . . . . . . . . . . . . . . . . .  24
       A.2.  Change from 01 to 02  . . . . . . . . . . . . . . . . . .  24
       A.3.  Change from 02 to 03  . . . . . . . . . . . . . . . . . .  25
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     The Registration Data Access Protocol (RDAP) provides access to
     registration data for domain names, IP addresses, and autonomous
     system numbers.  However, RDAP responses do not currently include
     explicit information about whether contact information such as email
     addresses or phone numbers has been verified.

     This document defines a simple extension that enables RDAP providers
     to include verification status for contact fields.  This is useful in
     contexts where contact verification may be legally required or
     strongly recommended.

     In particular, Article 28 of Directive (EU) 2022/2555 ([NIS2])
     requires top-level domain (TLD) name registries and domain name
     registrars to collect and maintain accurate and complete domain name
     registration data.  Assuring accuracy and completeness of
     registration data may involve verification of contact details and, in
     some cases, publishing their verification status—either in a publicly



  Loffredo, et al.         Expires 27 August 2026                 [Page 2]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     accessible RDAP service or in a closed RDAP service requiring prior
     authorization for legitimate access seekers or authorities.  The
     extension defined in this document can support compliance with these
     obligations by enabling the inclusion of verification status for
     contact fields in RDAP responses in a standardized way.

  2.  Conventions Used in This Document

     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.

  3.  RDAP Conformance

     Servers implementing this extension MUST include the string
     "verifiedContacts" in the "rdapConformance" ([RFC9083]) array of all
     relevant RDAP responses.  The registration of the "verifiedContacts"
     extension identifier is described in Section 8.

  4.  JSON Structure

     The verification information is conveyed via a new top-level object
     member named "verifiedContacts_data" within the entity objects.


























  Loffredo, et al.         Expires 27 August 2026                 [Page 3]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     {
       "objectClassName": "entity",
       "handle": "ABC123-EXAMPLE",
       "rdapConformance": ["rdap_level_0", "verifiedContacts"],
       ...
       "verifiedContacts_data":
       {
         [
           "claims": ["name", "address"],
           "verificationDate": "2025-03-15T12:00:00Z",
           "trustFramework": "eidas",
           "verifierId": "Registro.it",
           "verificationId": "verif-20250315-0001",
           "evidence": "idcard",
           "method": "auth"
         ],
         [
           "claims": ["email"],
           "verificationDate": "2025-03-10T09:30:00Z",
           "trustFramework": "registro.it",
           "verifierId": "Registro.it",
           "verificationId": "verif-20250310-0001",
           "method": "reachability",
           "remarks" :
             [
               {
                 "description" :
                 [
                   "E-mail verification embedded
                   in onboarding process."
                 ]
               }
             ]
         ]
         ...
       }
     }

      Figure 1: Entity object including the "verifiedContacts_data" member

  5.  verifiedContacts_data Structure

     The "verifiedContacts_data" member is an array if objects containing:

     "verificationDate":  (OPTIONAL) A string with the date and time of
         verification, represented as an [RFC3339] date-time profile
         format.




  Loffredo, et al.         Expires 27 August 2026                 [Page 4]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     "verifierId":  (OPTIONAL) Verifier identifier, that is a server
         unique number or a delimited string using a '-' as a separator
         character to support a regional or globally unique identifier.
         The minimum length is 1 character and the maximum length is 40
         characters.  The set of verifiers and verifier identifiers is up
         to server policy.

     "verifierName":  (OPTIONAL) Verifier name of the verifier that is a
         simple character string, with a minimum length of 1 character and
         a maximum length of 40 characters.  The set of verifiers and
         verifier identifiers is up to server policy.

     "verificationId":  (OPTIONAL) Verification identifier that
         unambigously identifies the verification performed by the
         verification provider.

     "claims":  (OPTIONAL) An array of strings indicating which parts of
         the data has been verified in a given process.

         The list of allowed values is specified by entries of a type
         "verified contact claim" in "RDAP JSON Values Registry" and is
         extendible.

         This specification defines the following set of values based on
         [OpenID]:

         "email":  E-mail address.

         "phone number":  Voice phone number.

         "fax":  Fax phone number.

         "address":  Address.

         "name":  Entities full name.

         "given name":  Given name or first name of the entity.

         "family name":  Surname or last name of the entity.

         "birthdate":  Date of birth.

     "trustFramework":  (OPTIONAL) A string determining the trust
         framework governing the identity verification process.

         The list of allowed values is specified by entries of a type
         "verified contact trust framework" in "RDAP JSON Values Registry"
         and is extendible.



  Loffredo, et al.         Expires 27 August 2026                 [Page 5]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


         If the verification is conducted according to the policy
         framework of server operator, this value SHOULD be specific to
         this operator unless external policy has been adopted.

         This specification defines the following set of values:

         "eidas":  The verification has been conducted in accordance with
             the EU regulation No 910/2014 (eIDAS).

         "private":  The verification has been conducted in accordance
             private policy framework of server operator.

     "method":  (OPTIONAL) A string indicating a verification method.

         The list of allowed values is specified by entries of a type
         "verified contact method" in "RDAP JSON Values Registry" and is
         extendible.

         This specification defines the following set of values, based on
         Check Methods defined in [IDA-Predefined-Values] referred from
         [IDA-verified-claims]:

         "vpip":  Validation that physical evidence is genuine through
             inspection of its physical properties in person.

         "vpiruv":  Validation that physical evidence is genuine through
             inspection of its physical properties in person including its
             optical characteristics under non-visible light.

         "vri":  Validation that physical evidence is genuine through the
             inspection of an image taken remotely under visible light.

         "vdig":  Validation that digital/electronic evidence is genuine
             by the inspection of its properties and content.

         "vcrypt":  Validation the cryptographic security features of the
             evidence are intact and correct.

         "data":  Found an existing electronic record that matches the
             claims made by the user.

         "auth":  Verifying the user is the owner of the claims by use of
             an electronic authentication process that is linked to the
             owner of the claims.

         "token":  Verifying the user is the owner of the claims by use of





  Loffredo, et al.         Expires 27 August 2026                 [Page 6]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


             an electronic authentication token such as hardware token or
             smartcard that is linked and issued to the owner of the
             claims.

         "kbv":  Verifying the user is the owner of the claims by
             knowledge based challenges/questions that only the owner of
             the claims should know how to answer.

         "pvp":  Physical verification in person by a qualified/authorised
             person, the comparison of a physical characteristic (such as
             face) of the user with a known image/template of the owner of
             the claims.

         "pvr":  Physical verification by a qualified/authorised person
             when the user is remote, the comparison of a physical
             characteristic (such as face) from an image or video of the
             user with a known image/template of the owner of the claims.

         "bvp":  Biometric verification by an automated system with the
             user physically present to the system and the verifier, the
             use of a biometric modality (such as face) to match the user
             with a known template of the owner of the claims.

         "bvr":  Biometric verification by an automated system where the
             user and capture device is remote to the verifier, the use of
             a biometric modality (such as face) to match the user with a
             known template of the owner of the claims.

         "reachability":  Verification conducted in a way that confirms
             the reliability of the chosen communication method, requiring
             the recipient to actively acknowledge receipt through an
             appropriate confirmation action, such as signing a
             confirmation of receipt, entering a code or clicking a link

     "evidence":  (OPTIONAL) A string indicating an evidence used in the
         verification.

         The list of allowed values is specified by entries of a type
         "verified contact evidence" in "RDAP JSON Values Registry" and is
         extendible.

         This specification defines the following set of values, based on
         Documents, Electronic records and Vouches defined in
         [IDA-Predefined-Values] referred from [IDA-verified-claims]:

         "idcard":  An identity document issued by a country's government
             for the purpose of identifying a citizen.




  Loffredo, et al.         Expires 27 August 2026                 [Page 7]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


         "passport":  A passport is a travel document, usually issued by a
             country's government, that certifies the identity and
             nationality of its holder primarily for the purpose of
             international travel.

         "residence permit":  Official document permitting an individual
             to reside within a particular jurisdiction.

         "bank statement":  Bank statement from a recognized banking
             institution.

         "utility statement":  Statement from a recognized utility
             provider.

         "tax statement":  Statement from a country's tax authority.

         "birth certificate":  Official document certifying the
             circumstances of a birth.

         "birth register":  A record from an official register of births.

         "population register":  A record from an official population
             register.

         "written attestation":  A written/printed statement/letter from a
             recognised person or authority regarding the identity of the
             entity.

         "digital attestation":  A statement from a recognised person or
             authority regarding the identity of the entiry that was made
             and stored electronically.

         "email ver transaction log":  A digital transaction log of an
             appropriate confirmation action of email verification, such
             as entering a code or clicking a link.

         "postal ver transaction log":  A digital transaction log of an
             appropriate confirmation action of postal verification, such
             as confirmation of receipt, entering a code or clicking a
             link.

         "address database":  Information from a reliable address
             database.

     "remarks":  (OPTIONAL) property, which is an array of remarks (see
         Section 4.3 of [RFC9083]).

     "extension":  (OPTIONAL) property, which is a map of objects.



  Loffredo, et al.         Expires 27 August 2026                 [Page 8]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


         The list of allowed values is specified by entries of a type
         "verified contact extension" in "RDAP JSON Values Registry" and
         is extendible.

         This specification does not specify any entries to this registry
         leaving it open for other specificiations.

  6.  Combining Evidence and Method

     In most common cases a verification of data consists of comparison
     against some authoritative source or document (evidence) using one of
     the allowed methods (method) within a defined trust framework.  The
     same evidence may be verified using different methods, just as the
     same method may be applied to different evidences.  Therefore, a
     description of the verification process typically specifies the
     values in a combination.

     Real life examples of such combinations:

     *  Email verification

        {
          ...
          "verifiedContacts_data":
          {
            [
              "claims": ["email"],
              "method": "reachability",
              "evidence": "email ver transaction log",
              "remarks" :
                [
                  {
                    "description" :
                    [
                      "Sending a confirmation link to
                      the specified email address and
                      requiring user interaction (e.g.,
                      clicking the link) to confirm
                      ownership."
                    ]
                  }
                ]
            ]
            ...
          }
        }

     *  Address Verification



  Loffredo, et al.         Expires 27 August 2026                 [Page 9]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


        {
          ...
          "verifiedContacts_data":
          {
            [
              "claims": ["address"],
              "method": "data",
              "evidence": "address database",
              "remarks" :
                [
                  {
                    "description" :
                    [
                      "Verification of the postal address using
                        a geolocation or address validation service
                        (e.g., Google Maps API, OpenStreetMap,
                        postal databases)."
                    ]
                  }
                ]
            ]
            ...
          }
        }

     *  Manual review

























  Loffredo, et al.         Expires 27 August 2026                [Page 10]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


        {
          ...
          "verifiedContacts_data":
          {
            [
              "claims": ["name", "address"],
              "method": "pvr",
              "evidence": "idcard",
              "remarks" :
                [
                  {
                    "description" :
                    [
                      "Manual review of contact data by a human operator
                        (e.g., calling the phone number, making a live
                        video call, inspecting submitted documentation)."
                    ]
                  }
                ]
            ]
            ...
          }
        }

  7.  Extension Version Identifier

     This extension supports the following versioning types as defined in
     [I-D.ietf-regext-rdap-versioning]:

     *  Opaque Versioning: The Opaque Extension Version Identifier is
        "verifiedContacts".

     *  Semantic Versioning: The Semantic Extension Version Identifier is
        "verifiedContacts-0.3".  The Semantic Extension Version Identifier
        is "verifiedContacts-0.2" for draft-loffredo-regext-rdap-verified-
        contacts-02 and "verifiedContacts-0.1" for draft-loffredo-regext-
        rdap-verified-contacts-01.  When there are interface changes to
        the extension, the Semantic Extension Version Identifier will be
        incremented, which may not match the draft version number.  When
        the draft becomes a working group document and passes Working
        Group Last Call (WGLC), the Semantic Extension Version Identifier
        will be changed to "verifiedContacts-1.0".

  8.  IANA Considerations







  Loffredo, et al.         Expires 27 August 2026                [Page 11]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


  8.1.  RDAP Extensions Registry

     IANA is requested to register the following value in the RDAP
     Extensions Registry:

     Extension identifier:  verifiedContacts
     Registry operator:  Any
     Published specification:  This document.
     Contact:  IETF <iesg@ietf.org>
     Intended usage:  This extension identifies RDAP extension for
        verified contact information.

  8.2.  RDAP JSON Values Registry

     Section 10.2 of [RFC9083] defines the RDAP JSON Values Registry with
     pre-defined Type field values and the use of the "Expert Review"
     policy defined in [RFC8126].  This specification defines new RDAP
     JSON Values Registry Type field values that can be used to register
     pre-defined "verified contact claim", "verified contact method",
     "verified contact trust framework", "verified contact evidence" and
     "verified contact extension" values.  IANA is requested to update the
     RDAP JSON Values Registry to accept these additional type field
     values as follows:

     "verified contact claim":  Verified contact claim being registered.
         The registered "verified contact claim" is referenced using a
         sub-field of the verified contacts "verifiedContacts_data" field.

     "verified contact method":  Verified contact method being registered.
         The "verified contact method" is referenced using the "method"
         field of the verified contacts detail (e.g., "email", "voice",
         "fax", "addr") field.

     "verified contact evidence":  Verified contact evidence being
         registered.  The "verified contact evidence" is referenced using
         a sub-field of the verified contacts "verifiedContacts_data"
         field.

     "verified contact trust framework":  Verified contact trust framework
         registered.  The "verified contact trust framework" is referenced
         using a sub-field of the verified contacts
         "verifiedContacts_data" field.

     "verified contact extension":  Verified contact extension field being
         registered.  The "verified contact extension" is referenced using
         a sub-field of the verified contacts "verifiedContacts_data"
         field.




  Loffredo, et al.         Expires 27 August 2026                [Page 12]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     IANA is requested to register the following in the RDAP JSON Values
     Registry, described in [RFC9083]:

     Value:  email

     Type:  verified contact claim

     Description:  E-mail address.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  phone number

     Type:  verified contact claim

     Description:  Voice phone number.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  fax

     Type:  verified contact claim

     Description:  Fax phone number.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  address

     Type:  verified contact claim

     Description:  Address.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



  Loffredo, et al.         Expires 27 August 2026                [Page 13]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Value:  name

     Type:  verified contact claim

     Description:  Entities full name.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org

     Value:  given name

     Type:  verified contact claim

     Description:  Given name or first name of the entity.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org

     Value:  family name

     Type:  verified contact claim

     Description:  Surname or last name of the entity.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org

     Value:  birthdate

     Type:  verified contact claim

     Description:  Date of birth.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  vpip

     Type:  verified contact method

     Description:  Validation that physical evidence is genuine through
         inspection of its physical properties in person.



  Loffredo, et al.         Expires 27 August 2026                [Page 14]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  vpiruv

     Type:  verified contact method

     Description:  Validation that physical evidence is genuine through
         inspection of its physical properties in person including its
         optical characteristics under non-visible light.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  vri

     Type:  verified contact method

     Description:  Validation that physical evidence is genuine through
         the inspection of an image taken remotely under visible light.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  vdig

     Type:  verified contact method

     Description:  Validation that digital/electronic evidence is genuine
         by the inspection of its properties and content.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  vcrypt




  Loffredo, et al.         Expires 27 August 2026                [Page 15]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Type:  verified contact method

     Description:  Validation the cryptographic security features of the
         evidence are intact and correct.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  data

     Type:  verified contact method

     Description:  Found an existing electronic record that matches the
         claims made by the user.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  auth

     Type:  verified contact method

     Description:  Verifying the user is the owner of the claims by use of
         an electronic authentication process that is linked to the owner
         of the claims.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  token

     Type:  verified contact method

     Description:  Verifying the user is the owner of the claims by use of
         an electronic authentication token such as hardware token or
         smartcard that is linked and issued to the owner of the claims.

     Registrant Name:  IETF




  Loffredo, et al.         Expires 27 August 2026                [Page 16]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Registrant Contact Information:  iesg@ietf.org



     Value:  kbv

     Type:  verified contact method

     Description:  Verifying the user is the owner of the claims by
         knowledge based challenges/questions that only the owner of the
         claims should know how to answer.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  pvp

     Type:  verified contact method

     Description:  Physical verification in person by a qualified/
         authorised person, the comparison of a physical characteristic
         (such as face) of the user with a known image/template of the
         owner of the claims.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  pvr

     Type:  verified contact method

     Description:  Physical verification by a qualified/authorised person
         when the user is remote, the comparison of a physical
         characteristic (such as face) from an image or video of the user
         with a known image/template of the owner of the claims.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org






  Loffredo, et al.         Expires 27 August 2026                [Page 17]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Value:  bvp

     Type:  verified contact method

     Description:  Biometric verification by an automated system with the
         user physically present to the system and the verifier, the use
         of a biometric modality (such as face) to match the user with a
         known template of the owner of the claims.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  bvr

     Type:  verified contact method

     Description:  Biometric verification by an automated system where the
         user and capture device is remote to the verifier, the use of a
         biometric modality (such as face) to match the user with a known
         template of the owner of the claims.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  reachability

     Type:  verified contact method

     Description:  Verification conducted in a way that confirms the
         reliability of the chosen communication method, requiring the
         recipient to actively acknowledge receipt through an appropriate
         confirmation action, such as signing a confirmation of receipt,
         entering a code or clicking a link.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  idcard




  Loffredo, et al.         Expires 27 August 2026                [Page 18]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Type:  verified contact evidence

     Description:  An identity document issued by a country's government
         for the purpose of identifying a citizen.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  passport

     Type:  verified contact evidence

     Description:  A passport is a travel document, usually issued by a
         country's government, that certifies the identity and nationality
         of its holder primarily for the purpose of international travel.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  residence permit

     Type:  verified contact evidence

     Description:  Official document permitting an individual to reside
         within a particular jurisdiction.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  bank statement

     Type:  verified contact evidence

     Description:  Bank statement from a recognized banking institution.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org




  Loffredo, et al.         Expires 27 August 2026                [Page 19]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Value:  utility statement

     Type:  verified contact evidence

     Description:  Statement from a recognized utility provider.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  tax statement

     Type:  verified contact evidence

     Description:  Statement from a country's tax authority.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  birth certificate

     Type:  verified contact evidence

     Description:  Official document certifying the circumstances of a
         birth.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  birth register

     Type:  verified contact evidence

     Description:  A record from an official register of births.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org





  Loffredo, et al.         Expires 27 August 2026                [Page 20]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Value:  population register

     Type:  verified contact evidence

     Description:  A record from an official population register.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  written attestation

     Type:  verified contact evidence

     Description:  A written/printed statement/letter from a recognised
         person or authority regarding the identity of the entity.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  digital attestation

     Type:  verified contact evidence

     Description:  A statement from a recognised person or authority
         regarding the identity of the entiry that was made and stored
         electronically.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  email ver transaction log

     Type:  verified contact evidence

     Description:  A digital transaction log of an appropriate
         confirmation action of email verification, such as entering a
         code or clicking a link.

     Registrant Name:  IETF



  Loffredo, et al.         Expires 27 August 2026                [Page 21]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Registrant Contact Information:  iesg@ietf.org



     Value:  postal ver transaction log

     Type:  verified contact evidence

     Description:  A digital transaction log of an appropriate
         confirmation action of postal verification, such as confirmation
         of receipt, entering a code or clicking a link.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  address database

     Type:  verified contact evidence

     Description:  Information from a reliable address database.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  eidas

     Type:  verified contact trust framework

     Description:  The verification has been conducted in accordance with
         the EU regulation No 910/2014 (eIDAS).

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



     Value:  private

     Type:  verified contact trust framework

     Description:  The verification has been conducted in accordance



  Loffredo, et al.         Expires 27 August 2026                [Page 22]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


         private policy framework of server operator.

     Registrant Name:  IETF

     Registrant Contact Information:  iesg@ietf.org



  9.  Security Considerations

     Contact verification data may have privacy implications.  Servers
     MUST ensure that disclosure of this information complies with
     applicable data protection laws and policies.

  10.  Acknowledgements

     The authors wish to thank the following persons for their feedback
     and suggestions: Scott Hollenbeck.

  11.  References

  11.1.  Normative References

     [I-D.ietf-regext-rdap-versioning]
                Gould, J., Keathley, D., and M. Loffredo, "Versioning in
                the Registration Data Access Protocol (RDAP)", Work in
                Progress, Internet-Draft, draft-ietf-regext-rdap-
                versioning-04, 11 December 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-regext-
                rdap-versioning-04>.

     [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>.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

     [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>.

     [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>.



  Loffredo, et al.         Expires 27 August 2026                [Page 23]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     [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>.

  11.2.  Informative References

     [IDA-Predefined-Values]
                OpenID Foundation, "Overview page for predefined values",
                2021, <https://openid.net/wg/ekyc-ida/identifiers/>.

     [IDA-verified-claims]
                Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann,
                K., and K. Koiwai, "OpenID Identity Assurance Schema
                Definition", 9 August 2023, <https://openid.net/specs/
                openid-ida-verified-claims-1_0.html>.

     [NIS2]     European Parliament and Council, "Directive (EU) 2022/2555
                of the European Parliament and of the Council of 14
                December 2022 on measures for a high common level of
                cybersecurity across the Union, amending Regulation (EU)
                No 910/2014 and Directive (EU) 2018/1972, and repealing
                Directive (EU) 2016/1148 (NIS 2 Directive)", December
                2022, <https://eur-lex.europa.eu/legal-content/EN/TXT/
                PDF/?uri=CELEX:02022L2555-20221227>.

     [OpenID]   Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
                C. Mortimore, "OpenID Connect Core 1.0 incorporating
                errata set 1", 8 November 2014,
                <https://openid.net/specs/openid-connect-core-1_0.html>.

  Appendix A.  Change History

  A.1.  Change from 00 to 01

     1.  Made The "verifiedContacts_data" keys consistent with those
         defined in draft-ietf-regext-rdap-jscontact.
     2.  Further specified the verification methods and changed their
         format to CamelCase.

  A.2.  Change from 01 to 02

     1.   Added definition of the "verified contact detail" and "verified
          contact method" RDAP JSON Values types and added a set of RDAP
          JSON Values registrations.
     2.   Updated the "method" values to be lowercase with a space word
          separator to match the requirement for registered RDAP JSON
          Values.



  Loffredo, et al.         Expires 27 August 2026                [Page 24]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     3.   Added support for semantic versioning using the versioning
          extension and included the semantic versions for the prior draft
          versions.
     4.   Added the "all", "email", "voice", "fax", and "addr" verified
          contact detail registration.
     5.   Added the "verifierId" optional field to reference who performed
          the verification.
     6.   Added the "verificationId" optional field to reference the
          unique verification performed by the verification provider.
     7.   Added the "trustFramework" optional field to reference the
          policy framework of the verification
     8.   Make verification date optional
     9.   Clarified that the extension can be used in both public and
          restricted RDAP services
     10.  Make possible to have multiple verification objects.
     11.  Add verification evidence as optional field.
     12.  Change reference to verified data as an array instead of object
          key, to enable multiple verifications referring to the same data
          element and avoid same verification object repeated if multiple
          data elements were verified.

  A.3.  Change from 02 to 03

     1.   Rename "verified contact detail" to "verified contact claim" to
          match terminology with [OpenID].
     2.   Added "verified contact evidence", "verified contact trust
          framework" to IANA section.
     3.   Synchronised "verified contact claim" IANA section with
          Section 5.
     4.   Changed "verified contact method" according to
          [IDA-verified-claims]
     5.   Removed "all" claim as it is ambigous if the whole set of claims
          in the registration system is unknown.
     6.   Refactor introduction to reflect better NIS-2 requirements.
     7.   Removed ambiguous "all" claim.
     8.   Added "extension" and "remarks" fields.
     9.   Added "email ver transaction log" and "postal ver transaction
          log" evidence.
     10.  Added section Combining Evidence and Method as well as needed
          values to the lists.

  Authors' Addresses

     Mario Loffredo
     IIT-CNR/Registro.it
     Via Moruzzi,1
     56124 Pisa
     Italy



  Loffredo, et al.         Expires 27 August 2026                [Page 25]


  Internet-Draft         Verifying Contacts in RDAP          February 2026


     Email: mario.loffredo@iit.cnr.it
     URI:   http://www.iit.cnr.it


     Maurizio Martinelli
     IIT-CNR/Registro.it
     Via Moruzzi,1
     56124 Pisa
     Italy
     Email: maurizio.martinelli@iit.cnr.it
     URI:   http://www.iit.cnr.it


     James Gould
     VeriSign, Inc.
     12061 Bluemont Way
     Reston, VA 20190
     United States of America
     Email: jgould@verisign.com
     URI:   http://www.verisigninc.com


     P Kowalik
     DENIC eG
     Theodor-Stern-Kai 1
     Frankfurt am Main
     Germany
     Email: pawel.kowalik@denic.de
     URI:   https://denic.de






















  Loffredo, et al.         Expires 27 August 2026                [Page 26]


name: draft-ietf-dnsop-ns-revalidation
rev: 11
title: Delegation Revalidation by DNS Resolvers
time: 2026-01-18T22:05:15Z
group_uri: /api/v1/group/group/1452/
expires: 2026-04-22T23:09:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/42/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.344281+00:00
source: ietf
source_id: 98324
source_url: https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
doc_status: active
abstract:
  This document describes an optional algorithm for the processing of
     Name Server (NS) resource record (RR) sets (RRsets) during iterative
     resolution, and describes the benefits and considerations of using
     this approach.  When following a referral response from an
     authoritative server to a child zone, DNS resolvers should explicitly
     query the authoritative NS RRset at the apex of the child zone and
     cache this in preference to the NS RRset on the parent side of the
     zone cut.  The (A and AAAA) address RRsets in the additional section
     from referral responses and authoritative NS answers for the names of
     the NS RRset, should similarly be re-queried and used to replace the
     entries with the lower trustworthiness ranking in cache.  Resolvers
     should also periodically revalidate the delegation by re-querying the
     parent zone at the expiration of the TTL of either the parent or
     child NS RRset, whichever comes first.

full_text:
  Domain Name System Operations                                   S. Huque
  Internet-Draft                                                Salesforce
  Intended status: Standards Track                                P. Vixie
  Expires: 22 April 2026                                  SIE Europe, U.G.
                                                                 W. Toorop
                                                                NLnet Labs
                                                           19 October 2025


                  Delegation Revalidation by DNS Resolvers
                    draft-ietf-dnsop-ns-revalidation-11

  Abstract

     This document describes an optional algorithm for the processing of
     Name Server (NS) resource record (RR) sets (RRsets) during iterative
     resolution, and describes the benefits and considerations of using
     this approach.  When following a referral response from an
     authoritative server to a child zone, DNS resolvers should explicitly
     query the authoritative NS RRset at the apex of the child zone and
     cache this in preference to the NS RRset on the parent side of the
     zone cut.  The (A and AAAA) address RRsets in the additional section
     from referral responses and authoritative NS answers for the names of
     the NS RRset, should similarly be re-queried and used to replace the
     entries with the lower trustworthiness ranking in cache.  Resolvers
     should also periodically revalidate the delegation by re-querying the
     parent zone at the expiration of the TTL of either the parent or
     child NS RRset, whichever comes first.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/.

     Discussion of this document takes place on the DNSOP Working Group
     mailing list (mailto:dnsop@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/dnsop/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/dnsop/.

     Source for this draft and an issue tracker can be found at
     https://github.com/shuque/ns-revalidation.

  Status of This Memo

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



  Huque, et al.             Expires 22 April 2026                 [Page 1]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     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 22 April 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include 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
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Upgrading NS RRset Credibility  . . . . . . . . . . . . . . .   7
     4.  Limiting upgrading NS Credibility . . . . . . . . . . . . . .   8
     5.  Upgrading A and AAAA RRset Credibility  . . . . . . . . . . .   8
       5.1.  Upgrading glue  . . . . . . . . . . . . . . . . . . . . .   8
       5.2.  Upgrading additional address from authoritative NS
             responses . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  Strict and opportunistic revalidation . . . . . . . . . . . .   9
       6.1.  Strictly revalidating referrals and authoritative NS RRset
             responses . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.2.  Opportunistic revalidating referral and authoritative NS
             RRset responses . . . . . . . . . . . . . . . . . . . . .  10
     7.  Delegation Revalidation . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.  Security and Privacy Considerations . . . . . . . . . . . . .  11
       9.1.  DNSSEC protection of infrastructure data  . . . . . . . .  12
       9.2.  Cache poisoning protection  . . . . . . . . . . . . . . .  12
       9.3.  Other considerations  . . . . . . . . . . . . . . . . . .  13



  Huque, et al.             Expires 22 April 2026                 [Page 2]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
       10.2.  Informative References . . . . . . . . . . . . . . . . .  14
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  16
     Appendix B.  Implementation status  . . . . . . . . . . . . . . .  16
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     This document recommends improved DNS [RFC1034] [RFC1035] resolver
     behavior with respect to the processing of NS record sets during
     iterative resolution.

     In Upgrading NS RRset Credibility (Section 3) we recommend that
     resolvers, when following a referral response from an authoritative
     server to a child zone, should explicitly query the authoritative NS
     RRset at the apex of the child zone and cache this in preference to
     the NS RRset on the parent side of the zone cut.

     Upgrading NS RRset Credibility (Section 3) works most reliably with
     good quality child NS RRsets, where the name servers referenced in
     the RDATA of the NS RRset correspond to IP addresses of nameservers
     which correctly serve the child zone.  We consider both the root, as
     well as the zones delegated from the root, to have good quality child
     NS RRset.  We also note that there may be numerous zones further down
     the DNS delegation hierarchy that may not be competently
     administered, and may have incorrect or stale authoritative NS and
     associated address records.  As a result they may require a resolver
     to fallback to data from the delegating side of the zone cut for
     successful resolution.  Section 4 describes limiting the upgrading of
     NS RRset credibility to address this.

     The address records in the additional section from the referral
     response (as glue) or authoritative NS response that match the names
     of the NS RRset should similarly be re-queried if they are cached
     non-authoritatively.  The authoritative answers from those queries
     should replace the cached non-authoritative A and AAAA RRsets.  This
     is described in (see Upgrading A and AAAA RRset Credibility
     (Section 5)).












  Huque, et al.             Expires 22 April 2026                 [Page 3]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     In Strict and opportunistic revalidation (Section 6), we make a
     distinction between strict and opportunistic revalidation.  Strict
     revalidation provides DNSSEC protection of infrastructure data
     (Section 9.1) with DNSSEC signed infrastructure data and validating
     resolvers, but for it to work correctly, good quality child NS RRsets
     are a pre-requisite.  Opportunistic revalidation allows for fallback
     to the non-authoritative data returned in the referral responses, but
     therefore does not provide the same degree of protection as strict
     revalidation does.

     Finally, in Delegation Revalidation (Section 7), we recommend that
     resolvers revalidate the delegation by re-querying the parent zone at
     the expiration of the TTL of the parent side NS RRset.

  1.1.  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.

     Throughout this document we will also use terminology with the
     meaning as defined below:

     Triggering query:
        the DNS query that caused ("triggered") a referral response.

     Infrastructure RRsets (data):
        the NS and address (A and AAAA) RRsets used by resolvers to
        contact the authoritative name servers

     Revalidation:
        the process of obtaining the authoritative infrastructure data

     Validation (validating) query:
        the extra query that is performed to get the authoritative version
        of infrastructure RRsets

     Delegation revalidation:
        re-establishing the existence and validity of the parent-side NS
        RRset of a delegation

     Revalidation point:
        a delegation under revalidation

     Re-delegation:




  Huque, et al.             Expires 22 April 2026                 [Page 4]


  Internet-Draft         DNS Delegation Revalidation          October 2025


        the process of changing a delegation information to another set of
        authoritative name servers, potentially under different
        administrative control

  2.  Motivation

     There is wide variability in the behavior of deployed DNS resolvers
     today with respect to how they process delegation records.  Some of
     them prefer the parent NS set, some prefer the child, and for others,
     what they preferentially cache depends on the dynamic state of
     queries and responses they have processed [SOMMESE].

     While this variability is expected to continue in deployed
     implementations, this document specifies an algorithm that can be
     adopted by resolvers to achieve several benefits.

     It preferentially and predictably prefers the authoritative NS set at
     the apex of the child zone, which better comports with the the DNS
     protocol's data ranking rules.  (Note that the proposed redesign of
     the DNS delegation mechanism in [I-D.ietf-deleg] is expected to
     fundamentally alter where authoritative delegation information will
     reside.  This document deals with the DNS delegation mechanism as
     currently deployed.)

     It offers seeveral security advantages.  The mechanisms described in
     this document help against GHOST domain attacks and a variety of
     cache poisoning attacks with resolvers that adhere to Sections 5.4.1
     (Ranking data) and 6.1 (Zone authority) of [RFC2181].  Strictly
     revalidating referral and authoritative NS RRset responses, enables
     the resolver to defend itself against query redirection attacks, see
     Security and Privacy considerations (Section 9).

     The delegation NS RRset at the bottom of the parent zone and the apex
     NS RRset in the child zone are unsynchronized in the DNS protocol.
     Section 4.2.2 of [RFC1034] says "The administrators of both zones
     should insure that the NS and glue RRs which mark both sides of the
     cut are consistent and remain so.".  But for a variety of reasons
     they could not be [SOMMESE].  Officially, a child zone's apex NS
     RRset is authoritative and thus has a higher cache credibility than
     the parent's delegation NS RRset, which is non-authoritative
     (Sections 5.4.1 (Ranking data) and 6.1 (Zone authority) of
     [RFC2181]).  Hence the NS RRset "below the zone cut" should
     immediately replace the parent's delegating NS RRset in cache when an
     iterative caching DNS resolver crosses a zone boundary.  However,
     this can only happen if (1) the resolver receives the authoritative
     NS RRset in the Authority section of a response from the child zone,
     which is not mandatory, or (2) if the resolver explicitly issues an
     NS RRset query to the child zone as part of its iterative resolution



  Huque, et al.             Expires 22 April 2026                 [Page 5]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     algorithm.  In the absence of this, it is possible for an iterative
     caching resolver to never learn the authoritative NS RRset for a
     zone, unless a downstream client of the resolver explicitly issues
     such an NS query, which is not something that normal end user
     applications do, and thus cannot be relied upon to occur with any
     regularity.

     Increasingly, there is a trend towards minimizing unnecessary data in
     DNS responses.  Several popular DNS implementations default to such a
     configuration (see "minimal-responses" in BIND and NSD).  So, they
     may never include the authoritative NS RRset in the Authority section
     of their responses.

     A common reason that zone owners want to ensure that resolvers place
     the authoritative NS RRset preferentially in their cache is that the
     TTLs may differ between the parent and child side of the zone cut.
     Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
     their delegation NS sets.  This inhibits a child zone owner's ability
     to make more rapid changes to their name server configuration using a
     shorter TTL, if resolvers have no systematic mechanism to observe and
     cache the child NS RRset.

     Similarly, a child zone owner may also choose to have longer TTLs in
     their delegation NS sets and address records to decrease the attack
     window for cache poisoning attacks.  For example, at the time of
     writing, root-servers.net has a TTL of 6 weeks for the root server
     identifier address records, where the TTL in the priming response is
     6 days.

     A zone's delegation still needs to be periodically revalidated at the
     parent to make sure that the parent zone has not legitimately re-
     delegated the zone to a different set of name servers, or even
     removed the delegation.  Otherwise, resolvers that refresh the TTL of
     a child NS RRset on subsequent queries or due to pre-fetching, may
     cling to those name servers long after they have been re-delegated
     elsewhere.  This leads to the second recommendation in this document,
     "Delegation Revalidation" - Resolvers should record the TTL of the
     parent's delegating NS RRset, and use it to trigger a revalidation
     action.  Attacks exploiting lack of this revalidation have been
     described in [GHOST1], [GHOST2].











  Huque, et al.             Expires 22 April 2026                 [Page 6]


  Internet-Draft         DNS Delegation Revalidation          October 2025


  3.  Upgrading NS RRset Credibility

     When a referral response is received during iteration, a validation
     query SHOULD be sent in parallel with the resolution of the
     triggering query, to one of the delegated name servers for the newly
     discovered zone cut.  Note that DNSSEC validating resolvers today,
     when following a secure referral, already need to dispatch a query to
     one of the delegated name servers for the DNSKEY RRset, so this
     validation query could be sent in parallel with that DNSKEY query.

     A validation query consists of a query for the child's apex NS RRset,
     sent to one of the newly discovered delegation's name servers.
     Normal iterative logic applies to the processing of responses to
     validation queries, including storing the results in cache, trying
     the next server on SERVFAIL or timeout, and so on.  Positive
     responses to this validation query MAY be cached with an
     authoritative data ranking.  Successive queries directed to the same
     zone SHOULD be directed to the nameservers listed in the child's
     apex, due to the ranking of this answer.  If the validation query
     fails, the parent NS RRset SHOULD remain the one with the highest
     ranking and SHOULD be used for successive queries.

     A response to the triggering query to the child may contain the NS
     RRset in the authority section as well.  This NS RRset however has a
     lower trustworthiness than the set from the direct query
     (Section 5.4.1 of [RFC2181]), so regardless of the order in which the
     responses are received, the NS RRset from the answer section from the
     direct child's apex NS RRset query MAY be stored in the cache
     eventually.

     When a resolver detects that the child's apex NS RRset contains
     different name servers than the non-authoritative version at the
     parent side of the zone cut, it MAY report the mismatch using DNS
     Error Reporting [RFC9567] on the Report-Channel for the child zone,
     as well as on the Report-Channel for the parent zone, with an
     extended DNS error code of TBD (See Section 8).

     A No Data response (see Section 2.2 of [RFC2308]) for the validating
     NS query should be treated the same as a failed validating NS query.
     The parent NS RRset SHOULD remain the one with the highest ranking
     and SHOULD be used for successive queries.  All resolution failures
     MUST be cached as directed in [RFC9520], to prevent aggressive
     requeries.








  Huque, et al.             Expires 22 April 2026                 [Page 7]


  Internet-Draft         DNS Delegation Revalidation          October 2025


  4.  Limiting upgrading NS Credibility

     Upgrading NS RRset Credibility (Section 3) works most reliable with
     good quality child NS RRsets, where the name servers referenced in
     the RDATA of the NS RRset do result in IP addresses which serve the
     child zone.  We consider both the root, as well as the zones
     delegated from the root, to have good quality child NS RRset, but
     recognize that, because of the less transparently administered
     further delegations (among others by parties that are perhaps less
     devoted to DNS administration), some of those further delegations may
     be sub-optimal for upgrading NS RRset credibility.. An implementation
     MAY limit revalidation to delegations that cross administrative
     boundaries such as anywhere in ".ip6.arpa" and ".in-addr.arpa" as
     well as any so-called "public suffix" such as the root zone, top
     level zones such as ".com" or ".net", and effective top level zones
     such as ".ad.jp" or ".co.uk".

  5.  Upgrading A and AAAA RRset Credibility

  5.1.  Upgrading glue

     Additional validation queries for the "glue" address RRs of referral
     responses (if not already authoritatively present in cache) SHOULD be
     sent with the validation query for the NS RRset as well.  Positive
     responses SHOULD be cached with authoritative data ranking.  The non-
     authoritative "glue" MAY be cached with non-authoritative data
     ranking for fallback purposes.  Successive queries directed to the
     same zone SHOULD be directed to the authoritative nameservers denoted
     in the referral response.

     The names from the NS RRset in a validating NS response may differ
     from the names from the NS RRset in the referral response.
     Outstanding validation queries for "glue" address RRs that do not
     match names in a newly discovered authoritative NS RRset may be
     discarded, or they may be left running to completion.  Their result
     MUST no longer be used in queries for the zone.  Outstanding
     validation queries for "glue" address RRs that do match names in the
     authoritative NS RRset MUST be left running to completion.  They do
     not need to be re-queried after reception of the authoritative NS
     RRset (see Section 5).

     Validated "glue" may result in unreachable destinations if they are
     obtained from poorly managed zones with incorrect address records.  A
     resolver MAY choose to keep the non-authoritative value for the
     "glue" next to the preferred authoritative value for fallback
     purposes.  Such a resolver MAY choose to fallback to use the non-
     authoritative value as a last resort, but SHOULD do so only if all
     other authoritative "glue" led to unreachable destinations as well.



  Huque, et al.             Expires 22 April 2026                 [Page 8]


  Internet-Draft         DNS Delegation Revalidation          October 2025


  5.2.  Upgrading additional address from authoritative NS responses

     Authoritative responses for a zone's NS RRset at the apex can contain
     nameserver addresses in the Additional section.  An NS RRset
     validation response is an example of such a response.  A priming
     response is another example of an authoritative zone's NS RRset
     response [RFC8109].

     When additional addresses in authoritative NS RRset responses are
     DNSSEC verifiable (because the complete RRset is included, including
     a verifiable signature for the RRset) and DNSSEC secure, they MAY be
     cached authoritatively immediately without additional validation
     queries.  DNSSEC validation is enough validation in those cases.
     Otherwise, the addresses cannot be assumed to be complete or even
     authoritatively present in the same zone, and additional validation
     queries SHOULD be made for these addresses.

     Note that there may be outstanding address validation queries for the
     names of the authoritative NS RRset (from referral address validation
     queries).  In those cases no new validation queries need to be made.

  6.  Strict and opportunistic revalidation

  6.1.  Strictly revalidating referrals and authoritative NS RRset
        responses

     Resolvers may choose to delay the response to a triggering query
     until it can be verified that the answer came from a name server
     listening on an authoritatively acquired address for an
     authoritatively acquired name.  This would offer the most trustworthy
     responses with the least risk for forgery or eavesdropping, however
     without fallback to lower ranked NS RRsets and addresses, there is no
     failure mitigation and a failed NS RRset validation query, due to a
     broken child NS RRset or to malfunctioning child zone's authoritative
     servers, will then lead to a hard failure to query the referred to
     child zone.

     If the resolver chooses to delay the response, and there are no
     nameserver names in common between the child's apex NS RRset and the
     parent's delegation NS RRset, then any responses received from
     sending the triggering query to the parent's delegated nameservers
     SHOULD be discarded, and this query should be sent again to one of
     the child's apex nameservers.

     It is RECOMMENDED, to scope *strict* upgrading of NS, A and AAAA
     RRset credibility, to the root zone and zones delegated from the root
     zone only (see Section 4).




  Huque, et al.             Expires 22 April 2026                 [Page 9]


  Internet-Draft         DNS Delegation Revalidation          October 2025


  6.2.  Opportunistic revalidating referral and authoritative NS RRset
        responses

     In practice, we expect many implementations may answer the triggering
     query in advance of the validation query for performance reasons.  An
     additional reason is that there are unfortunately a number of
     nameservers in the field that (incorrectly) fail to properly answer
     explicit queries for zone apex NS records, and thus the revalidation
     logic may need to be applied lazily and opportunistically to deal
     with them.  In cases where the delegated nameservers respond
     incorrectly to an NS query, the resolver SHOULD abandon this
     algorithm for the zone in question and fall back to using only the
     information from the parent's referral response.

     One may consider to only limit _strict_ upgrading of NS, A and AAAA
     RRset credibility to the root zone and zones delegated from the root
     zone, and perform _opportunistic_ revalidations for further
     delegations (see Section 4).

  7.  Delegation Revalidation

     The essence of this mechanism is revalidation of all delegation
     metadata that directly or indirectly supports an owner name in cache.
     This requires a cache to remember the delegated name server names for
     each zone cut as received from the parent (delegating) zone's name
     servers, and also the TTL of that NS RRset, and the TTL of the
     associated DS RRset (if seen).

     A delegation under revalidation is called a "revalidation point" and
     is "still valid" if its parent zone's servers still respond to an in-
     zone question with a referral to the revalidation point, and if that
     referral overlaps with the previously cached referral by at least one
     name server name, and the DS RRset (if seen) overlaps the previously
     cached DS RRset (if also seen) by at least one delegated signer.

     If the response is not a referral or refers to a different zone than
     before, then the shape of the delegation hierarchy has changed.  If
     the response is a referral to the revalidation point but to a wholly
     novel NS RRset or a wholly novel DS RRset, then the authority for
     that zone has changed.  For clarity, this includes transitions
     between empty and non-empty DS RRsets.










  Huque, et al.             Expires 22 April 2026                [Page 10]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     If the shape of the delegation hierarchy or the authority for a zone
     has been found to change, then currently cached data whose owner
     names are at or below that revalidation point MUST NOT be used.  Such
     non-use can be by directed garbage collection or lazy generational
     garbage collection or some other method befitting the architecture of
     the cache.  What matters is that the cache behave as though this data
     was removed.

     Since revalidation can discover changes in the shape of the
     delegation hierarchy it is more efficient to revalidate from the top
     (root) downward (to the owner name) since an upper level revalidation
     may obviate lower level revalidations.  What matters is that the
     supporting chain of delegations from the root to the owner name be
     demonstrably valid; further specifics are implementation details.

     Revalidation MUST be triggered when delegation meta-data has been
     cached for a period at most exceeding the delegating NS or DS (if
     seen) RRset TTL.  If the corresponding child zone's apex NS RRset TTL
     is smaller than the delegating NS RRset TTL, revalidation MUST happen
     at that interval instead.  However, resolvers SHOULD impose a
     sensible minimum TTL floor they are willing to endure to avoid
     potential computational DoS attacks inflicted by zones with very
     short TTLs.

     In normal operations this meta-data can be quickly revalidated with
     no further work.  However, when re-delegation or take-down occurs, a
     revalidating cache SHOULD discover this within one delegation TTL
     period, allowing the rapid expulsion of old data from the cache.

  8.  IANA Considerations

     IANA is requested to assign a value to the "Extended DNS Error Codes"
     registry [RFC8914].

         +===========+============================+=================+
         | INFO-CODE | Purpose                    | Reference       |
         +===========+============================+=================+
         | TBD       | referral NS RRset mismatch | [this document] |
         +-----------+----------------------------+-----------------+

                                   Table 1

  9.  Security and Privacy Considerations








  Huque, et al.             Expires 22 April 2026                [Page 11]


  Internet-Draft         DNS Delegation Revalidation          October 2025


  9.1.  DNSSEC protection of infrastructure data

     Referral response NS RRsets and glue, and the additional addresses
     from authoritative NS RRset responses (such as the root priming
     response), are not protected with DNSSEC signatures.  An attacker
     that is able to alter the unsigned A and AAAA RRsets in the
     additional section of referral and authoritative NS RRset responses,
     can fool a resolver into taking addresses under the control of the
     attacker to be authoritative for the zone.  Such an attacker can
     redirect all traffic to the zone (of the referral or authoritative NS
     RRset response) to a rogue name server.

     A rogue name server can view all queries from the resolver to that
     zone and alter all unsigned parts of responses, such as the parent
     side NS RRsets and glue of further referral responses.  Resolvers
     following referrals from a rogue name server, that do not revalidate
     those referral responses, can subsequently be fooled into taking
     addresses under the control of the attacker to be authoritative for
     those delegations as well.  The higher up the DNS tree, the more
     impact such an attack has.  An attacker controlling a rogue name
     server for the root has potentially complete control over the entire
     domain name space and can alter all unsigned parts undetected.

     Strictly revalidating referral and authoritative NS RRset responses
     (see Section 6), enables the resolver to defend itself against the
     above described attack with DNSSEC signed infrastructure RRsets.
     Unlike cache poisoning defences that leverage increase entropy to
     protect the transaction, revalidation of NS RRsets and addresses also
     provides protection against on-path attacks.

     Since December 6, 2023, the root zone contains a DNSSEC signed
     cryptographic message digest [RFC8976][ROOT-ZONEMD], covering all
     root zone data.  This includes all non-authoritative data such as the
     A and AAAA RRsets for the IP addresses of the root server
     identifiers, as well as the NS RRsets and glue that make up the
     delegations.  A root zone local to the resolver [RFC8806] with a
     verified and validated ZONEMD RRset, would provide protection
     similarly strong to strictly revalidating the root and the top level
     domains.

  9.2.  Cache poisoning protection

     In [DNS-CACHE-INJECTIONS] an overview is given of 18 cache poisoning
     attacks of which 13 can be remedied with delegation revalidation.
     The paper provides recommendations for handling records in DNS
     responses with respect to an earlier version of the idea presented in
     this document [I-D.wijngaards-dnsext-resolver-side-mitigation].




  Huque, et al.             Expires 22 April 2026                [Page 12]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     Upgrading NS RRset Credibility (Section 3) allows resolvers to cache
     and utilize the authoritative child apex NS RRset in preference to
     the non-authoritative parent NS RRset.  However, it is important to
     implement the steps described in Delegation Revalidation (Section 7)
     at the expiration of the parent's delegating TTL.  Otherwise, the
     operator of a malicious child zone, originally delegated to, but
     subsequently delegated away from, can cause resolvers that refresh
     TTLs on subsequent NS set queries, or that pre-fetch NS queries, to
     never learn of the re-delegated zone [GHOST1], [GHOST2].

  9.3.  Other considerations

     Some resolvers do not adhere to Sections 5.4.1 and 6.1 of [RFC2181],
     and only use the non-authoritative parent side NS RRsets and glue
     returned in referral responses for contacting authoritative name
     servers [I-D.fujiwara-dnsop-resolver-update].  As a consequence, they
     are not susceptible to many of the cache poisoning attacks enumerated
     in [DNS-CACHE-INJECTIONS] that are based upon the relative
     trustworthiness of DNS data.  Such resolvers are also not susceptible
     to the GHOST domain attacks [GHOST1], [GHOST2].  Such resolvers will
     however never benefit from DNSSEC protection of infrastructure RRsets
     and are susceptible to query redirection attacks.

     Revalidating referral and authoritative NS RRset responses will
     induce more traffic from the resolver to the authoritative name
     servers.  The traffic increase may be substantial if the address
     RRsets for the names in the NS RRset's RDATA were provided non-
     authoritatively (as glue or as additional addresses) and need
     revalidation too [REDIRECTED-QUERY-TRAFFIC].  Resolvers SHOULD take
     care to limit the amount of work they are willing to do to resolve a
     query to a sensible amount.

  10.  References

  10.1.  Normative References

     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
                STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
                <https://www.rfc-editor.org/info/rfc1034>.

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/info/rfc1035>.

     [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>.



  Huque, et al.             Expires 22 April 2026                [Page 13]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
                Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
                <https://www.rfc-editor.org/info/rfc2181>.

     [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
                NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
                <https://www.rfc-editor.org/info/rfc2308>.

     [RFC8109]  Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
                Resolver with Priming Queries", RFC 8109,
                DOI 10.17487/RFC8109, March 2017,
                <https://www.rfc-editor.org/info/rfc8109>.

     [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>.

     [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
                a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
                <https://www.rfc-editor.org/info/rfc8806>.

     [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
                Lawrence, "Extended DNS Errors", RFC 8914,
                DOI 10.17487/RFC8914, October 2020,
                <https://www.rfc-editor.org/info/rfc8914>.

     [RFC8976]  Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
                Hardaker, "Message Digest for DNS Zones", RFC 8976,
                DOI 10.17487/RFC8976, February 2021,
                <https://www.rfc-editor.org/info/rfc8976>.

     [RFC9520]  Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
                of DNS Resolution Failures", RFC 9520,
                DOI 10.17487/RFC9520, December 2023,
                <https://www.rfc-editor.org/info/rfc9520>.

     [RFC9567]  Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567,
                DOI 10.17487/RFC9567, April 2024,
                <https://www.rfc-editor.org/info/rfc9567>.

  10.2.  Informative References

     [DNS-CACHE-INJECTIONS]
                Klein, A., Shulman, H., and M. Waidner, "Internet-Wide
                Study of DNS Cache Injections", n.d.,
                <https://ieeexplore.ieee.org/abstract/document/8057202>.





  Huque, et al.             Expires 22 April 2026                [Page 14]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     [GHOST1]   Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu,
                "Ghost Domain Names: Revoked Yet Still Resolvable", n.d.,
                <https://www.ndss-symposium.org/ndss2012/>.

     [GHOST2]   Li, X., Liu, B., Bai, X., Zhang, M., Zhang, Q., Li, Z.,
                Duan, H., and Q. Li, "Ghost Domain Reloaded: Vulnerable
                Links in Domain Name Delegation and Revocation", n.d.,
                <https://www.ndss-symposium.org/ndss-paper/ghost-domain-
                reloaded-vulnerable-links-in-domain-name-delegation-and-
                revocation/>.

     [I-D.fujiwara-dnsop-resolver-update]
                Fujiwara, K., "Updating Resolver Algorithm", Work in
                Progress, Internet-Draft, draft-fujiwara-dnsop-resolver-
                update-00, 31 October 2016,
                <https://datatracker.ietf.org/doc/html/draft-fujiwara-
                dnsop-resolver-update-00>.

     [I-D.ietf-deleg]
                April, T., Špaček, P., Weber, R., and Lawrence,
                "Extensible Delegation for DNS", Work in Progress,
                Internet-Draft, draft-ietf-deleg-04, 16 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-deleg-
                04>.

     [I-D.vixie-dnsext-resimprove]
                Vixie, P. A., Joffe, R., and F. Neves, "Improvements to
                DNS Resolvers for Resiliency, Robustness, and
                Responsiveness", Work in Progress, Internet-Draft, draft-
                vixie-dnsext-resimprove-00, 23 June 2010,
                <https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-
                resimprove-00>.

     [I-D.wijngaards-dnsext-resolver-side-mitigation]
                Wijngaards, W., "Resolver side mitigations", Work in
                Progress, Internet-Draft, draft-wijngaards-dnsext-
                resolver-side-mitigation-01, 24 February 2009,
                <https://datatracker.ietf.org/doc/html/draft-wijngaards-
                dnsext-resolver-side-mitigation-01>.

     [REDIRECTED-QUERY-TRAFFIC]
                Toorop, W., Thessalonikefs, Y., Overeinder, B., Müller,
                M., and M. Davids, "The reduced risk of redirected query
                traffic with signed root name server data", n.d.,
                <https://www.icann.org/en/system/files/files/reduced-risk-
                redirected-query-traffic-signed-root-name-server-data-
                22may24-en.pdf#h.8mh7wvmas7vi>.




  Huque, et al.             Expires 22 April 2026                [Page 15]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     [ROOT-ZONEMD]
                Wessels, D., "Root zone operational announcement:
                introducing ZONEMD for the root zone", n.d.,
                <https://lists.dns-oarc.net/pipermail/dns-
                operations/2023-December/022388.html>.

     [SOMMESE]  Sommese, R., Moura, G. C. M., Jonker, M., van Rijswijk-
                Deij, R., Dainotti, A., Claffy, K. C., and A. Sperotto,
                "When parents and children disagree: Diving into DNS
                delegation inconsistency", n.d.,
                <https://par.nsf.gov/servlets/purl/10186683>.

  Appendix A.  Acknowledgements

     Wouter Wijngaards proposed explicitly obtaining authoritative child
     NS data in [I-D.wijngaards-dnsext-resolver-side-mitigation].  This
     behavior has been implemented in the Unbound DNS resolver via the
     "harden-referral-path" option.  The combination of child NS fetch and
     revalidating the delegation was originally proposed in
     [I-D.vixie-dnsext-resimprove], by Paul Vixie, Rodney Joffe, and
     Frederico Neves.

     The authors would like to thank Ralph Dolmans who was an early
     collaborator on this work, as well as the many members of the IETF
     DNS Operations Working Group for helpful comments and discussion.

  Appendix B.  Implementation status

     *Note to the RFC Editor*: please remove this entire appendix before
     publication.

     *  The Unbound resolver software has opportunistic revalidating of
        referral and authoritative NS RRset responses, as described in
        Section 3, Section 5 and Section 6.2 in this document, implemented
        since version 1.1 (released August 29, 2008).  It is enabled with
        a configuration option harden-referral-path: yes which is disabled
        by default.

        "Redhat Enterprise Linux has been running Unbound with the harden-
        referral-path: option set to yes for years without problems", as
        mentioned by Paul Wouters during dnsop workgroup session at the
        IETF 119.

     *  The Knot Resolver software revalidates the priming response as
        part of priming the root zone since version 1.5.1 (released
        December 12, 2017)





  Huque, et al.             Expires 22 April 2026                [Page 16]


  Internet-Draft         DNS Delegation Revalidation          October 2025


     *  Section 7 has been implemented in the Unbound resolver since
        version 1.4.17 (released May 24, 2012).

  Authors' Addresses

     Shumon Huque
     Salesforce
     415 Mission Street, 3rd Floor
     San Francisco, CA 94105
     United States of America
     Email: shuque@gmail.com


     Paul Vixie
     SIE Europe, U.G.
     Email: paul@redbarn.org


     Willem Toorop
     NLnet Labs
     Science Park 400
     1098 XH Amsterdam
     Netherlands
     Email: willem@nlnetlabs.nl



























  Huque, et al.             Expires 22 April 2026                [Page 17]


name: draft-johani-dnsop-transport-signaling
rev: 02
title: Authoritative DNS Transport Signaling
time: 2025-10-20T20:10:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T20:10:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.385098+00:00
source: ietf
source_id: 146592
source_url: https://datatracker.ietf.org/doc/draft-johani-dnsop-transport-signaling/
doc_status: active
abstract:
  This document proposes a mechanism for authoritative DNS servers to
     signal their support for alternative transport protocols (e.g., DNS
     over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)).  This
     signaling may either be provided within the Additional section of
     authoritative DNS responses or be the result of direct DNS queries.

     The former, "opportunistic mode" is hint-based and aims to enable
     resolvers to discover alternative transports efficiently and then
     opportunistically upgrade connections to the authoritative, thereby
     improving privacy, security, and performance for subsequent
     interactions.  The mechanism is designed to not require any protocol
     change or additional queries.  It is safe, backward-compatible, and
     effective even when DNSSEC validation of the hint is not possible or
     desired.

     In certain circumstances and with additional overhead it is also
     possible to use direct queries to securely obtain authentication
     information for the authoritative that can then be used to
     authenticate an encrypted connection.

     It is also possible to establish a "validated mode" where the
     communication between the resolver and the authoritative server is
     provably both secure and authentic.  Validated mode may not always be
     possible, depending on whether the resolver is able to DNSSEC
     validate the signal or not.  When Validated mode is possible it does
     provide a stronger and more trustworthy connection.

     This document proposes an improvement to the opportunistic (but
     blind) testing of alternative transports suggested in RFC9539 by
     providing a mechanism by which a responding authoritative server may
     signal what alternative transports it supports.

     TO BE REMOVED: This document is being collaborated on in Github at:
     https://github.com/johanix/draft-johani-dnsop-transport-signaling
     (https://github.com/johanix/draft-johani-dnsop-transport-signaling).
     The most recent working version of the document, open issues, etc,
     should all be available there.  The authors (gratefully) accept pull
     requests.

full_text:
  DNSOP Working Group                                          J. Stenstam
  Internet-Draft                                              L. Fernandez
  Intended status: Standards Track                            E. Bergström
  Expires: 23 April 2026                   The Swedish Internet Foundation
                                                                P. Homberg
                                                                NLnet Labs
                                                              S. Dickinson
                                                                Sinodun IT
                                                           20 October 2025


                   Authoritative DNS Transport Signaling
                 draft-johani-dnsop-transport-signaling-02

  Abstract

     This document proposes a mechanism for authoritative DNS servers to
     signal their support for alternative transport protocols (e.g., DNS
     over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)).  This
     signaling may either be provided within the Additional section of
     authoritative DNS responses or be the result of direct DNS queries.

     The former, "opportunistic mode" is hint-based and aims to enable
     resolvers to discover alternative transports efficiently and then
     opportunistically upgrade connections to the authoritative, thereby
     improving privacy, security, and performance for subsequent
     interactions.  The mechanism is designed to not require any protocol
     change or additional queries.  It is safe, backward-compatible, and
     effective even when DNSSEC validation of the hint is not possible or
     desired.

     In certain circumstances and with additional overhead it is also
     possible to use direct queries to securely obtain authentication
     information for the authoritative that can then be used to
     authenticate an encrypted connection.

     It is also possible to establish a "validated mode" where the
     communication between the resolver and the authoritative server is
     provably both secure and authentic.  Validated mode may not always be
     possible, depending on whether the resolver is able to DNSSEC
     validate the signal or not.  When Validated mode is possible it does
     provide a stronger and more trustworthy connection.

     This document proposes an improvement to the opportunistic (but
     blind) testing of alternative transports suggested in RFC9539 by
     providing a mechanism by which a responding authoritative server may
     signal what alternative transports it supports.




  Stenstam, et al.          Expires 23 April 2026                 [Page 1]


  Internet-Draft           DNS Transport Signaling            October 2025


     TO BE REMOVED: This document is being collaborated on in Github at:
     https://github.com/johanix/draft-johani-dnsop-transport-signaling
     (https://github.com/johanix/draft-johani-dnsop-transport-signaling).
     The most recent working version of the document, open issues, etc,
     should all be available there.  The authors (gratefully) accept pull
     requests.

  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 23 April 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include 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.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  1.1.  Confidentiality . . . . . . . . . . . . . . . . . .   5
       1.2.  1.2.  Prior Art . . . . . . . . . . . . . . . . . . . . .   5
       1.3.  1.3.  Rationale for Using the Additional Section  . . . .   6
     2.  2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  3.  Modes of Operation  . . . . . . . . . . . . . . . . . . .   7
       3.1.  3.1.  Description of Problem Space  . . . . . . . . . . .   7
         3.1.1.  3.1.1.  Validated Transport Signaling Not Possible  .   8



  Stenstam, et al.          Expires 23 April 2026                 [Page 2]


  Internet-Draft           DNS Transport Signaling            October 2025


         3.1.2.  3.1.2.  Validated Transport Signaling Possible  . . .   8
       3.2.  3.2.  Behaviour of the Two Modes  . . . . . . . . . . . .   8
         3.2.1.  3.2.1.  Opportunistic Mode  . . . . . . . . . . . . .   8
         3.2.2.  3.2.2.  Validated Mode  . . . . . . . . . . . . . . .   9
       3.3.  3.3.  Precedence and Interaction  . . . . . . . . . . . .  10
       3.4.  3.4.  Caching and No-DTS  . . . . . . . . . . . . . . . .  10
       3.5.  3.5.  Summary of Permitted Use by Mode  . . . . . . . . .  10
     4.  4.  The Opportunistic Signaling Mechanism . . . . . . . . . .  11
     5.  5.  Authoritative Nameserver Behaviour  . . . . . . . . . . .  11
       5.1.  5.1.  Trigger Conditions for Including the DTS Hint . . .  11
       5.2.  5.2.  Multiple Server Identities  . . . . . . . . . . . .  12
       5.3.  5.3.  Format of the DNS Transport Signal SVCB Record  . .  12
     6.  6.  Recursive Nameserver Behavior . . . . . . . . . . . . . .  13
       6.1.  6.1.  When Sending Queries  . . . . . . . . . . . . . . .  14
       6.2.  6.2.  When Receiving Responses  . . . . . . . . . . . . .  14
       6.3.  6.3.  Upgrading the DNS Transport Signal  . . . . . . . .  15
       6.4.  6.4.  Authentication of the Authoritative Nameserver  . .  15
       6.5.  6.5.  Resolver Caching Strategies . . . . . . . . . . . .  15
     7.  7.  The EDNS(0) No-DTS Option . . . . . . . . . . . . . . . .  16
     8.  8.  Comparison with DELEG . . . . . . . . . . . . . . . . . .  17
     9.  9.  Security Considerations . . . . . . . . . . . . . . . . .  18
     10. 10.  Operational Considerations . . . . . . . . . . . . . . .  19
     11. 11.  IANA Considerations  . . . . . . . . . . . . . . . . . .  19
       11.1.  11.1.  No-DTS EDNS(0) Option . . . . . . . . . . . . . .  19
       11.2.  11.2.  SVCB/HTTPS Parameter: tlsa  . . . . . . . . . . .  20
       11.3.  11.3.  The New SVCB alpn Token "-do53" . . . . . . . . .  20
     12. 12.  Acknowledgements . . . . . . . . . . . . . . . . . . . .  20
     13. Appendix A.  Rationale for Using the Additional Section . . .  21
       13.1.  A.1.  Opportunistic Mode Via the Additional Section  . .  21
       13.2.  A.2.  Validated Mode Via the Additional Section  . . . .  21
     14. Appendix B.  SVCB ALPN Negative Tokens  . . . . . . . . . . .  22
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  22
       15.2.  Informative References . . . . . . . . . . . . . . . . .  23
     Appendix A.  Change History (to be removed before publication)  .  23
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  1.  Introduction

     The Domain Name System (DNS) primarily relies on UDP and TCP for
     communication between resolvers and authoritative servers.  While
     these protocols are well-established, there is a growing interest in
     leveraging modern transport protocols like DNS over TLS (DoT)
     [RFC7858], DNS over HTTPS (DoH) [RFC9461] and DNS over QUIC (DoQ)
     [RFC9250] to enhance privacy, security, and performance.






  Stenstam, et al.          Expires 23 April 2026                 [Page 3]


  Internet-Draft           DNS Transport Signaling            October 2025


     Clients of authoritative servers (recursive resolvers) may employ
     various policies (usage profiles) when attempting to connect to an
     authoritative.  Two policies are described for the stub to recursive
     case in RFC8310, Strict and Opportunistic which are also applicable
     here:

     *  Strict mode relies on the client having securely discovered
        authentication information (e.g. a name or SPKI) for the server
        and then choosing to hard fail if an authenticated encrypted
        connection cannot be established.  This protects against active
        attack on the resulting connection (however a denial-of-service
        attack is possible).

     *  Opportunistic mode ([RFC7435]) starts with cleartext as a baseline
        with upgrade to encrypted transport and authentication of the
        connection when available.  This is a best effort attempt to set
        up an encrypted DNS transport connection.  This can provide
        enhanced privacy against a passive attacker.  However an active
        attacker may be able to force a downgrade to unencrypted DNS.

     Opportunistic mode can proceed based on, for example, probing of
     server capabilities (as in [RFC9539]) however a mechanism to signal
     such capabilities has a number of advantages.

     Existing efforts to signal service connection information, such as
     the SVCB and HTTPS DNS records [RFC9460] [RFC9461], primarily focus
     on service discovery mechanisms where a client explicitly queries for
     these records, often from a parent zone.  While robust, this approach
     can introduce additional latency and requires explicit configuration
     at the parent zone level.

     This document proposes a new hint-based "DNS Transport Signaling"
     (DTS) mechanism.  DTS, aka an "DTS Hint" allows an authoritative DNS
     nameserver to directly convey its transport capabilities as a hint
     within the Additional section of responses to queries where it
     identifies itself as an authoritative nameserver for the requested
     zone.  This direct, in-band signaling provides a low-latency
     discovery path, even when a formal, validated signal is not
     available.  Furthermore, this is achieved without any changes to the
     DNS Protocol.











  Stenstam, et al.          Expires 23 April 2026                 [Page 4]


  Internet-Draft           DNS Transport Signaling            October 2025


     The information conveyed by this hint alone signals only the
     capabilities of the authoritative nameserver serving the zone.  It
     does not, therefore, establish a full chain of trust directly to the
     zone itself and should be considered as insecure.  It should not be
     used as a basis of a Strict policy, only to enable Opportunistic
     transport.  However, receiving such a signal enables resolvers to
     immediately attempt to establish an opportunistically encrypted
     connection to the resolver without further queries being required.

     The focus of this document is the hint-based signaling of transport
     capabilities, however Section 6.2 outlines in detail the specific
     requirements for how DNSSEC signed authoritatives can provide, and
     willing resolvers can directly query for, a set of records than can
     securely provide authentication information for an authoritative
     nameserver that a resolver could then use to implement a Strict usage
     policy.

  1.1.  1.1.  Confidentiality

     The above text discusses discovery of transport signals and
     authentication information in queries made by the recursive resolver.
     Those queries may or may not occur over encrypted or authenticated
     connections.  Only when all the connections are authenticated are all
     the queries protected from active surveillance.  If all the
     connections are opportunistically encrypted then the queries are
     protected from passive surveillance.  Otherwise they may occur in
     cleartext, or a combination of circumstances may exist.

     Such queries leak the name of the zone that the resolver wishes to
     ultimately query which in itself can be sensitive.  During the early
     stages of the incremental rollout of technologies such as recursive
     to authoritative encrypted connections it is unlikely that fully
     confidential discovery will be possible due to the nature of the DNS
     hierarchy.  However, if large TLDs and/or those hosted by large CDNs
     support encrypted transports a significant number of queries from
     busy resolvers to discovery information on TLD child zones (and
     below) could be performed confidentially thereby greatly improving
     the privacy over the current situation.

  1.2.  1.2.  Prior Art

     An attempt at utilizing more modern, and in particular, more private
     transports between resolvers and authoritative nameservers was
     introduced in [RFC9539].  The idea there was to opportunistically try
     to send the query to the authoritative nameserver over multiple
     transports with no prior knowledge of whether a transport was
     supported in the receiving end or not.




  Stenstam, et al.          Expires 23 April 2026                 [Page 5]


  Internet-Draft           DNS Transport Signaling            October 2025


     The drawback with that approach is that without any significant
     deployment of authoritative support the resolver end will mostly
     spend cycles and traffic on a wasted effort.  For this reason their
     deployment has been limited.

     Furthermore, in Appendix B of [RFC9539] requirements for improving
     the defense against an active attacker are listed.  The first
     requirement is:

     *  A signaling mechanism that tells the recursive resolver that the
        authoritative server intends to offer authenticated encryption.

     This document aims to provide exactly such a mechanism while staying
     within the current DNS protocol.  Therefore the DNS transport
     signaling provided will be hint-based, and as such fit well as an
     improvement to [RFC9539].

  1.3.  1.3.  Rationale for Using the Additional Section

     See Appendix A for the rationale for using the Additional section for
     the transport signaling hint.

  2.  2.  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.

     *  *Authoritative Nameserver (Auth Server):* A DNS server that holds
        the authoritative zone data for a specific domain.

     *  *Recursive Nameserver (Resolver):* A DNS server that processes
        user queries, performing iterative lookups to authoritative
        servers to resolve domain names.

     *  *DTS Hint:* An SVCB record included in the Additional section of
        an authoritative DNS response, intended to signal the responding
        authoritative nameserver's transport capabilities.

     *  *SVCB Record:* Service Binding record, as defined in [RFC9460].









  Stenstam, et al.          Expires 23 April 2026                 [Page 6]


  Internet-Draft           DNS Transport Signaling            October 2025


  3.  3.  Modes of Operation

     This document describes a mechanism of DNS transport signaling
     intended to result in improved communication between the resolver and
     the authoritative nameserver.  This DNS transport signal is provided
     via an SVCB record that describes the transport capabilities of the
     authoritative server.

     In the easiest case the resolver will be able to communicate securely
     with the authoritative server using an encrypted channel (like DoQ or
     DoT), but the resolver does not have the identity of the
     authoritative server proven.  This is referred to as "opportunistic
     mode" and is essentially equivalent to the communication used today
     over UDP/TCP with the addition of privacy.

     The second level of communication is when the resolver is able to
     verify the identity of the authoritative server via validation of a
     DNSSEC signature over the DNS transport signal (which is contained in
     an SVCB record).  This is referred to as "validated mode" and is
     equivalent to the opportunistic mode plus knowledge that the DNS
     transport signal provably describes the authoritative server that the
     resolver is communicating with.

     In opportunistic mode, the authoritative server and the recursive
     resolver make a best effort attempt to set up an encrypted DNS
     transport connection.  This provides enhanced privacy against a
     passive attacker.  However an active attacker may be able to force a
     downgrade to unencrypted DNS.

  3.1.  3.1.  Description of Problem Space

     This section looks at the various configurations that need to be
     supported.

     For opportunistic mode to be possible, the authoritative server needs
     to provide the recursive resolver with the DNS transport signaling
     record even when the recursive resolver does not explicitly ask for
     it (i.e. as a hint, in the Additional Section).  For example by
     adding it to the result of an A or AAAA query for a name server.  The
     recursive resolver accepts such a record and uses it to set up a
     secure transport.

     There are three zones that matter in this analysis: the parent zone,
     the child zone, and the zone that contains the name server addresses
     and transport signaling records.  Note that the name server addresses
     may be located in the child zone.  And some of the three zones may be
     served by the same name server.




  Stenstam, et al.          Expires 23 April 2026                 [Page 7]


  Internet-Draft           DNS Transport Signaling            October 2025


     The parent zone contains the delegation NS RRset for the child which
     is not DNSSEC signed.  Therefore it does not matter if the parent
     zone is DNSSEC signed or not in terms of validating the child’s NS
     RRset.

     For the child zone there are also two possibilities, the child zone
     is DNSSEC secure or not.

     For the nameserver transport signaling there are two possibilities:
     either the zone that holds the nameserver information is DNSSEC
     secure or it is DNSSEC insecure (i.e. the signaling needs to be
     learned opportunistically and later possibly be validated by direct
     query to the SVCB owner name).

  3.1.1.  3.1.1.  Validated Transport Signaling Not Possible

     There are cases where validated transport signaling is unavailable.
     One case is when the zone that holds the nameserver records is not
     DNSSEC secure.  In that case obtaining transport signaling in a
     validated way is not possible without additional trust.

     Another case is where the parent zone does not provide a path that
     allows validating the child’s NS RRset and the child zone is not
     DNSSEC secure.  In that case obtaining a list of the child's
     nameservers in a validated way is impossible.

  3.1.2.  3.1.2.  Validated Transport Signaling Possible

     The remaining cases can be analysed as follows.

     If the zone that holds the nameserver records is DNSSEC secure then
     it is often sufficient if the nameserver adds DNS transport signaling
     along with an A or AAAA response (including signatures).

     If no signed signaling is received opportunistically then the
     resolver SHOULD issue an explicit query for the SVCB RRset at the
     SVCB owner name (_dns.{nameserver FQDN}) to obtain a validated signal
     or a secure denial of existence.

  3.2.  3.2.  Behaviour of the Two Modes

  3.2.1.  3.2.1.  Opportunistic Mode

     Opportunistic mode applies when the DTS Hint (the SVCB record) for
     the authoritative nameserver is received opportunistically in the
     Additional section as part of the response to a DNS query for
     something else.  The hint may or may not be DNSSEC-signed and may or
     may not be successfully validated by the resolver.



  Stenstam, et al.          Expires 23 April 2026                 [Page 8]


  Internet-Draft           DNS Transport Signaling            October 2025


  3.2.1.1.  Behavior:

     *  If the SVCB record and its signatures are DNSSEC-validated, the
        resolver MAY treat it equivalently to Validated mode for the
        corresponding data.

     *  If the SVCB record is not validated (e.g., unsigned, or validation
        fails), then:

        -  The resolver MAY use only positive "alpn" entries to attempt a
           transport upgrade (e.g., dot, doq).

        -  The resolver MUST ignore the negative transport signal "-do53",
           if present.

        -  The resolver MUST ignore ipv4hint, ipv6hint, tlsa, and any
           other parameters that affect addressing or authentication.

        -  The resolver MUST be prepared to immediately fall back to
           traditional UDP/TCP (Do53) upon failure or timeout.

  3.2.1.2.  Rationale:

     *  Opportunistic mode enables low-latency discovery without requiring
        changes at parent zones or prior configuration, while containing
        risk by limiting use of unvalidated data to only positive upgrade
        attempts.

  3.2.2.  3.2.2.  Validated Mode

     Validated mode applies when the resolver explicitly queries for the
     SVCB RRset at the SVCB owner name for the nameserver (i.e.,
     _dns.{nameserver FQDN}) and obtains a DNSSEC-signed response that is
     successfully validated to the appropriate trust anchor.

  3.2.2.1.  Requirements and behavior:

     *  The resolver MUST issue a direct query for the SVCB RRset at
        _dns.{nameserver FQDN}.

     *  The resolver MUST successfully DNSSEC-validate the SVCB RRset and
        its RRSIGs.

     *  When validated, the resolver MAY use all fields of the SVCB RDATA
        for connection establishment and policy decisions, including:

        -  alpn: positive transport signals (e.g., dot, doq) and the
           negative transport signal "-do53" (if present).



  Stenstam, et al.          Expires 23 April 2026                 [Page 9]


  Internet-Draft           DNS Transport Signaling            October 2025


        -  ipv4hint / ipv6hint: address hints for the authoritative
           nameserver.

        -  tlsa: a new SVCB parameter defined by this document that
           conveys the TLSA record to authenticate TLS/QUIC connections to
           the authoritative nameserver.

     *  If a validated SVCB contains the explicit negative transport
        signal "-do53", the resolver SHOULD honor it.  The "-do53" signal
        indicates that legacy UDP/TCP is NOT supported by this
        authoritative nameserver and the resolver SHOULD attempt only
        other advertised transports (if any).  If all transport
        alternatives fail in the validated case the resolver SHOULD treat
        that server as unreachable and prefer other authoritative servers
        for the zone.

  3.3.  3.3.  Precedence and Interaction

     *  Validated transport signals MUST take precedence over
        Opportunistic transport signals.

     *  A validated Opportunistic transport signal is equivalent to a
        Validated transport signal for policy and usage purposes.

     *  An Opportunistic (unvalidated) transport signal MUST NOT be used
        to enforce negative transport policy ("-do53"), alter addressing
        ("ipv4hint/ipv6hint"), or bootstrap authentication material
        ("tlsa").

  3.4.  3.4.  Caching and No-DTS

     *  Resolvers MAY cache Validated-mode SVCB information according to
        its TTL and MAY use the EDNS(0) No-DTS option to avoid redundant
        hints when sufficient information is cached.

     *  In Opportunistic mode, resolvers MAY cache positive "alpn" results
        subject to local policy (see Resolver Caching Strategies).  When a
        resolver has sufficient cached information, it SHOULD set No-DTS
        to reduce response size and limit unnecessary hints.

  3.5.  3.5.  Summary of Permitted Use by Mode

     *  Opportunistic:

        -  MAY use: alpn: "doq", "dot", "h2" and "h3" only.

        -  MUST NOT use: alpn: "-do53", ipv4hint, ipv6hint, tlsa, or any
           parameter that affects addressing or authentication.



  Stenstam, et al.          Expires 23 April 2026                [Page 10]


  Internet-Draft           DNS Transport Signaling            October 2025


        -  MUST support fallback to do53 (i.e. UDP/TCP).

     *  Validated:

        -  MAY use: alpn: "doq", "dot", "h2", "h3", "-do53", ipv4hint,
           ipv6hint, tlsa, and other defined parameters.

     Implementation note: - Existing resolvers that do not understand the
     alpn="-do53" token or the new "tlsa" parameter will ignore them and
     remain interoperable.  Clients implementing this specification MUST
     follow the above mode-dependent processing and precedence rules.

  4.  4.  The Opportunistic Signaling Mechanism

     The core of this proposal is for an authoritative nameserver to
     include a DNS transport signal in the form of an SVCB record in the
     Additional section of its responses under specific conditions.

     This consists of three parts.  The first two are the behaviour of the
     authoritative nameserver receiving the query and the behaviour of the
     recursive nameserver receiving the response.  The final part is a new
     EDNS(0) option that defines an OPT-OUT capability.

  5.  5.  Authoritative Nameserver Behaviour

  5.1.  5.1.  Trigger Conditions for Including the DTS Hint

     An authoritative nameserver SHOULD include an DTS Hint when _all_ of
     the following conditions are met:

     1.  *Self-Identification:* The responding authoritative own Fully
         Qualified Domain Name (FQDN) (or one of its configured aliases/
         identities) is found within the NS RRset for the queried zone.

     2.  *Transport Capability:* The responding authoritative nameserver
         supports one or more alternative transport protocols (e.g., DoT,
         DoH, DoQ) and is configured to advertise these capabilities.  Or
         the nameserver does not (temporarily or permanently) support DNS
         over legacy UDP/TCP transport and is configured to advertise this
         fact.

     3.  *SVCB not present in Answer:* If the SVCB record is present in
         the Answer section (because it was explicitly queried for), then
         it does not have to be included again in the Additional section,
         regardless of whether the resolver has set the DTS Option or not.






  Stenstam, et al.          Expires 23 April 2026                [Page 11]


  Internet-Draft           DNS Transport Signaling            October 2025


  5.2.  5.2.  Multiple Server Identities

     An authoritative nameserver may be known by multiple FQDNs (e.g.,
     ns1.example.com, dns.customer.org, ns.cdnprovider.net).  To
     facilitate condition 1 ("Self-Identification"), authoritative server
     implementations MAY include a configuration mechanism (e.g., an
     identities list) where operators can list FQDNs by which the server
     is known.  This allows the server to correctly identify itself
     regardless of the specific name used in the NS RRset.

  5.3.  5.3.  Format of the DNS Transport Signal SVCB Record

     The DTS Hint MUST be an SVCB record with the following
     characteristics:

     *  *OWNER:* The owner name of the SVCB record MUST be the label
        "_dns" followed by the FQDN of the authoritative nameserver
        itself, as identified in the NS RRset that triggered its inclusion
        (e.g., _dns.ns.dnsprovider.com.).

     *  *CLASS:* IN (Internet).

     *  *TYPE:* SVCB.

     *  *TTL:* The TTL of the SVCB record SHOULD be chosen by the
        authoritative server operator.  Choice of TTL is a local
        configuration decision, but unless the supported transports are
        subject to frequent change a value on the order of 24h or more is
        suggested.

     *  *SVCB_PRIORITY:* 1.  The specific priority value is not critical
        for this hint mechanism, but 1 indicates the highest priority for
        the service.

     *  *SVCB_TARGET:* . (root).  This indicates that the DNS transport
        capabilities described by the SVCB record refer to the owner name
        of the record.

     *  *SVCB_PARAMS:* A set of Service Parameters indicating the
        supported transport protocols.  This document uses the "alpn"
        parameter [RFC9460] for signaling DoT (alpn=dot) and DoQ
        (alpn=doq).  It further defines the new alpn parameter token
        "-do53" for signaling lack of support for UDP/TCP.  Resolvers MUST
        treat "-do53" as actionable only when the SVCB RRset has been
        DNSSEC-validated (Validated mode).






  Stenstam, et al.          Expires 23 April 2026                [Page 12]


  Internet-Draft           DNS Transport Signaling            October 2025


        The SVCB parameters "ipv4hint" and "ipv6hint" MAY be included.
        Resolvers MUST use these address hints only when the SVCB RRset
        has been successfully validated (Validated mode).

        A new "tlsa" SVCB parameter contains the corresponding TLSA record
        for the certificate used to secure a DoQ or DoT transport.
        Resolvers MUST use "tlsa" only when the SVCB RRset has been
        successfully validated (Validated mode).

        If any other parameter is present in the SVCB parameter list it
        must be ignored by the resolver.

     *Example 1:*

     If ns.dnsprovider.net. responds to a query for www.example.com. (in
     the unsigned zone example.com.) and ns.dnsprovider.net is listed in
     the NS RRset for example.com., it may respond with a DNS message that
     contains: ~~~ Header: ...

     Answer: www.example.com.  IN A 1.2.3.4

     Authority: example.com.  IN NS ns1.example.com. example.com.  IN NS
     ns.dnsprovider.net.

     Additional: ns.dnsprovider.net.  IN A 5.6.7.8 ns.dnsprovider.net.  IN
     RRSIG A ... _dns.ns.dnsprovider.net.  IN SVCB 1 . "alpn=doq,dot,do53"
     _dns.ns.dnsprovider.net.  IN RRSIG SVCB ... ~~~

     *Example 2:* The resolver explicitly asks for the DNS transport
     signal for the authoritative nameserver ns.dnsprovider.net. by
     querying for "_dns.ns.dnsprovider.net.  SVCB": ~~~ Header: ...

     Answer: _dns.ns.dnsprovider.net.  IN SVCB 1 . (alpn="doq,dot,-do53",
     tlsa="...") _dns.ns.dnsprovider.net.  IN RRSIG SVCB ...

     Additional: ~~~ Because the resolver uses Validated mode (by querying
     for the SVCB record at _dns.{nameserver FQDN} and validating the
     response) all data in the received SVCB record MAY be used.  In this
     case that includes the negative transport signal "-do53", which will
     effectively turn off UDP/TCP use by the resolver for communicating
     with this particular authoritative nameserver.

  6.  6.  Recursive Nameserver Behavior

     Recursive nameservers adopting this mechanism SHOULD implement the
     following logic:





  Stenstam, et al.          Expires 23 April 2026                [Page 13]


  Internet-Draft           DNS Transport Signaling            October 2025


  6.1.  6.1.  When Sending Queries

     1.  *OPT-OUT Possibility:* If the resolver already thinks that it
         knows the transport capabilities of the authoritative nameserver
         it is about to send a query to it may opt out from DNS transport
         signaling by including an EDNS(0) "No-DTS" option in the query.

         It is important to be aware that using the No-DTS option
         consistently will make the resolver blind to any changes in the
         transport signals, which is clearly not acceptable.  Hence any
         use of "No-DTS" should be restricted to only be used within the
         TTL of an already received and parsed DTS Hint.

  6.2.  6.2.  When Receiving Responses

     1.  *Opportunistic Parsing:* When receiving an authoritative DNS
         response, the resolver SHOULD parse the Additional section for
         SVCB records.

     2.  *Owner Check:* If an SVCB record is found whose owner name
         matches the "_dns" label followed by an authoritative nameserver
         name for the zone to which the query belongs, the resolver MAY
         consider this an DTS Hint.

     3.  *DNSSEC Validation (Optional but Recommended):*

         *  The resolver SHOULD attempt to DNSSEC validate the DTS Hint.
            This involves validating the SVCB record itself and its
            corresponding RRSIG (if present) against the DNSSEC chain of
            trust for the zone that owns the SVCB record (e.g.,
            dnsprovider.com for _dns.ns.dnsprovider.com).

         *  If validation succeeds: The DTS Hint is considered a *trusted
            signal*. The resolver MAY then use all the transport signals
            provided in the SVCB record when deciding on alternative
            transport choices for subsequent queries to that specific
            authoritative nameserver.

         *  If validation fails, or no RRSIG is present: The DTS Hint MUST
            be treated as an *unvalidated hint*. The resolver MAY still
            opportunistically attempt to use the signaled alternative
            transports, but MUST be prepared for immediate fallback to
            traditional transports (UDP/TCP) if the connection fails.
            This is particularly relevant for scenarios like vanity names
            (e.g., ns.customer.com where customer.com is an unsigned zone,
            but the underlying server ns.dnsprovider.com is capable).





  Stenstam, et al.          Expires 23 April 2026                [Page 14]


  Internet-Draft           DNS Transport Signaling            October 2025


     4.  *Prioritization:* * Any DNSSEC-validated SVCB record found via
         explicit query (e.g., _dns.ns.example.com for a queried domain)
         MUST take precedence over any unvalidated DTS Hint.

     *  The DTS Hint is a mechanism to _discover_ capabilities
        opportunistically, not to override trusted delegation or service
        configuration.

     1.  Fallback: Resolvers MUST always be prepared to fall back to
         traditional UDP/TCP transport if an attempt to use an alternative
         transport based on an DTS Hint (especially an unvalidated one)
         fails or times out.

  6.3.  6.3.  Upgrading the DNS Transport Signal

     If an unvalidated opportunistic transport signal has been received
     the resolver may choose to upgrade that signal, either immediately or
     when the transport signal is close to expiration from the resolver
     cache.  An upgraded transport signal allows the resolver to operate
     in Validated mode, and then use all the information in the SVCB
     record (including "-do53", ipv4hint/ipv6hint, and tlsa).

  6.4.  6.4.  Authentication of the Authoritative Nameserver

     Authentication of the authoritative nameserver is not an explicit
     goal in opportunistic mode.  The reason is that as an opportunistic
     mechanism it will not always be possible to do such authentication.

     However, even without strong authentication of the authoritative
     server the proposed mechanism still provides benefits (privacy,
     potential performance improvements) and for that reason cryptographic
     verification of the server identity is not a requirement.

     In validated mode authentication of the authoritative nameserver is
     done by validation of the DNSSEC RRSIG over the SVCB record
     containing the DTS Hint.

     Finally, validating the server cert against a list of well-known
     public Certificate Authorities is possible, but there is no
     standardized way to determine which CAs are appropriate for DNS
     server certificates.

  6.5.  6.5.  Resolver Caching Strategies

     Resolvers implementing the DNS DTS Hint mechanism have several
     options for caching the transport signals received via DTS Hints.





  Stenstam, et al.          Expires 23 April 2026                [Page 15]


  Internet-Draft           DNS Transport Signaling            October 2025


     A suggested primary strategy is to set the EDNS(0) No-DTS option when
     no transport signaling information is needed.  This may be because
     the resolver already knows the authoritative nameserver's transport
     capabilities from a previous response (with a TTL that has not
     expired) or for some other reason.

     The primary caching strategy SHOULD be "Standard DNS Cache", i.e.
     treat the SVCB record like any other DNS record, caching it according
     to its TTL.  This is the simplest approach and will simply cause the
     resolver to fall back to UDP for one query if the transport signal
     data has expired.

     For a more detailed analysis of possible caching logic, see
     [RFC9539], section 4.

     Note that the resolver always has the option of not using the EDNS(0)
     No-DTS option whenever the cache entry is getting close to expiry.

     Given the variety of deployment scenarios and operational
     requirements, this document does not mandate a specific caching
     strategy.  Implementers SHOULD choose a strategy that best fits their
     operational needs, considering factors such as:

     *  The importance of minimizing connection attempts

     *  The impact of failed connection attempts

     *  The computational cost of different caching strategies

     *  The memory requirements of maintaining cache state

     The chosen strategy SHOULD be documented in the implementation's
     configuration options to allow operators to make informed decisions
     about its use.

  7.  7.  The EDNS(0) No-DTS Option

     To provide a mechanism for resolvers to explicitly opt out of
     receiving transport signals, this document defines a new EDNS(0)
     option called "No-DTS".  When included in a query, this option
     signals to the authoritative server that the resolver does not want
     to receive any transport signals in the response.

     The typical use case is to set the EDNS(0) No-DTS option when the
     resolver already has the transport information it needs.

     The EDNS(0) No-DTS option is structured as follows:




  Stenstam, et al.          Expires 23 April 2026                [Page 16]


  Internet-Draft           DNS Transport Signaling            October 2025


                                                   1   1   1   1   1   1
           0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |                            OPTION-CODE                        |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: |                           OPTION-LENGTH                       |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     Field definition details:

     OPTION-CODE: 2 octets / 16 bits (defined in [RFC6891]) contains the
     value TBD for No-DTS.

     OPTION-LENGTH: 2 octets / 16 bits (defined in [RFC6891]) contains the
     length of the payload in octets.  For the No-DTS option, this value
     MUST be 0 as there is no payload.

     When an authoritative server receives a query containing the EDNS(0)
     No-DTS option, it SHOULD NOT include any DTS Hints in the response,
     regardless of whether it would normally do so based on the conditions
     described in Section 5.1.

     This option provides a clean way for resolvers to opt out of
     receiving transport signals, which may be useful in scenarios where:

     *  The resolver has recently established transport preferences for a
        particular authoritative server and that transport signal has not
        expired.

     *  The resolver does not support or does not want to use alternative
        transports

     *  The resolver wants to minimize response sizes

     *  The resolver is operating in an environment where transport
        signals are not needed or desired

     The No-DTS option is designed to be a simple, lightweight mechanism
     that can be used to disable transport signaling without affecting the
     normal operation of DNS resolution.

  8.  8.  Comparison with DELEG

     The idea to use an SVCB alpn parameter for transport signaling
     originated with the work on DELEG [I-D.draft-ietf-deleg].  The
     current document uses the same data format, but as an opportunistic
     addition to the Additional section rather than as integral part of a
     changed delegation mechanism.



  Stenstam, et al.          Expires 23 April 2026                [Page 17]


  Internet-Draft           DNS Transport Signaling            October 2025


     Both mechanisms have distinct use cases, and pros and cons.  The
     major advantage of the DELEG mechanism is that it cannot be spoofed
     or filtered, as it is an integral part of an upcoming protocol
     change.

     The opportunistic mechanism described here has the major advantage of
     being available immediately without any changes to the DNS protocol.
     Furthermore, as it is a signal directly from an authoritative
     nameserver, a single DTS Hint may allow the recipient recursive
     nameserver to upgrade the transport used for all the zones served by
     that authoritative nameserver (which may be millions) without the
     need to make any changes to the zones, nor to the parent zones.

     Given the current DNS landscape with a limited number of very large
     providers of authoritative DNS service and a limited number of large
     providers of recursive DNS service the opportunistic model described
     here has the potential of enabling upgrading the transport for a
     significant fraction of the DNS traffic with a limited amount of
     effort.

  9.  9.  Security Considerations

     *  *Spoofing of Unvalidated Hints:* An DTS Hint that cannot be DNSSEC
        validated (e.g., for ns.example.com where example.com is unsigned)
        is susceptible to spoofing by an on-path attacker.  Such an
        attacker could insert a fake SVCB record advertising a non-
        existing transport, thereby denying connection over that
        transport.  However, since the hint is opportunistic and not
        required for DNS resolution, the worst-case scenario is that the
        resolver attempts a connection that fails and then falls back to
        traditional transports.  Security for the actual DNS data remains
        unaffected.  The cryptographic validation of TLS/QUIC (via X.509
        certificates) for DoT/DoQ would still protect the integrity and
        privacy of the connection itself.

     *  *DNSSEC Validation:* When a DTS Hint is signed by DNSSEC (e.g.,
        the ns.dnsprovider.net SVCB record from a signed dnsprovider.net
        zone), it provides a trusted signal.  Resolvers SHOULD leverage
        DNSSEC validation to distinguish between trusted and unvalidated
        hints.

     *  *No New Attack Vectors:* This mechanism does not introduce new
        attack vectors for DNS data itself, as it primarily concerns
        transport discovery.  It relies on the existing security
        properties of DoT, DoH and DoQ for actual session security.






  Stenstam, et al.          Expires 23 April 2026                [Page 18]


  Internet-Draft           DNS Transport Signaling            October 2025


     *  *Safe Rollout:* As existing recursive nameservers carefully avoid
        data in the Additional section that they do not need, the DTS Hint
        will be ignored by everyone except recursive nameservers that
        understand the DTS Hint.

     *  *No-DTS enables a downgrade attack:* If an attacker is able to
        inject a No-DTS option to an outbound query then no transport
        signal will be provided.  However, this is a consequence of the
        opportunistic nature of the DTS Hint and not worse than not being
        able to do transport signaling at all.

  10.  10.  Operational Considerations

     *  *Response Size:* Including an SVCB record in the Additional
        section will increase the size of UDP responses.  Authoritative
        server operators should consider the potential for UDP
        fragmentation or TCP fallback if responses become excessively
        large, though a single SVCB record is typically small.  Recursive
        nameservers should usually set the EDNS(0) No-DTS when they
        already have the transport signaling information.

     *  *Server Configuration:* Authoritative server implementations will
        need configuration options to enable this feature and manage the
        identities list.

     *  *Rollout Strategy:* This mechanism supports a gradual rollout.
        Authoritative servers can begin sending hints without requiring
        changes from resolvers, and resolvers can begin processing hints
        without requiring all authoritative servers to implement the
        feature.

     *  *Monitoring:* As there is extremely limited data on effects of
        alternative DNS transports for communication resolver to
        authoritative nameserver it is strongly suggested that monitoring
        (of use, resource consumption, etc) is considered.

  11.  11.  IANA Considerations

  11.1.  11.1.  No-DTS EDNS(0) Option

     This document defines a new EDNS(0) option, entitled "No-DTS",
     assigned a value of TBD in the "DNS EDNS0 Option Codes" registry.

     +-------+--------------------------+----------+----------------------+
     | Value | Name                     | Status   | Reference            |
     +-------+--------------------------+----------+----------------------+
     | TBD   | No-DTS                   | Standard | ( This document )    |
     +-------+--------------------------+----------+----------------------+



  Stenstam, et al.          Expires 23 April 2026                [Page 19]


  Internet-Draft           DNS Transport Signaling            October 2025


     *Note to the RFC Editor*: In this section, please replace occurrences
     of "(This document)" with a proper reference.

  11.2.  11.2.  SVCB/HTTPS Parameter: tlsa

     This document requests registration of a new SVCB/HTTPS parameter in
     the "SVCB and HTTPS Parameters" registry:

        +-------+--------+--------------------+----------------------+
        | Key   | Name   | Meaning            | Reference            |
        +-------+--------+--------------------+----------------------+
        | TBD   | tlsa   | Carries TLSA data  | ( This document )    |
        +-------+--------+--------------------+----------------------+

     Presentation and wire format: The value carries one or more TLSA RRs
     associated with the nameserver endpoint.  Exact encoding and size
     limits are defined by this document (TBD).  Use of this parameter is
     appropriate only when the containing SVCB RRset is DNSSEC-validated
     (see Section 3).

  11.3.  11.3.  The New SVCB alpn Token "-do53"

     This document updates the "alpn" SVCB parameter with one additional
     token, "-do53", used to signal lack of support for UDP/TCP, i.e. a
     negative transport capability.  Note that at present support for UDP/
     TCP is required for authoritative nameservers.

     The "-do53" token has two use cases.  The first is for temporary
     service interruptions (i.e. a busy nameserver that only supports UDP/
     TCP transport may signal alpn="-do53" prior to being offline for
     maintenance).  The second is for a future where a significant
     fraction of authoritative DNS traffic has migrated to encrypted
     transports and it may be reasonable to not support every transport at
     every nameserver.

     IANA is requested to add the "-do53" token to the list of defined
     tokens for the "SVCB and HTTPS Parameters" registry entry for "alpn"
     and reference this document.  A new ALPN ID must be allocated for
     "-do53".

  12.  12.  Acknowledgements

     *  Many people have commented and contributed to this document in
        different ways.  In no particular order and with a significant
        risk of forgetting someone: The participants of the DELEG Working
        Group, Peter Thomassen, Christian Elmerot, John Todd, Peter Koch,
        Willem Toorop, Peter van Dijk.




  Stenstam, et al.          Expires 23 April 2026                [Page 20]


  Internet-Draft           DNS Transport Signaling            October 2025


  13.  Appendix A.  Rationale for Using the Additional Section

     *Note to the RFC Editor*: Please remove this entire section before
     publication.

  13.1.  A.1.  Opportunistic Mode Via the Additional Section

     When designing a mechanism that relies on sending new information in
     DNS responses without changing the current DNS protocol, the
     Additional section has the major advantage of being ignored by legacy
     software.  This property makes it possible to essentially deploy the
     proposed mechanism immediately, as it will not cause problems with
     existing DNS infrastructure.

     *  Existing authoritative nameservers will not provide any DTS Hint
        in the Additional section.

     *  Existing resolvers will actively ignore any DTS Hint in the
        Additional section.

     Only DNS nameservers (authoritative or recursive) that are aware of
     the proposed mechanism will use it.

     The downside is that it is not possible to strictly rely on anything
     specific being present in the Additional section, as it may be
     stripped off by a middle man or even by the sending nameserver (eg.
     due to packet size constraints).  For this reason it is not possible
     to provide more than an opportunistic transport signal when the
     signal is not explicitly queried for.

     This is usually a major issue and the primary reason that data in the
     Additional section is actively ignored by resolvers.  In this
     particular case, though, even an untrusted transport signal is better
     than no signal at all.  Furthermore, the only effect of a forged or
     otherwise incorrect transport signal is a, typically failed,
     connection attempt to an authoritative nameserver that does not
     support the advertised transport.  This will cause immediate fallback
     to "Do53", i.e. traditional DNS over UDP/TCP and the non-availability
     of the advertised transport will be remembered by the resolver (for
     some suitable time).

     Hence, using the Additional section for opportunistic transport
     signaling has vastly more benefits than drawbacks.

  13.2.  A.2.  Validated Mode Via the Additional Section

     If the transport signal is present in the Additional section, it may
     or may not be possible to validate it (if it has a DNSSEC signature).



  Stenstam, et al.          Expires 23 April 2026                [Page 21]


  Internet-Draft           DNS Transport Signaling            October 2025


     This is necessary to bee able to trust more sensitive signals.  A
     positive signal inserted by an on-path attacker (eg. claiming DoQ
     support when this is false) would not be catastrophic.  However, a
     false negative alpn="-do53" signal (eg. claiming no Do53 support
     while such support is present) would be potentially catastrophic.
     For this reason (ability to trust more sensitive signals) the
     connection between resolver and authoritative server must be in
     Validated Mode.

  14.  Appendix B.  SVCB ALPN Negative Tokens

     This appendix defines a presentation-time extension to the SVCB
     "alpn" parameter that allows an authoritative nameserver to signal
     explicit non-support of a transport by prefixing an existing ALPN
     token with a hyphen ("-").  For example, "-do53" indicates that
     legacy UDP/TCP transport is not supported.

     Processing rules: - The "-do53" negative token is only actionable
     when the SVCB RRset is DNSSEC-validated (Validated mode).  In these
     cases, resolvers SHOULD honor the "-do53" token when selecting
     transports. - In Opportunistic (unvalidated) mode, resolvers MUST
     ignore the "-do53" negative token.

     Examples: - alpn="dot,doq" -> Indicates support for DoT and DoQ. -
     alpn="-do53,dot" -> Indicates no Do53; use DoT (validated modes
     only). - alpn="-do53,doq,dot" -> Indicates no Do53; prefer DoQ/DoT
     (validated modes only).

     Interoperability considerations: - Implementations that do not
     understand the alpn "-do53" negative token will ignore it per SVCB
     parameter processing and remain interoperable. - This alpn token does
     not alter on-the-wire encoding for ALPN; it is a presentation-layer
     convention.  IANA considerations for documentation of this convention
     are provided in Section 11.3.

  15.  References

  15.1.  Normative References

     [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/rfc/rfc2119>.

     [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
                for DNS (EDNS(0))", STD 75, RFC 6891,
                DOI 10.17487/RFC6891, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6891>.



  Stenstam, et al.          Expires 23 April 2026                [Page 22]


  Internet-Draft           DNS Transport Signaling            October 2025


     [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
                Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
                December 2014, <https://www.rfc-editor.org/rfc/rfc7435>.

     [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
                and P. Hoffman, "Specification for DNS over Transport
                Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
                2016, <https://www.rfc-editor.org/rfc/rfc7858>.

     [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/rfc/rfc8174>.

     [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
                Dedicated QUIC Connections", RFC 9250,
                DOI 10.17487/RFC9250, May 2022,
                <https://www.rfc-editor.org/rfc/rfc9250>.

     [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
                and Parameter Specification via the DNS (SVCB and HTTPS
                Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

     [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
                RFC 9461, DOI 10.17487/RFC9461, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9461>.

     [RFC9539]  Gillmor, D. K., Ed., Salazar, J., Ed., and P. Hoffman,
                Ed., "Unilateral Opportunistic Deployment of Encrypted
                Recursive-to-Authoritative DNS", RFC 9539,
                DOI 10.17487/RFC9539, February 2024,
                <https://www.rfc-editor.org/rfc/rfc9539>.

  15.2.  Informative References

     [I-D.draft-ietf-deleg]
                April, T., Špaček, P., Weber, R., and Lawrence,
                "Extensible Delegation for DNS", Work in Progress,
                Internet-Draft, draft-ietf-deleg-05, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-deleg-
                05>.

  Appendix A.  Change History (to be removed before publication)

        Initial public draft

  Authors' Addresses




  Stenstam, et al.          Expires 23 April 2026                [Page 23]


  Internet-Draft           DNS Transport Signaling            October 2025


     Johan Stenstam
     The Swedish Internet Foundation
     Sweden
     Email: johan.stenstam@internetstiftelsen.se


     Leon Fernandez
     The Swedish Internet Foundation
     Sweden
     Email: leon.fernandez@internetstiftelsen.se


     Erik Bergström
     The Swedish Internet Foundation
     Sweden
     Email: erik.bergstrom@internetstiftelsen.se


     Philip Homberg
     NLnet Labs
     Email: philip@nlnetlabs.nl


     Sara Dickinson
     Sinodun IT
     United Kingdom
     Email: sara@sinodun.com
























  Stenstam, et al.          Expires 23 April 2026                [Page 24]


name: draft-ietf-rats-ear
rev: 02
title: EAT Attestation Results
time: 2026-01-27T17:39:01Z
group_uri: /api/v1/group/group/2231/
expires: 2026-07-31T17:39:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.393660+00:00
source: ietf
source_id: 145428
source_url: https://datatracker.ietf.org/doc/draft-ietf-rats-ear/
doc_status: active
abstract:
  This document defines the EAT Attestation Result (EAR) message
     format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" to present a normalized view of the evaluation results, thus
     easing the task of defining and computing authorization policies by
     relying parties.  Alongside the trustworthiness vector, EAR provides
     contextual information bound to the appraisal process.  This allows a
     relying party (or an auditor) to reconstruct the frame of reference
     in which the trustworthiness vector was originally computed.  EAR
     supports simple devices with one attester as well as composite
     devices that are made of multiple attesters, allowing the state of
     each attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT or JWT.

full_text:
  Remote ATtestation ProcedureS                                 T. Fossati
  Internet-Draft                                                    Linaro
  Intended status: Standards Track                                 E. Voit
  Expires: 31 July 2026                                              Cisco
                                                               S. Trofimov
                                                               Arm Limited
                                                               H. Birkholz
                                                            Fraunhofer SIT
                                                           27 January 2026


                          EAT Attestation Results
                           draft-ietf-rats-ear-02

  Abstract

     This document defines the EAT Attestation Result (EAR) message
     format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" to present a normalized view of the evaluation results, thus
     easing the task of defining and computing authorization policies by
     relying parties.  Alongside the trustworthiness vector, EAR provides
     contextual information bound to the appraisal process.  This allows a
     relying party (or an auditor) to reconstruct the frame of reference
     in which the trustworthiness vector was originally computed.  EAR
     supports simple devices with one attester as well as composite
     devices that are made of multiple attesters, allowing the state of
     each attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT or JWT.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://thomas-
     fossati.github.io/draft-ear/draft-fv-rats-ear.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-rats-ear/.

     Discussion of this document takes place on the Remote ATtestation
     ProcedureS Working Group mailing list (mailto:rats@ietf.org), which
     is archived at https://mailarchive.ietf.org/arch/browse/rats/.
     Subscribe at https://www.ietf.org/mailman/listinfo/rats/.





  Fossati, et al.           Expires 31 July 2026                  [Page 1]


  Internet-Draft                     EAR                      January 2026


     Source for this draft and an issue tracker can be found at
     https://github.com/thomas-fossati/draft-ear.

  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 31 July 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  EAT Attestation Result  . . . . . . . . . . . . . . . . . . .   4
       3.1.  EAR Appraisal Claims  . . . . . . . . . . . . . . . . . .   5
       3.2.  JSON Serialisation  . . . . . . . . . . . . . . . . . . .   6
         3.2.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  CBOR Serialisation  . . . . . . . . . . . . . . . . . . .   9
         3.3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   9
     4.  EAR Extensions  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Unregistered claims . . . . . . . . . . . . . . . . . . .  10
       4.2.  Registered claims . . . . . . . . . . . . . . . . . . . .  10
       4.3.  Choosing between registered and unregistered claims . . .  10



  Fossati, et al.           Expires 31 July 2026                  [Page 2]


  Internet-Draft                     EAR                      January 2026


       4.4.  TEEP Extension  . . . . . . . . . . . . . . . . . . . . .  11
         4.4.1.  JSON Serialization Example  . . . . . . . . . . . . .  11
         4.4.2.  CBOR Serialization Example  . . . . . . . . . . . . .  12
       4.5.  Project Veraison Extensions . . . . . . . . . . . . . . .  13
         4.5.1.  JSON Serialization Examples . . . . . . . . . . . . .  14
         4.5.2.  CBOR Serialization Example  . . . . . . . . . . . . .  16
     5.  Media Types . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.  Implementation Status . . . . . . . . . . . . . . . . . . . .  18
       6.1.  Project Veraison  . . . . . . . . . . . . . . . . . . . .  18
         6.1.1.  github.com/veraison/ear . . . . . . . . . . . . . . .  18
         6.1.2.  github.com/veraison/c-ear . . . . . . . . . . . . . .  19
         6.1.3.  github.com/veraison/rust-ear  . . . . . . . . . . . .  19
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       9.1.  New EAT Claims  . . . . . . . . . . . . . . . . . . . . .  20
         9.1.1.  EAR Status  . . . . . . . . . . . . . . . . . . . . .  20
         9.1.2.  Trustworthiness Vector  . . . . . . . . . . . . . . .  20
         9.1.3.  EAR Raw Evidence  . . . . . . . . . . . . . . . . . .  21
         9.1.4.  EAR Appraisal Policy Identifier . . . . . . . . . . .  21
         9.1.5.  Verifier Software Identifier  . . . . . . . . . . . .  21
         9.1.6.  EAR TEEP Claims . . . . . . . . . . . . . . . . . . .  22
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
       10.2.  Informative References . . . . . . . . . . . . . . . . .  23
     Appendix A.  Common CDDL Types  . . . . . . . . . . . . . . . . .  24
     Appendix B.  Open Policy Agent Example  . . . . . . . . . . . . .  24
     Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  26
     Appendix D.  Document History . . . . . . . . . . . . . . . . . .  26
       D.1.  draft-fv-rats-ear-00  . . . . . . . . . . . . . . . . . .  26
       D.2.  draft-fv-rats-ear-01  . . . . . . . . . . . . . . . . . .  27
       D.3.  draft-fv-rats-ear-02  . . . . . . . . . . . . . . . . . .  27
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

     This document defines the EAT [RFC9711] Attestation Result (EAR)
     message format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" [I-D.ietf-rats-ar4si] to present a normalized view of the
     evaluation results, thus easing the task of defining and computing
     authorization policies by relying parties.  Alongside the
     trustworthiness vector, EAR provides contextual information bound to
     the appraisal process.  This allows a relying party (or an auditor)
     to reconstruct the frame of reference in which the trustworthiness



  Fossati, et al.           Expires 31 July 2026                  [Page 3]


  Internet-Draft                     EAR                      January 2026


     vector was originally computed.  EAR supports simple devices with one
     attester as well as composite devices that are made of multiple
     attesters (see Section 3.3 of [RFC9334]) allowing the state of each
     attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT [RFC8392] or JWT [RFC7519].

  2.  Conventions and Definitions

     This document uses terms and concepts defined by the RATS
     architecture.  For a complete glossary see Section 4 of [RFC9334].

     The terminology from CBOR [STD94], CDDL [RFC8610] and COSE [STD96]
     applies; in particular, CBOR diagnostic notation is defined in
     Section 8 of [STD94] and Appendix G of [RFC8610].

     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.

  3.  EAT Attestation Result

     EAR is an EAT token which can be serialized as JWT [RFC7519] or CWT
     [RFC8392].

     The EAR claims-set is as follows:

     ;# import rfc9711 as eat
     ;# import ar4si as ar4si

     EAR = {
       eat.profile-label => "tag:ietf.org,2025-07:ear"
       eat.iat-claim-label => int
       verifier-id-label => ar4si.verifier-id
       ? raw-evidence-label => eat.binary-data
       eat.submods-label => { + text => EAR-appraisal }
       ? eat.nonce-label => eat.nonce-type
       * $$ear-extension
     }

     ; EAR-specific claims
     raw-evidence-label = eat.JC<"ear.raw-evidence", 1002>
     verifier-id-label = eat.JC<"ear.verifier-id", 1004>

                        Figure 1: EAR (CDDL Definition)




  Fossati, et al.           Expires 31 July 2026                  [Page 4]


  Internet-Draft                     EAR                      January 2026


     Where:

     eat_profile (mandatory)  The EAT profile (Section 6 of [RFC9711])
        associated with the EAR claims-set and encodings defined by this
        document.  It MUST be the following tag URI ([RFC4151])
        tag:ietf.org,2025-07:ear.

     iat (mandatory)  "Issued At" claim -- the time at which the EAR is
        issued.  See Section 4.1.6 of [RFC7519] and Section 4.3.1 of
        [RFC9711] for the EAT-specific encoding restrictions (i.e.,
        disallowing the floating point representation).

     ear.verifier-id (mandatory)  Identifying information about the
        appraising verifier.  See Section 3.3 of [I-D.ietf-rats-ar4si] for
        further details on its structure and serialization.

     ear.raw-evidence (optional)  The unabridged evidence submitted for
        appraisal, including any signed container/envelope.  This field
        may be consumed by other Verifiers in multi-stage verification
        scenarios or by auditors.  There are privacy considerations
        associated with this claim.  See Section 8.

     submods (mandatory)  A submodule map (Section 4.2.18 of [RFC9711])
        holding one EAR-appraisal for each separately appraised attester.
        The map MUST contain at least one entry.  For each appraised
        attester the verifier chooses a unique label.  For example, when
        evidence is in EAT format, the label could be constructed from the
        associated EAT profile.  A verifier SHOULD publicly and
        permanently document its labelling scheme for each supported
        evidence type, unless EAR payloads are produced and consumed
        entirely within a private deployment.  See Section 3.1 for the
        details about the contents of an EAR-appraisal.

     eat_nonce (optional)  A user supplied nonce that is echoed by the
        verifier to provide freshness.  The nonce is a sequence of bytes
        between 8 and 64 bytes long.  When serialized as JWT, the nonce
        MUST be base64 encoded, resulting in a string between 12 and 88
        bytes long.  See Section 4.1 of [RFC9711].

     $$ear-extension (optional)  Any registered or unregistered extension.
        An EAR extension MUST be a map.  See Section 4 for further
        details.

  3.1.  EAR Appraisal Claims







  Fossati, et al.           Expires 31 July 2026                  [Page 5]


  Internet-Draft                     EAR                      January 2026


     ;# import ar4si as ar4si

     EAR-appraisal = {
       status-label => ar4si.trustworthiness-tier
       ? trustworthiness-vector-label => ar4si.trustworthiness-vector
       ? appraisal-policy-id-label => text
       * $$ear-appraisal-extension
     }

     status-label = eat.JC<"ear.status", 1000>
     trustworthiness-vector-label = eat.JC<"ear.trustworthiness-vector", 1001>
     appraisal-policy-id-label = eat.JC<"ear.appraisal-policy-id", 1003>

                Figure 2: EAR Appraisal Claims (CDDL Definition)

     ear.status (mandatory)
        The overall appraisal status for this attester represented as one
        of the four trustworthiness tiers (Section 3.2 of
        [I-D.ietf-rats-ar4si]).  The value of this claim MUST be set to a
        tier of no higher trust than the tier corresponding to the worst
        trustworthiness claim across the entire trustworthiness vector.

     ear.trustworthiness-vector (optional)
        The AR4SI trustworthiness vector providing the breakdown of the
        appraisal for this attester.  See Section 3.1 of
        [I-D.ietf-rats-ar4si] for the details.  This claim MUST be present
        unless the party requesting Evidence appraisal explicitly asks for
        it to be dropped, e.g., via an API parameter or similar
        arrangement.  Such consumer would therefore rely entirely on the
        semantics of the ear.status claim.  This behaviour is NOT
        RECOMMENDED because of the resulting loss of quality of the
        appraisal result.

     ear.appraisal-policy-id (optional)
        An unique identifier of the appraisal policy used to evaluate the
        attestation result.

     $$ear-appraisal-extension (optional)
        Any registered or unregistered extension.  An EAR appraisal
        extension MUST be a map.  See Section 4 for further details.

  3.2.  JSON Serialisation









  Fossati, et al.           Expires 31 July 2026                  [Page 6]


  Internet-Draft                     EAR                      January 2026


  3.2.1.  Examples

     The example in Figure 3 shows an EAR claims-set corresponding to a
     "contraindicated" appraisal, meaning the verifier has found some
     problems with the attester's state reported in the submitted
     evidence.  Specifically, the identified issue is related to
     unauthorized code or configuration loaded in runtime memory (i.e.,
     value 96 in the executables category).  The appraisal is for a device
     with one attester labelled "PSA".  Note that in case there is only
     one attester, the labelling can be freely chosen because there is no
     ambiguity.

     {
       "eat_profile": "tag:ietf.org,2025-07:ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         }
       }
     }

              Figure 3: JSON claims-set: contraindicated appraisal

     The breakdown of the trustworthiness vector is as follows:

     *  Instance Identity (affirming): recognized and not compromised

     *  Configuration (warning): known vulnerabilities

     *  Executables (contraindicated): contraindicated run-time

     *  File System (none): no claim being made

     *  Hardware (affirming): genuine




  Fossati, et al.           Expires 31 July 2026                  [Page 7]


  Internet-Draft                     EAR                      January 2026


     *  Runtime Opaque (none): no claim being made

     *  Storage Opaque (none): no claim being made

     *  Sourced Data (none): no claim being made

     The example in Figure 4 contains the appraisal for a composite device
     with two attesters named "CCA Platform" and "CCA Realm" respectively.
     Both attesters have either "affirming" or (implicit) "none" values in
     their associated trustworthiness vectors.  Note that the "none"
     values can refer to either an AR4SI category that is unapplicable for
     the specific attester (ideally, the applicability should be specified
     by the evidence format itself), or to the genuine lack of information
     at the attester site regarding the specific category.  For example,
     the reference values for the "CCA Realm" executables (i.e., the
     confidential computing workload) may not be known to the CCA platform
     verifier.  In such cases, it is up to the downstream entity
     (typically, the relying party) to complete the partial appraisal.

     {
       "eat_profile": "tag:ietf.org,2025-07:ear",
       "iat": 1666529300,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQKNzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "CCA Platform": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 2,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         },
         "CCA Realm": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d"
         }
       }
     }



  Fossati, et al.           Expires 31 July 2026                  [Page 8]


  Internet-Draft                     EAR                      January 2026


             Figure 4: JSON claims-set: simple affirming appraisal

  3.3.  CBOR Serialisation

  3.3.1.  Examples

     The example in Figure 5 is semantically equivalent to that in
     Figure 3.  It shows the same "contraindicated" appraisal using the
     more compact CBOR serialization of the EAR claims-set.

     {
       265: "tag:ietf.org,2025-07:ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA": {
           1000: 96,
           1001: {
             0: 2,
             2: 96,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d"
         }
       }
     }

              Figure 5: CBOR claims-set: contraindicated appraisal

  4.  EAR Extensions

     EAR provides core semantics for describing the result of appraising
     attestation evidence.  However, a given application may offer extra
     functionality to its relying parties, or tailor the attestation
     result to the needs of the application (e.g., TEEP
     [I-D.ietf-teep-protocol]).  To accommodate such cases, both EAR and
     EAR-appraisal claims-sets can be extended by plugging new claims into
     the $$ear-extension (or $$ear-appraisal-extension, respectively) CDDL
     socket.

     The rules that govern extensibility of EAR are those defined in
     [RFC8392] and [RFC7519] for CWTs and JWTs respectively.





  Fossati, et al.           Expires 31 July 2026                  [Page 9]


  Internet-Draft                     EAR                      January 2026


     An extension MUST NOT change the semantics of the EAR and EAR-
     appraisal claims-sets.

     A receiver MUST ignore any unknown claim.

  4.1.  Unregistered claims

     An application-specific extension will normally mint its claim from
     the "private space" - using integer values less than -65536 for CWT,
     and Public or Private Claim Names as defined in Sections 4.2 and 4.3
     of [RFC7519] when serializing to JWT.

     It is RECOMMENDED that JWT EARs use Collision-Resistant Public Claim
     Names (Section 2 of [RFC7519]) rather than Private Claim Names.

  4.2.  Registered claims

     If an extension will be used across multiple applications, or is
     intended to be used across multiple environments, the associated
     extension claims SHOULD be registered in one, or both, the CWT and
     JWT claim registries.

     In general, if the registration policy requires an accompanying
     specification document (as it is the case for "specification
     required" and "standards action"), such document SHOULD explicitly
     say that the extension is expected to be used in EAR claims-sets
     identified by this profile.

     An up-to-date view of the registered claims can be obtained via the
     [IANA.cwt] and [IANA.jwt] registries.

  4.3.  Choosing between registered and unregistered claims

     If an extension supports functionality of a specific application
     (e.g. Project Veraison Services), its claims MAY be registered.

     If an extension supports a protocol that may be applicable across
     multiple applications or environments (e.g., TEEP), its claims SHOULD
     be registered.

     Since, in general, there is no guarantee that an application will be
     confined within an environment, it is RECOMMENDED that extension
     claims that have meaning outside the application's context are always
     registered.







  Fossati, et al.           Expires 31 July 2026                 [Page 10]


  Internet-Draft                     EAR                      January 2026


     It is also possible that claims that start out as application-
     specific acquire a more stable meaning over time.  In such cases, it
     is RECOMMENDED that new equivalent claims are created in the "public
     space" and are registered as described in Section 4.2.  The original
     "private space" claims SHOULD then be deprecated by the application.

  4.4.  TEEP Extension

     The TEEP protocol [I-D.ietf-teep-protocol] specifies the required
     claims that an attestation result must carry for a TAM (Trusted
     Application Manager) to make decisions on how to remediate a TEE
     (Trusted Execution Environment) that is out of compliance, or update
     a TEE that is requesting an authorized change.

     The list is provided in Section 4.3.1 of [I-D.ietf-teep-protocol].

     EAR defines a TEEP application extension for the purpose of conveying
     such claims.

     ;# import rfc9711 as eat
     ;# import rfc9393

     $$ear-appraisal-extension //= (
       ear.teep-claims-label => ear-teep-claims
     )

     ear-teep-claims = non-empty<{
       ? eat.nonce-label => eat.nonce-type
       ? eat.ueid-label => eat.ueid-type
       ? eat.oemid-label => eat.oemid-pen / eat.oemid-ieee / eat.oemid-random
       ? eat.hardware-model-label => eat.hardware-model-type
       ? eat.hardware-version-label => eat.hardware-version-type
       ? eat.manifests-label => eat.manifests-type
     }>

     ear.teep-claims-label = eat.JC<"ear.teep-claims", 65000>

                   Figure 6: TEEP Extension (CDDL Definition)

  4.4.1.  JSON Serialization Example











  Fossati, et al.           Expires 31 July 2026                 [Page 11]


  Internet-Draft                     EAR                      January 2026


     {
       "eat_profile": "tag:ietf.org,2025-07:ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.teep-claims": {
             "eat_nonce": "80FH7byS7VjfARIq0_KLqu6B9j-F79QtV6p",
             "ueid": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "oemid": "Av8B",
             "hwmodel": "fJYq",
             "hwversion": ["1.2.5", 16384]
           }
         }
       }
     }

  4.4.2.  CBOR Serialization Example





















  Fossati, et al.           Expires 31 July 2026                 [Page 12]


  Internet-Draft                     EAR                      January 2026


     {
       265: "tag:ietf.org,2025-07:ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA": {
           1000: 0,
           1001: {
             0: 2,
             1: 2,
             2: 2,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d",
           65000: {
             10: h'948f8860d13a463e',
             256: h'0198f50a4ff6c05861c8860d13a638ea',
             258: 64242,
             259: h'ee80f5a66c1fb9742999a8fdab930893',
             260: ["1.2.5", 16384]
           }
         }
       }
     }

  4.5.  Project Veraison Extensions

     The Project Veraison verifier defines three private, application-
     specific extensions:

     ear.veraison.annotated-evidence
        JSON representation of the evidence claims-set, including any
        annotations provided by the Project Veraison verifier.  There are
        privacy considerations associated with this claim.  See Section 8.

     ear.veraison.policy-claims
        any extra claims added by the policy engine in the Project
        Veraison verifier.

     ear.veraison.key-attestation
        contains the public key part of a successfully verified attested
        key.  The key is a DER encoded ASN.1 SubjectPublicKeyInfo
        structure (Section 4.1.2.7 of [RFC5280]).




  Fossati, et al.           Expires 31 July 2026                 [Page 13]


  Internet-Draft                     EAR                      January 2026


     ;# import rfc9711 as eat

     $$ear-appraisal-extension //= (
       ear.veraison.annotated-evidence-label => ear-veraison-annotated-evidence
     )

     ear-veraison-annotated-evidence = {
       + text => any
     }

     $$ear-appraisal-extension //= (
       ear.veraison.policy-claims-label => ear-veraison-policy-claims
     )

     ear-veraison-policy-claims = {
       + text => any
     }

     $$ear-appraisal-extension //= (
       ear.veraison.key-attestation-label => ear-veraison-key-attestation
     )

     ear-veraison-key-attestation = {
       "akpub" => eat.binary-data
     }

     ear.veraison.annotated-evidence-label = eat.JC<"ear.veraison.annotated-evidence", -70000>
     ear.veraison.policy-claims-label = eat.JC<"ear.veraison.policy-claims", -70001>
     ear.veraison.key-attestation-label = eat.JC<"ear.veraison.key-attestation", -70002>

            Figure 7: Project Veraison Extensions (CDDL Definition)

  4.5.1.  JSON Serialization Examples

     {
       "eat_profile": "tag:ietf.org,2025-07:ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PSA_IOT": {
           "ear.status": "contraindicated",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 96,



  Fossati, et al.           Expires 31 July 2026                 [Page 14]


  Internet-Draft                     EAR                      January 2026


             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.veraison.annotated-evidence": {
             "eat-profile": "http://arm.com/psa/2.0.0",
             "psa-client-id": 1,
             "psa-security-lifecycle": 12288,
             "psa-implementation-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-software-components": [
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               },
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               }
             ],
             "psa-nonce":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-instance-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "psa-certification-reference": "1234567890123-12345"
           },
           "ear.veraison.policy-claims": {
             "psa-certified": {
               "certificate-number": "1234567890123-12345",
               "date-of-issue": "23/06/2022",
               "test-lab": "Riscure",
               "certification-holder": "ACME Inc.",
               "certified-product": "RoadRunner",
               "hardware-version": "Gizmo v1.0.2",
               "software-version": "TrustedFirmware-M v1.0.6",
               "certification-type": "PSA Certified Level 1 v2.1",
               "developer-type": "PSA Certified – Device"
             }
           }
         }
       }
     }





  Fossati, et al.           Expires 31 July 2026                 [Page 15]


  Internet-Draft                     EAR                      January 2026


     {
       "eat_profile": "tag:ietf.org,2025-07:ear",
       "iat": 1666529184,
       "ear.verifier-id": {
         "developer": "https://veraison-project.org",
         "build": "vts 0.0.1"
       },
       "ear.raw-evidence": "NzQ3MjY5NzM2NTYzNzQK",
       "submods": {
         "PARSEC_TPM": {
           "ear.status": "affirming",
           "ear.trustworthiness-vector": {
             "instance-identity": 2,
             "executables": 2,
             "hardware": 2
           },
           "ear.appraisal-policy-id":
             "https://veraison.example/policy/1/60a0068d",
           "ear.veraison.key-attestation": {
             "akpub":
               "MFkwEwYHKoZIzj0CAQYIKoZIz___"
           }
         }
       }
     }

  4.5.2.  CBOR Serialization Example

     {
       265: "tag:ietf.org,2025-07:ear",
       6: 1666529184,
       1004: {
         0: "https://veraison-project.org",
         1: "vts 0.0.1"
       },
       1002: h'6C696665626F61746D616E',
       266: {
         "PSA_IOT": {
           1000: 0,
           1001: {
             0: 2,
             1: 2,
             2: 2,
             4: 2
           },
           1003: "https://veraison.example/policy/1/60a0068d",
           -70000: {
             "eat-profile": "http://arm.com/psa/2.0.0",



  Fossati, et al.           Expires 31 July 2026                 [Page 16]


  Internet-Draft                     EAR                      January 2026


             "psa-client-id": 1,
             "psa-security-lifecycle": 12288,
             "psa-implementation-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-software-components": [
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               },
               {
                 "measurement-value":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
                 "signer-id":
                   "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
               }
             ],
             "psa-nonce":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
             "psa-instance-id":
               "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
             "psa-certification-reference": "1234567890123-12345"
           },
           -70001: {
             "psa-certified": {
               "certificate-number": "1234567890123-12345",
               "date-of-issue": "23/06/2022",
               "test-lab": "Riscure",
               "certification-holder": "ACME Inc.",
               "certified-product": "RoadRunner",
               "hardware-version": "Gizmo v1.0.2",
               "software-version": "TrustedFirmware-M v1.0.6",
               "certification-type": "PSA Certified Level 1 v2.1",
               "developer-type": "PSA Certified – Device"
             }
           }
         }
       }
     }

  5.  Media Types

     Media types for EAR are automatically derived from the base EAT media
     type [RFC9782] using the profile string defined in Section 3.

     For example, a JWT serialization would use:




  Fossati, et al.           Expires 31 July 2026                 [Page 17]


  Internet-Draft                     EAR                      January 2026


     application/eat-jwt; eat_profile="tag:ietf.org,2025-07:ear"

     A CWT serialization would instead use:

     application/eat-cwt; eat_profile="tag:ietf.org,2025-07:ear"

  6.  Implementation Status

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in [RFC7942].
     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.  Please note that the listing of any individual implementation
     here does not imply endorsement by the IETF.  Furthermore, no effort
     has been spent to verify the information presented here that was
     supplied by IETF contributors.  This is not intended as, and must not
     be construed to be, a catalog of available implementations or their
     features.  Readers are advised to note that other implementations may
     exist.

     According to [RFC7942], "this will allow reviewers and working groups
     to assign due consideration to documents that have the benefit of
     running code, which may serve as evidence of valuable experimentation
     and feedback that have made the implemented protocols more mature.
     It is up to the individual working groups to use this information as
     they see fit".

  6.1.  Project Veraison

     The organization responsible for this implementation is Project
     Veraison, a Linux Foundation project hosted at the Confidential
     Computing Consortium.

     The organization currently provides two separate implementations: one
     in Golang another in C17.

     The developers can be contacted on the Zulip channel:
     https://veraison.zulipchat.com/#narrow/stream/357929-EAR/.

  6.1.1.  github.com/veraison/ear

     The software, hosted at https://github.com/veraison/ear, provides a
     Golang package that allows encoding, decoding, signing and
     verification of EAR payloads together with a CLI (arc) to create,
     verify and visualize EARs on the command line.  The maturity level is
     currently alpha, and only the JWT serialization is implemented.  The
     license is Apache 2.0.  The package is used by the Project Veraison



  Fossati, et al.           Expires 31 July 2026                 [Page 18]


  Internet-Draft                     EAR                      January 2026


     verifier to produce attestation results.

  6.1.2.  github.com/veraison/c-ear

     The software, hosted at https://github.com/veraison/c-ear, provides a
     C17 library that allows verification and partial decoding of EAR
     payloads.  The maturity level is currently pre-alpha, and only the
     JWT serialization is implemented.  The license is Apache 2.0.  The
     library targets relying party applications that need to verify
     attestation results.

  6.1.3.  github.com/veraison/rust-ear

     The software, hosted at https://github.com/veraison/rust-ear,
     provides a Rust (2021 edition) library that allows verification and
     partial decoding of EAR payloads.  The maturity level is currently
     pre-alpha, with limitted algorithm support.  Both JWT and COSE
     serializations are implemented.  The license is Apache 2.0.  The
     library targets verifiers that need to produce attestation results as
     well as relying party applications that need to verify and consume
     attestation results.

  7.  Security Considerations

     TODO Security

  8.  Privacy Considerations

     EAR is designed to expose as little identifying information as
     possible about the attester.  However, certain EAR claims have direct
     privacy implications.  Implementations should therefore allow
     applying privacy-preserving techniques to those claims, for example
     allowing their redaction, anonymisation or outright removal.
     Specifically:

     *  It SHOULD be possible to disable inclusion of the optional
        ear.raw-evidence claim

     *  It SHOULD be possible to disable inclusion of the optional
        ear.veraison.annotated-evidence claim

     *  It SHOULD be possible to allow redaction, anonymisation or removal
        of specific claims from the ear.veraison.annotated-evidence object

     EAR is an EAT, therefore the privacy considerations in Section 8 of
     [RFC9711] apply.





  Fossati, et al.           Expires 31 July 2026                 [Page 19]


  Internet-Draft                     EAR                      January 2026


  9.  IANA Considerations

  9.1.  New EAT Claims

     This specification adds the following values to the "JSON Web Token
     Claims" registry [IANA.jwt] and the "CBOR Web Token Claims" registry
     [IANA.cwt].

     Each entry below is an addition to both registries.

     The "Claim Description", "Change Controller" and "Specification
     Documents" are common and equivalent for the JWT and CWT registries.
     The "Claim Key" and "Claim Value Types(s)" are for the CWT registry
     only.  The "Claim Name" is as defined for the CWT registry, not the
     JWT registry.  The "JWT Claim Name" is equivalent to the "Claim Name"
     in the JWT registry.

  9.1.1.  EAR Status

     *  Claim Name: ear.status

     *  Claim Description: EAR Status

     *  JWT Claim Name: ear.status

     *  Claim Key: 1000 (suggested)

     *  Claim Value Type(s): unsigned integer (0, 2, 32, 96)

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis

  9.1.2.  Trustworthiness Vector

     *  Claim Name: ear.trustworthiness-vector

     *  Claim Description: EAR Trustworthiness Vector

     *  JWT Claim Name: ear.trustworthiness-vector

     *  Claim Key: 1001 (suggested)

     *  Claim Value Type(s): map

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis



  Fossati, et al.           Expires 31 July 2026                 [Page 20]


  Internet-Draft                     EAR                      January 2026


  9.1.3.  EAR Raw Evidence

     *  Claim Name: ear.raw-evidence

     *  Claim Description: EAR Raw Evidence

     *  JWT Claim Name: ear.raw-evidence

     *  Claim Key: 1002 (suggested)

     *  Claim Value Type(s): bytes

     *  Change Controller: IESG

     *  Specification Document(s): Section 3 of RFCthis

  9.1.4.  EAR Appraisal Policy Identifier

     *  Claim Name: ear.appraisal-policy-id

     *  Claim Description: EAR Appraisal Policy Identifier

     *  JWT Claim Name: ear.appraisal-policy-id

     *  Claim Key: 1003 (suggested)

     *  Claim Value Type(s): text

     *  Change Controller: IESG

     *  Specification Document(s): Section 3.1 of RFCthis

  9.1.5.  Verifier Software Identifier

     *  Claim Name: ear.verifier-id

     *  Claim Description: AR4SI Verifier Software Identifier

     *  JWT Claim Name: ear.verifier-id

     *  Claim Key: 1004 (suggested)

     *  Claim Value Type(s): map

     *  Change Controller: IESG

     *  Specification Document(s): Section 3 of RFCthis




  Fossati, et al.           Expires 31 July 2026                 [Page 21]


  Internet-Draft                     EAR                      January 2026


  9.1.6.  EAR TEEP Claims

     TODO

  10.  References

  10.1.  Normative References

     [I-D.ietf-rats-ar4si]
                Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
                Scarlata, "Attestation Results for Secure Interactions",
                Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
                09, 15 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                ar4si-09>.

     [I-D.ietf-teep-protocol]
                Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and
                A. Tsukamoto, "Trusted Execution Environment Provisioning
                (TEEP) Protocol", Work in Progress, Internet-Draft, draft-
                ietf-teep-protocol-21, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-teep-
                protocol-21>.

     [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/rfc/rfc2119>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [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/rfc/rfc8174>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.





  Fossati, et al.           Expires 31 July 2026                 [Page 22]


  Internet-Draft                     EAR                      January 2026


     [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/rfc/rfc8610>.

     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
                DOI 10.17487/RFC9711, April 2025,
                <https://www.rfc-editor.org/rfc/rfc9711>.

     [RFC9782]  Lundblade, L., Birkholz, H., and T. Fossati, "Entity
                Attestation Token (EAT) Media Types", RFC 9782,
                DOI 10.17487/RFC9782, May 2025,
                <https://www.rfc-editor.org/rfc/rfc9782>.

     [STD94]    Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [STD96]    Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

  10.2.  Informative References

     [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
                <https://www.iana.org/assignments/cwt>.

     [IANA.jwt] IANA, "JSON Web Token (JWT)",
                <https://www.iana.org/assignments/jwt>.

     [RFC4151]  Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
                RFC 4151, DOI 10.17487/RFC4151, October 2005,
                <https://www.rfc-editor.org/rfc/rfc4151>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.




  Fossati, et al.           Expires 31 July 2026                 [Page 23]


  Internet-Draft                     EAR                      January 2026


  Appendix A.  Common CDDL Types

     non-empty
        A CDDL generic that can be used to ensure the presence of at least
        one item in an object with only optional fields.

     non-empty<M> = (M) .within ({ + any => any })

  Appendix B.  Open Policy Agent Example

     Open Policy Agent OPA (https://www.openpolicyagent.org) is a popular
     and flexible policy engine that is used in a variety of contexts,
     from cloud to IoT.  OPA policies are written using a purpose-built,
     declarative programming language called Rego
     (https://www.openpolicyagent.org/docs/latest/policy-language/).  Rego
     has been designed to handle JSON claim-sets and their JWT envelopes
     as first class objects, which makes it an excellent fit for dealing
     with JWT EARs.

     The following example illustrates an OPA policy that a Relying Party
     would use to make decisions based on a JWT EAR received from a
     trusted verifier.





























  Fossati, et al.           Expires 31 July 2026                 [Page 24]


  Internet-Draft                     EAR                      January 2026


     package ear

     ear_appraisal = {
         "verified": signature_verified,
         "appraisal-status": status,
         "trustworthiness-vector": trust_vector,
     } {
         # verify EAR signature is correct and from one of the known and
         # trusted verifiers
         signature_verified := io.jwt.verify_es256(
             input.ear_token,
             json.marshal(input.trusted_verifiers)
         )

         # extract the EAR claims-set
         [_, payload, _] := io.jwt.decode(input.ear_token)

         # access the attester-specific appraisal record
         app_rec := payload.submods.PARSEC_TPM
         status := app_rec["ear.status"] == "affirming"

         # extract the trustworhiness vector for further inspection
         trust_vector := app_rec["ear.trustworthiness-vector"]
     }

     # add further conditions on the trust_vector here
     # ...

     The result of the policy appraisal is the following JSON object:

     {
         "ear_appraisal": {
             "appraisal-status": true,
             "trustworthiness-vector": {
                 "executables": 2,
                 "hardware": 2,
                 "instance-identity": 2
             },
             "verified": true
         }
     }

     For completeness, the trusted verifier public key and the EAR JWT
     used in the example are provided below.







  Fossati, et al.           Expires 31 July 2026                 [Page 25]


  Internet-Draft                     EAR                      January 2026


     =============== NOTE: '\' line wrapping per RFC 8792 ================
     {
         "ear_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXIucmF3L\
     WV2aWRlbmNlIjoiTnpRM01qWTVOek0yTlRZek56UUsiLCJlYXIudmVyaWZpZXItaWQiO\
     nsiYnVpbGQiOiJ2dHMgMC4wLjEiLCJkZXZlbG9wZXIiOiJodHRwczovL3ZlcmFpc29uL\
     XByb2plY3Qub3JnIn0sImVhdF9wcm9maWxlIjoidGFnOmdpdGh1Yi5jb20sMjAyMzp2Z\
     XJhaXNvbi9lYXIiLCJpYXQiOjEuNjY2NTI5MTg0ZSswOSwianRpIjoiNTViOGIzZmFkO\
     GRkMWQ4ZWFjNGU0OGYxMTdmZTUwOGIxMWY4NDRkOWYwMTg5YmZlZDliODc1MTVhNjc1N\
     DI2NCIsIm5iZiI6MTY3NzI0Nzg3OSwic3VibW9kcyI6eyJQQVJTRUNfVFBNIjp7ImVhc\
     i5hcHByYWlzYWwtcG9saWN5LWlkIjoiaHR0cHM6Ly92ZXJhaXNvbi5leGFtcGxlL3Bvb\
     GljeS8xLzYwYTAwNjhkIiwiZWFyLnN0YXR1cyI6ImFmZmlybWluZyIsImVhci50cnVzd\
     HdvcnRoaW5lc3MtdmVjdG9yIjp7ImV4ZWN1dGFibGVzIjoyLCJoYXJkd2FyZSI6Miwia\
     W5zdGFuY2UtaWRlbnRpdHkiOjJ9LCJlYXIudmVyYWlzb24ua2V5LWF0dGVzdGF0aW9uI\
     jp7ImFrcHViIjoiTUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFY2pTc\
     DhfTVdNM2d5OFR1Z1dPMVRwUVNqX3ZJa3NMcEMtZzhsNVMzbHBHYjdQV1dHb0NBakVQO\
     F9BNTlWWndMWGd3b1p6TjBXeHVCUGpwYVdpV3NmQ1EifX19fQ.3Ym-f1LEgamxePUM7h\
     6Y2RJDGh9eeL0xKor0n1wE9jdAnLNwm3rTKFV2S2LbqVFoDtK9QGalT2t5RnUdfwZNmg\
     ",
         "trusted_verifiers": {
             "keys": [
                 {
                     "alg": "ES256",
                     "crv": "P-256",
                     "kty": "EC",
                     "x": "usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8",
                     "y": "IBOL-C3BttVivg-lSreASjpkttcsz-1rb7btKLv8EX4"
                 }
             ]
         }
     }

  Appendix C.  Open Issues


     // Note to RFC Editor: please remove before publication.

     The list of currently open issues for this documents can be found at
     https://github.com/thomas-fossati/draft-ear/issues.

  Appendix D.  Document History


     // Note to RFC Editor: please remove before publication.

  D.1.  draft-fv-rats-ear-00

     Initial release.




  Fossati, et al.           Expires 31 July 2026                 [Page 26]


  Internet-Draft                     EAR                      January 2026


  D.2.  draft-fv-rats-ear-01

     *  privacy considerations

     *  OPA policy example

     *  add rust-ear crate to the implementation status section

  D.3.  draft-fv-rats-ear-02

     *  align JWT and CWT representations of eat_nonce

  Acknowledgments

     Many thanks to Dave Thaler, Greg Kostal, Simon Frost, Yogesh
     Deshpande for helpful comments and discussions that have shaped this
     document.

  Authors' Addresses

     Thomas Fossati
     Linaro
     Email: thomas.fossati@linaro.org


     Eric Voit
     Cisco
     Email: evoit@cisco.com


     Sergei Trofimov
     Arm Limited
     Email: sergei.trofimov@arm.com


     Henk Birkholz
     Fraunhofer SIT
     Rheinstrasse 75
     64295 Darmstadt
     Germany
     Email: henk.birkholz@ietf.contact










  Fossati, et al.           Expires 31 July 2026                 [Page 27]


name: draft-ounsworth-lamps-x509-ar
rev: 00
title: X.509 Certificate Extensions for Attestation Results
time: 2025-11-03T07:09:24Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-28T10:47:18Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.399035+00:00
source: ietf
source_id: 145844
source_url: https://datatracker.ietf.org/doc/draft-ounsworth-lamps-x509-ar/
doc_status: active
abstract:
  This document defines extensions for X.509 certificates to include
     attestation results as part of the certificate's content.  The
     primary use case for these extensions is in the context of
     Certificate Signing Request (CSR) attestation, where claims about the
     trustworthiness of an Attester are conveyed to the Certification
     Authority (CA) as part of the CSR process.  These extensions enable
     the CA to appraise the submitted evidence and embed attestation
     results into the issued certificate.  This allows Relying Parties to
     evaluate the Attester's trustworthiness consistently and efficiently,
     supporting scalable policies for verification in environments with
     diverse attestation technologies.

full_text:
  LAMPS                                                       M. Ounsworth
  Internet-Draft                                                   Entrust
  Intended status: Standards Track                              M. Wiseman
  Expires: 28 October 2025                                 Beyond Identity
                                                             H. Tschofenig
                                                                     H-BRS
                                                                  T. Reddy
                                                                     Nokia
                                                                  N. Smith
                                                         Intel Corporation
                                                             26 April 2025


            X.509 Certificate Extensions for Attestation Results
                      draft-ounsworth-lamps-x509-ar-00

  Abstract

     This document defines extensions for X.509 certificates to include
     attestation results as part of the certificate's content.  The
     primary use case for these extensions is in the context of
     Certificate Signing Request (CSR) attestation, where claims about the
     trustworthiness of an Attester are conveyed to the Certification
     Authority (CA) as part of the CSR process.  These extensions enable
     the CA to appraise the submitted evidence and embed attestation
     results into the issued certificate.  This allows Relying Parties to
     evaluate the Attester's trustworthiness consistently and efficiently,
     supporting scalable policies for verification in environments with
     diverse attestation technologies.

  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 28 October 2025.





  Ounsworth, et al.        Expires 28 October 2025                [Page 1]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Certificate Extensions  . . . . . . . . . . . . . . . . . . .   4
       3.1.  id-pkix-attest-entity-platform (Platform Attestation) . .   5
       3.2.  id-pkix-attest-entity-key (Key Attestation) . . . . . . .   5
       3.3.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Attestation mechanisms are increasingly used to verify the
     trustworthiness of devices and cryptographic keys.  These mechanisms
     provide evidence that a device or key meets specific security
     criteria before being relied upon by an application.  However,
     relying parties need a standardized way to access and validate these
     attestation results.

     This document introduces the Evidence Claims Certificate Extension,
     which enables Certification Authorities (CAs) to embed attestation
     results into issued X.509 certificates.  By incorporating attestation
     results directly into certificates, Relying Parties can assess
     trustworthiness without requiring additional protocol interactions
     with external verifiers.

     This extension is particularly useful in environments where:




  Ounsworth, et al.        Expires 28 October 2025                [Page 2]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


     *  Devices generate key pairs and request certificates while
        providing evidence of their security characteristics, such as key
        storage protection and tamper resistance.
     *  Certification Authorities evaluate and verify attestation claims
        before issuing a certificate.
     *  Relying Parties need a standardized way to verify the security
        characteristics of a key or the platform managing it, as stated in
        the certificate, without requiring real-time attestation checks,
        since these characteristics are relatively static.

     While PKIX Key Attestation [I-D.ietf-rats-pkix-key-attestation]
     defines a mechanism for carrying attestation evidence within a CSR,
     this document extends that concept to X.509 certificates by defining
     a Certificate Evidence Claims extension.  This extension allows
     attestation evidence to be embedded directly into an issued
     certificate, enabling Relying Parties to verify the security
     characteristics of a key or its platform without requiring access to
     the original CSR or real-time attestation.  Additionally, this
     document defines the ASN.1 syntax for the Evidence Claims Certificate
     Extension and specifies how it should be included in X.509
     certificates.

                               .-----------------.
                               |                 | Compare Evidence
                               |     Verifier    | against Appraisal
                               |                 | Policy
                               '------------+----'
                                    ^       |
                           Evidence |       | Attestation
                             (2)    |       | Result (3)
                                    |       v
     .------------.            .----|-------|----.                .-----.
     |            +----------->|----'       '--->|--------------->|     |
     | HSM        | Evidence   | Registration    | CSR with       | CA  |
     | (Attester) | in CSR (1) | Authority       | Attestation    |     |
     |            |            | (Relying Party) | Result (4)     |     |
     '------------'            '-----------------'                '-----'
         ^     ^                                                     |
         |     |    X.509 Certificate with Attestation Result (5)    |
         |     +-----------------------------------------------------+
         |
         |                     .-----------------.
         |       TLS           |                 |
         | (with mutual auth.) | Relying Party   |
         +-------------------->|                 |
                  (6)          '-----------------'





  Ounsworth, et al.        Expires 28 October 2025                [Page 3]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


          Figure 1: Example Data Flow demonstrating Attested CSR with
                            Background Check Model.

     Steps 1 to 4, covering the generation of evidence in a CSR, its
     verification by a Registration Authority, and the issuance of a CSR
     with an attestation result, are already specified in
     [I-D.ietf-rats-pkix-key-attestation].

     *  Step 5: The CA issues an X.509 certificate embedding the
        attestation result within the Evidence Claims Certificate
        Extension.
     *  Step 6: The Relying Party uses TLS with mutual authentication to
        verify the certificate and its Evidence Claims, authenticating the
        Attester.

     This ensures that the security characteristics of the key or platform
     are verifiable without requiring real-time attestation checks.

  2.  Conventions and Definitions

     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.

  3.  Certificate Extensions

     This section specifies the syntax and semantics of the Attestation
     Result Claims certificate extension, which provides a list of claims
     associated with the certificate subject appraised by the CA.

     The Attestation Result Claims certificate extension MAY be included
     in public key certificates [RFC5280].  The Attestation Result Claims
     certificate extension MUST be identified by the following object
     identifier:

     id-pe-ar-claims OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-pe(1) 34
     }

     This extension MUST NOT be marked critical.

     The Attestation Result Claims extension MUST have the following
     syntax:

     AR-Claims ::= SEQUENCE SIZE (1..MAX) OF ReportedEntity



  Ounsworth, et al.        Expires 28 October 2025                [Page 4]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


     The AR-Claims field represents a sequence of attestation result
     claims (ReportedEntity) included by the CA in the certificate.  It
     MUST contain at least one claim.  For privacy reasons, the CA MAY
     choose to include only a subset of the claims from the Attestation
     Result it received from a Verifier.  The CA may include in their
     certificate profile a list of verified evidence claims (identified by
     OID) that MAY be copied from the CSR to the certificate, while any
     other claims MUST NOT be copied.  By removing the signature from the
     evidence, the CA is asserting that it has verified the Evidence to
     chain to a root that the CA trusts, but it is not required to
     disclose in the final certificate what that root is.

     See Section 4 for a discussion of privacy concerns related to re-
     publishing Evidence into a certificate.

     The platform entity and key entity are relevant to the Evidence
     Claims Certificate Extension in the context of attesting to the
     security properties of a key or the platform that manages it.

  3.1.  id-pkix-attest-entity-platform (Platform Attestation)

     *  This attests that the platform hosting the key meets security
        requirements.
     *  Useful when the integrity of the system running cryptographic
        operations is important.
     *  Example: A certificate extension proving the FIPS level at which
        the attestor is currently operating in compliance with.

  3.2.  id-pkix-attest-entity-key (Key Attestation)

     *  This attests to the security properties of a specific
        cryptographic key, regardless of the platform.
     *  Ensures that the key is stored securely and follows cryptographic
        policies.
     *  Example: A certificate extension proving that the private key of
        the certificate is hardware-protected and cannot be exported to a
        software cryptographic module.

  3.3.  ASN.1 Module

     This section provides an ASN.1 Module for the Evidence Claims
     certificate extension, and it follows the conventions established in
     [RFC5912] and [RFC6268].








  Ounsworth, et al.        Expires 28 October 2025                [Page 5]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


     EvidenceClaimsCertExtn
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-evidenceclaims(TBD) }

     DEFINITIONS IMPLICIT TAGS ::= BEGIN

     IMPORTS
         EXTENSION
         FROM PKIX-CommonTypes-2009 -- RFC 5912
             { iso(1) identified-organization(3) dod(6) internet(1)
               security(5) mechanisms(5) pkix(7) id-mod(0)
               id-mod-pkixCommon-02(57) };

     -- Evidence Claims Certificate Extension OID
     id-pe-ar-claims OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-pe(1) 34
     }

     -- Evidence Claims Certificate Extension
     ext-EvidenceClaims EXTENSION ::= {
         SYNTAX AR-Claims
         IDENTIFIED BY id-pe-ar-claims
     }

     -- Evidence Claims Syntax
     AR-Claims ::= SEQUENCE SIZE (1..MAX) OF ReportedEntity

     -- Alignment with PkixAttestation structure
     ReportedEntity ::= SEQUENCE {
         entityType         OBJECT IDENTIFIER,
         reportedAttributes SEQUENCE SIZE (1..MAX) OF ReportedAttribute
     }

     ReportedAttribute ::= SEQUENCE {
         attributeType      OBJECT IDENTIFIER,
         value              AttributeValue
     }

     AttributeValue ::= CHOICE {
         bytes       [0] IMPLICIT OCTET STRING,
         utf8String  [1] IMPLICIT UTF8String,
         bool        [2] IMPLICIT BOOLEAN,
         time        [3] IMPLICIT GeneralizedTime,
         int         [4] IMPLICIT INTEGER,
         oid         [5] IMPLICIT OBJECT IDENTIFIER
     }



  Ounsworth, et al.        Expires 28 October 2025                [Page 6]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


  4.  Security Considerations

     The extension MUST NOT publish in the certificate any privacy-
     sensitive information that could compromise the end device.  What
     counts as privacy-sensitive will vary by use case.  For example:

     1.  *HSM Usage*: For a hardware security module (HSM) backing a
         public code-signing service, the model and firmware patch level
         could be considered sensitive as it could give an attacker an
         advantage in exploiting known vulnerabilities.
     2.  *Mobile Devices*: For a certificate issued to an end-user mobile
         computing device, any unique identifier could be used for
         tracking.
     3.  *IoT Devices*: For small IoT devices, knowing hardware and
         firmware version information could help edge gateways deny access
         to devices with known vulnerabilities.

     The CA MUST have a configurable mechanism to control which
     information is copied from the provided Evidence into the
     certificate, for example, via a certificate profile or Certificate
     Practice Statement (CPS).  CA operators should err on the side of
     caution and exclude unnecessary claims.  Avoiding unnecessary claims
     also mitigates the risk of targeted attacks, where an attacker could
     exploit knowledge of hardware versions, models, etc.

  5.  IANA Considerations

     For the EvidenceClaims certificate extension in Section 3.3, IANA is
     requested to assign an object identifier (OID) for the certificate
     extension.  The OID for the certificate extension should be allocated
     in the "SMI Security for PKIX Certificate Extension" registry
     (1.3.6.1.5.5.7.1).

     For the ASN.1 Module in Section 3.3, IANA is requested to assign an
     object identifier (OID) for the module identifier.  The OID for the
     module should be allocated in the "SMI Security for PKIX Module
     Identifier" registry (1.3.6.1.5.5.7.0).

  6.  References

  6.1.  Normative References

     [I-D.ietf-rats-eat]
                Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", Work in
                Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-eat-31>.



  Ounsworth, et al.        Expires 28 October 2025                [Page 7]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


     [I-D.ietf-rats-pkix-key-attestation]
                Ounsworth, M., Fiset, J., Tschofenig, H., Birkholz, H.,
                Wiseman, M., and N. Smith, "PKIX Key Attestation", Work in
                Progress, Internet-Draft, draft-ietf-rats-pkix-key-
                attestation-00, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                pkix-key-attestation-00>.

     [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/rfc/rfc2119>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [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/rfc/rfc8174>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

  6.2.  Informative References

     [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
                Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
                DOI 10.17487/RFC5912, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5912>.

     [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
                for the Cryptographic Message Syntax (CMS) and the Public
                Key Infrastructure Using X.509 (PKIX)", RFC 6268,
                DOI 10.17487/RFC6268, July 2011,
                <https://www.rfc-editor.org/rfc/rfc6268>.

     [RFC9344]  Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
                Content and Network Information in Content-Centric
                Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023,
                <https://www.rfc-editor.org/rfc/rfc9344>.






  Ounsworth, et al.        Expires 28 October 2025                [Page 8]


  Internet-Draft        X.509 Cert Extensions for ARs           April 2025


  Acknowledgments

     The authors would like to thank ...

  Authors' Addresses

     Mike Ounsworth
     Entrust Limited
     2500 Solandt Road – Suite 100
     Ottawa, Ontario  K2K 3G5
     Canada
     Email: mike.ounsworth@entrust.com


     Monty Wiseman
     Beyond Identity
     United States of America
     Email: monty.wiseman@beyondidentity.com


     Hannes Tschofenig
     University of Applied Sciences Bonn-Rhein-Sieg
     Email: Hannes.Tschofenig@gmx.net


     Tirumaleswar Reddy
     Nokia
     Bangalore
     Karnataka
     India
     Email: kondtir@gmail.com


     Ned Smith
     Intel Corporation
     United States of America
     Email: ned.smith@intel.com














  Ounsworth, et al.        Expires 28 October 2025                [Page 9]


name: draft-ietf-v6ops-nd-considerations
rev: 14
title: Neighbor Discovery Considerations in IPv6 Deployments
time: 2025-11-21T00:01:15Z
group_uri: /api/v1/group/group/1578/
expires: 2025-11-27T08:27:14Z
ad: /api/v1/person/person/112869/
shepherd: /api/v1/person/email/tim@qacafe.com/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:46.403442+00:00
source: ietf
source_id: 111303
source_url: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/
doc_status: active
abstract:
  The Neighbor Discovery (ND) protocol is a critical component of the
     IPv6 architecture. The protocol uses multicast in many messages. It
     also assumes a security model where all nodes on a link are trusted.
     Such a design might be inefficient in some scenarios (e.g., use of
     multicast in wireless networks) or when nodes are not trustworthy
     (e.g., public access networks). These security and operational
     issues and the associated mitigation solutions are documented in
     more than 20 RFCs. There is a need to track these issues and
     solutions in a single document.

     To that aim, this document summarizes the published ND issues and
     then describes how all these issues originate from three causes.
     Addressing the issues is made simpler by addressing the causes. This
     document also analyzes the mitigation solutions and demonstrates
     that isolating hosts into different subnets and links can help to
     address the three causes. Guidance is provided for selecting a
     suitable isolation method to prevent potential ND issues.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/110/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  IPv6 Operations (v6ops) Working Group                           X. Xiao
  Internet Draft                                             E. Vasilenko
  Intended status: Informational                      Huawei Technologies
  Expires: Nov. 2025                                              E. Metz
                                                                      KPN
                                                                G. Mishra
                                                             Verizon Inc.
                                                              N. Buraglio
                                                  Energy Sciences Network
                                                             May 26, 2025

            Neighbor Discovery Considerations in IPv6 Deployments
                    draft-ietf-v6ops-nd-considerations-14


  Abstract

     The Neighbor Discovery (ND) protocol is a critical component of the
     IPv6 architecture. The protocol uses multicast in many messages. It
     also assumes a security model where all nodes on a link are trusted.
     Such a design might be inefficient in some scenarios (e.g., use of
     multicast in wireless networks) or when nodes are not trustworthy
     (e.g., public access networks). These security and operational
     issues and the associated mitigation solutions are documented in
     more than 20 RFCs. There is a need to track these issues and
     solutions in a single document.

     To that aim, this document summarizes the published ND issues and
     then describes how all these issues originate from three causes.
     Addressing the issues is made simpler by addressing the causes. This
     document also analyzes the mitigation solutions and demonstrates
     that isolating hosts into different subnets and links can help to
     address the three causes. Guidance is provided for selecting a
     suitable isolation method to prevent potential ND issues.

  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




  Xiao                    Expires Nov. 26, 2025                  [Page 1]


  Internet-Draft            nd-considerations                    May 2025


     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 in Nov. 2025.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://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
        1.1. Terminology...............................................5
     2. Review of Inventoried ND Issues................................6
        2.1. Multicast May Cause Performance and Reliability Issues....6
        2.2. Trusting-all-hosts May Cause On-link Security Issues......7
        2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE
        Exhaustion, and Address Accountability Issues..................7
        2.4. Summary of ND Issues......................................8
     3. Review of ND Mitigation Solutions..............................9
        3.1. ND Solution in Mobile Broadband IPv6.....................10
        3.2. ND Solution in Fixed Broadband IPv6......................11
        3.3. Unique IPv6 Prefix per Host (UPPH).......................12
        3.4. Wireless ND and Subnet ND................................13
        3.5. Scalable Address Resolution Protocol.....................14
        3.6. ARP and ND Optimization for TRILL........................14
        3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN).15
        3.8. Reducing Router Advertisements...........................15
        3.9. Gratuitous Neighbor Discovery (GRAND)....................15
        3.10. Source Address Validation Improvement (SAVI) and Router
        Advertisement Guard...........................................16
        3.11. RFC 6583 Dealing with NCE Exhaustion Attacks............16
        3.12. Registering Self-generated IPv6 Addresses using DHCPv6..17
        3.13. Enhanced DAD............................................17
        3.14. ND Mediation for IP Interworking of Layer 2 VPNs........17



  Xiao                    Expires Nov. 26, 2025                  [Page 2]


  Internet-Draft            nd-considerations                    May 2025


        3.15. ND Solutions Defined before the Latest Versions of ND...17
           3.15.1. Secure Neighbor Discovery (SeND)...................18
           3.15.2. Cryptographically Generated Addresses (CGA)........18
           3.15.3. ND Proxy...........................................18
           3.15.4. Optimistic DAD.....................................19
     4. Guidelines for Prevention of Potential ND Issues..............19
        4.1. Learning Host Isolation from the Existing Solutions......19
        4.2. Applicability of Various Isolation Methods...............20
           4.2.1. Applicability of L3+L2 Isolation....................20
           4.2.2. Applicability of L3 Isolation.......................22
           4.2.3. Applicability of Partial L2 Isolation...............22
        4.3. Guidelines for Applying Isolation Methods................23
     5. Security Considerations.......................................24
     6. IANA Considerations...........................................24
     7. References....................................................24
        7.1. Normative References.....................................24
        7.2. Informative References...................................24
     8. Acknowledgments...............................................28

  1. Introduction

     Neighbor Discovery (ND) [RFC4861] specifies the mechanisms that IPv6
     nodes (hosts and routers) on the same link use to communicate and
     learn about each other. Stateless Address Autoconfiguration (SLAAC)
     [RFC4862] builds on those ND mechanisms to let nodes configure their
     own IPv6 addresses. When analyzing the issues nodes may encounter
     with ND, it helps to view the ND messages they exchange throughout
     their life-cycle, taking SLAAC into consideration.

     For a host, the overall procedure is as follows:

       1. LLA DAD: The host forms a Link-Local Address (LLA) and performs
          Duplicate Address Detection (DAD) using multicast Neighbor
          Solicitations (NSs).
       2. Router Discovery: The host sends multicast Router Solicitations
          (RSs) to discover a router on the link. The router responds
          with Router Advertisements (RAs), providing subnet prefixes and
          other information. The host installs a Neighbor Cache Entry
          (NCE) for that router upon receiving the RAs. In contrast, the
          router cannot install an NCE for the host at this moment of the
          exchange because the host's global IP address is still unknown.
          When the router later needs to forward a packet to the host's
          global address, it will perform address resolution and install
          an NCE for the host.
       3. GUA DAD: The host forms a Global Unicast Address (GUA)
          [RFC3587] or a Unique Local Address (ULA) [RFC4193] and uses



  Xiao                    Expires Nov. 26, 2025                  [Page 3]


  Internet-Draft            nd-considerations                    May 2025


          multicast NSs for DAD. For simplicity of description, this
          document will not further distinguish GUA and ULA.
       4. Next-hop determination and address resolution: When the host
          needs to send a packet, it will first determine whether the
          next-hop is a router or an on-link host (which is the
          destination). If the next-hop is a router, the host already has
          the NCE for that router. If the next-hop is an on-link host, it
          will use multicast NSs to perform address resolution for the
          destination host. As a result, the source host installs an NCE
          for the destination host.
       5. Node Unreachability Detection (NUD): The host uses unicast NSs
          to determine whether another node with an NCE is still
          reachable.
       6. Link-layer address change announcement: If a host's link-layer
          address changes, it may use multicast Node Advertisements (NAs)
          to announce its new link-layer address to other nodes.

     For a router, the procedure is similar except that there is no
     Router Discovery. Instead, routers perform a Redirect procedure that
     hosts do not have. A router sends a Redirect to inform a node of a
     better next-hop for the node's traffic.

     ND uses multicast in many messages, trusts messages from all nodes,
     and routers may install NCEs for hosts on demand when they are to
     forward packets to these hosts. These may lead to issues.
     Concretely, various ND issues and mitigation solutions have been
     published in more than 20 RFCs, including:

       . ND Trust Models and Threats [RFC3756],
       . Secure ND [RFC3971],
       . Cryptographically Generated Addresses [RFC3972],
       . ND Proxy [RFC4389],
       . Optimistic ND [RFC4429],
       . ND for mobile broadband [RFC6459][RFC7066],
       . ND for fixed broadband [TR177],
       . ND Mediation [RFC6575],
       . Operational ND Problems [RFC6583],
       . Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929][SND],
       . DAD Proxy [RFC6957],
       . Source Address Validation Improvement [RFC7039],
       . Router Advertisement Guard [RFC6105][RFC7113],
       . Enhanced Duplicate Address Detection [RFC7527],
       . Scalable ARP [RFC7586],
       . Reducing Router Advertisements [RFC7772],
       . Unique Prefix Per Host [RFC8273],




  Xiao                    Expires Nov. 26, 2025                  [Page 4]


  Internet-Draft            nd-considerations                    May 2025


       . ND Optimization for Transparent Interconnection of Lots of
          Links (TRILL) [RFC8302],
       . Gratuitous Neighbor Discovery [RFC9131],
       . Proxy ARP/ND for EVPN [RFC9161], and
       . Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
          IPv6 Prefixes per Client in Large Broadcast Networks [RFC9663].

     This document summarizes these RFCs into a one-stop reference (as of
     the time of writing) for easier access. This document also
     identifies three causes of the issues and defines three host
     isolation methods to address the causes and prevent potential ND
     issues.

  1.1. Terminology

     This document uses the terms defined in [RFC4861]. Additional terms
     are defined in this section.

    MAC - To avoid confusion with link-local addresses, link-layer
             addresses are referred to as MAC addresses in this document.

    Host Isolation - separating hosts into different subnets or links.

    L3 Isolation - allocating a unique prefix per host
             [RFC8273][RFC9663] so that every host is in a different
             subnet. Given that a unique prefix can be allocated per host
             on shared media, hosts in different subnets may be on the
             same link.

    L2 Isolation - taking measures to prevent a host from reaching other
             hosts directly in Layer 2 (L2) so that every host is in a
             different link. Due to the existence of Multi-Link Subnet
             [RFC4903], hosts in different links may be in the same
             subnet. Therefore, L2 Isolation does not imply L3 Isolation,
             and L3 Isolation does not imply L2 Isolation either.

    L3+L2 Isolation - applying L3 Isolation and L2 Isolation
             simultaneously so that every host is in a different subnet
             and on a different link.

    Partial L2 Isolation - using an L3 ND proxy [RFC4389] device to
             represent the hosts behind it to other hosts in the same
             subnet. Within the subnet, ND multicast exchange is
             segmented into multiple smaller scopes, each represented by
             an ND proxy device.




  Xiao                    Expires Nov. 26, 2025                  [Page 5]


  Internet-Draft            nd-considerations                    May 2025


  2. Review of Inventoried ND Issues

  2.1. Multicast May Cause Performance and Reliability Issues

     In some cases, ND uses multicast for NSs, NAs, RSs, and RAs. While
     multicast can be highly efficient in certain scenarios, e.g., in
     wired networks, multicast can also be inefficient in other
     scenarios, e.g., in large L2 networks or wireless networks.

     Typically, multicast can create a large amount of protocol traffic
     in large L2 networks. This can consume network bandwidth, increase
     processing overhead, and degrade network performance [RFC7342].

     In wireless networks, multicast can be inefficient or even
     unreliable due to a higher probability of transmission interference,
     lower data rate, and lack of acknowledgements (Section 3.1 of [RFC9119]).

     Multicast-related performance issues of the various ND messages are
     summarized below:

       . Issue 1: LLA DAD Degrading Performance - in an L2 network of N
          addresses (which can be much larger than the number of hosts,
          as each host can have multiple addresses), there can be N such
          multicast messages. This may cause performance issues when N is
          large.
       . Issue 2: Router's Periodic Unsolicited RAs Draining Hosts'
          Battery - multicast RAs are generally limited to one packet
          every MIN_DELAY_BETWEEN_RAS (3 seconds), and there are usually
          only one or two routers on the link, so it is unlikely to cause
          a performance issue. However, for battery-powered hosts, such
          messages may wake them up and drain their batteries [RFC7772].
       . Issue 3: GUA DAD Degrading Performance - same as in Issue 1.
       . Issue 4: Router's Address Resolution for Hosts Degrading
          Performance - same as in Issue 1.
       . Issue 5: Host's Address Resolution for Hosts Degrading
          Performance - same as in Issue 1.
       . (For Further Study) Hosts' MAC Address Change NAs Degrading
          Performance - with randomized and changing MAC addresses
          [MADINAS], there may be many such multicast messages.

     In wireless networks, multicast is more likely to cause packet loss.
     Because DAD treats no response as no duplicate address detected,
     packet loss may cause duplicate addresses to be undetected.
     Multicast reliability issues are summarized below:




  Xiao                    Expires Nov. 26, 2025                  [Page 6]


  Internet-Draft            nd-considerations                    May 2025


       . Issue 6: LLA DAD Not Completely Reliable in Wireless Networks.
       . Issue 7: GUA DAD Not Completely Reliable in Wireless Networks.

     Note: IPv6 address collisions are extremely unlikely. As a result,
     these two issues are largely theoretical rather than practical.

  2.2. Trusting-all-hosts May Cause On-link Security Issues

     In scenarios such as public access networks, some nodes may not be
     trustworthy. An attacker on the link can cause the following on-link
     security issues [RFC3756][RFC9099]:

       . Issue 8: Source IP Address Spoofing - an attacker can use
          another node's IP address as the source address of its ND
          message to pretend to be that node. The attacker can then
          launch various Redirect or Denial-of-Service (DoS) attacks.
       . Issue 9: Denial of DAD - an attacker can repeatedly reply to a
          victim's DAD messages, causing the victim's address
          configuration procedure to fail, resulting in a DoS to the
          victim.
       . Issue 10: Rogue RAs - an attacker can send RAs to victim hosts
          to pretend to be a router. The attacker can then launch various
          Redirect or DoS attacks.
       . Issue 11: Spoofed Redirects - an attacker can send forged
          Redirects to victim hosts to redirect their traffic to the
          legitimate router itself.
       . Issue 12: Replay Attacks - an attacker can capture valid ND
          messages and replay them later.

  2.3. Router-NCE-on-Demand May Cause Forwarding Delay, NCE Exhaustion,
     and Address Accountability Issues

     When a router needs to forward a packet to a node but does not yet
     have a Neighbor-Cache Entry (NCE) for that node, it first creates an
     NCE in the INCOMPLETE state. The router then multicasts an NS to the
     node's solicited-node multicast address. When the destination
     replies with an NA containing its MAC address, the router updates
     the NCE with that address and changes its state to REACHABLE,
     thereby completing the entry. This process is referred to as Router-
     NCE-on-Demand in this document.

     Router-NCE-on-Demand can cause the following issues:

       . Issue 13: NCE Exhaustion - an attacker can send a high volume
          of packets targeting non-existent IP addresses, causing the
          router to create numerous NCEs in the INCOMPLETE state. The



  Xiao                    Expires Nov. 26, 2025                  [Page 7]


  Internet-Draft            nd-considerations                    May 2025


          resulting resource exhaustion may cause the router to
          malfunction. This vulnerability, described as "NCE Exhaustion"
          in this document, does not require the attacker to be on-link.
       . Issue 14: Router Forwarding Delay - when a packet arrives at a
          router, the router buffers it while attempting to determine the
          host's MAC address. This buffering delays forwarding and,
          depending on the router's buffer size, may lead to packet loss.
          This delay is referred to as "Router-NCE-on-Demand Forwarding
          Delay" in this document.
       . Issue 15: Lack of Address Accountability - with SLAAC, hosts
          generate their IP addresses. The router does not become aware
          of a host's IP address until an NCE entry is created. With
          DHCPv6 [RFC8415], the router may not know the host's addresses
          unless it performs DHCPv6 snooping. In public access networks,
          where subscriber management often relies on IP address (or
          prefix) identification, this lack of address accountability
          poses a challenge [AddrAcc]. Without knowledge of the host's IP
          address, network administrators are unable to effectively
          manage subscribers, which is particularly problematic in public
          access networks. Moreover, once a router has created its NCEs,
          ND [RFC4861] provides no mechanism to retrieve them for
          management or monitoring, as noted in Section 2.6.1 of [RFC
          9099].

  2.4. Summary of ND Issues

     The ND issues, as discussed in Sections 2.1 to 2.3, are summarized
     below. These issues stem from three primary causes: multicast,
     Trusting-all-nodes, and Router-NCE-on-Demand. Eliminating any of
     these causes would also mitigate the corresponding issues. These
     observations provide guidance for addressing and preventing ND-
     related issues.

     (1) Multicast-related issues:

       . Performance issues
            o Issue 1: LLA DAD Degrading Performance.
            o Issue 2: Unsolicited RA Draining Host Battery Life.
            o Issue 3: GUA DAD degrading performance.
            o Issue 4: Router Address Resolution for Hosts Degrading
               Performance.
            o Issue 5: Host Address Resolution for Other Hosts Degrading
               Performance.
       . Reliability issues
            o Issue 6: LLA DAD Not Completely Reliable in Wireless
               Networks



  Xiao                    Expires Nov. 26, 2025                  [Page 8]


  Internet-Draft            nd-considerations                    May 2025


            o Issue 7: GUA DAD Not Completely Reliable in Wireless
               Networks

     (2) Trusting-all-nodes related issues:

            o Issue 8: Source IP Address Spoofing
            o Issue 9: Denial of DAD
            o Issue 10: Rogue RAs
            o Issue 11: Spoofed Redirects
            o Issue 12: Replay Attacks

     (3) Router-NCE-on-Demand related issues:

            o Issue 13: NCE Exhaustion
            o Issue 14: Router Forwarding Delay
            o Issue 15: Lack of Address Accountability

     These issues are potential vulnerabilities and may not manifest in
     all usage scenarios.

     When these issues may occur in a specific deployment, it is
     advisable to consider the mitigation solutions available. They are
     described in the following section.

  3. Review of ND Mitigation Solutions

     Table 1 summarizes ND mitigation solutions available for Issues 1-15
     described in Section 2.4. Similar solutions are grouped, beginning
     with those that address the most issues. Unrelated solutions are
     ordered based on the issues (listed in Section 2.4) they address.
     Each solution in the table will be explained in a sub-section later,
     where abbreviations in the table are described.

     In the table, a letter code indicates the RFC category of the
     mitigation solution (see BCP 9 [RFC2026] for explanation of these
     categories):

       S - Standards Track (Proposed Standard, Draft Standard, or
       Internet Standard)
       E - Experimental
       I - Informational
       B - Best Current Practice
       U - Unknown (not formally defined by the IETF)

    +-----+---+-------------------+--------+-------+-------+------+-----+
    |ND   |RFC|     Multicast     | Reli-  |On-link|NCE    |Fwd.  |No A.|
    |solu-|ty-|     performance   | ability|securi.|Exhau. |Delay |Acct.|


  Xiao                    Expires Nov. 26, 2025                  [Page 9]


  Internet-Draft            nd-considerations                    May 2025


    |tion |pe |---+---+---+---+---+---+----+-------+-------+------+-----+
    |     |   | 1 | 2 | 3 | 4 | 5 | 6 |  7 |  8-12 |   13  |  14  | 15  |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |MBBv6| I |            All identified issues solved                 |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |FBBv6| U |            All identified issues solved                 |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |UPPH | I |   | X |   | X | X |   |  X |       |   X   |   X  |  X  |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |WiND | S |All issues solved for Low-Power and Lossy Networks (LLNs)|
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |SARP | E |   |   |   |   | X |   |    |       |       |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |ND   | S |   |   |   |   | X |   |    |       |       |      |     |
    |TRILL|   |   |   |   |   |   |   |    |       |       |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |ND   | S |   |   |   |   | X |   |    |       |       |      |     |
    |EVPN |   |   |   |   |   |   |   |    |       |       |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |7772 | B |   | X |   |   |   |   |    |       |       |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |GRAND| S |   |   |   | X |   |   |    |       |       |  X   |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |SAVI/|   |   |   |   |   |   |   |    |       |       |      |     |
    |RA   | I |   |   |   |   |   |   |    |   X   |       |      |     |
    |G/G+ |   |   |   |   |   |   |   |    |       |       |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |6583 | I |   |   |   |   |   |   |    |       |   X   |      |     |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
    |9686 | S |   |   |   |   |   |   |    |       |       |      |  X  |
    +-----+---+---+---+---+---+---+---+----+-------+-------+------+-----+
                   Table 1. Solutions for identified issues

  3.1. ND Solution in Mobile Broadband IPv6

     The IPv6 solution defined in "IPv6 in 3GPP EPS" [RFC6459], "IPv6 for
     3GPP Cellular Hosts" [RFC7066], and "Extending an IPv6 /64 Prefix
     from a Third Generation Partnership Project (3GPP) Mobile Interface
     to a LAN Link" [RFC7278] is called Mobile Broadband IPv6 (MBBv6) in
     this document. They are Informational RFCs. The key points are:

       . Putting every host, e.g., the mobile User Equipment (UE), in a
          Point-to-Point (P2P) link with the router, e.g., the mobile
          gateway. Consequently:
            o All multicast is effectively turned into unicast.
            o The P2P links do not have a MAC address. Therefore, Router-
               NCE-on-Demand is not needed.


  Xiao                    Expires Nov. 26, 2025                 [Page 10]


  Internet-Draft            nd-considerations                    May 2025


            o Trusting-all-nodes is only relevant to the router. By
               applying filtering at the router, e.g., dropping RAs from
               the hosts, even malicious hosts cannot cause harm.
       . Assigning a unique /64 prefix to each host. Together with the
          P2P link, this puts each host on a separate link and subnet.
       . Maintaining (prefix, interface) binding at the router for
          forwarding purposes.

     Since all the three causes of ND issues are addressed, all the
     issues discussed in Section 2.4 are addressed.

  3.2. ND Solution in Fixed Broadband IPv6

     The IPv6 solution defined in "IPv6 in the context of TR-101" [TR177]
     is called Fixed Broadband IPv6 (FBBv6) in this document. FBBv6 has
     two flavors:

       . P2P: Every host, e.g., the Residential Gateway (RG), is in a
          P2P link with the router, e.g., the Broadband Network Gateway
          (BNG). In this case, the solution is functionally similar to
          MBBv6. All ND issues discussed in Section 2.4 are solved.
       . Point-to-Multi-Point (P2MP): All hosts, e.g., the RGs,
          connected to an access device, e.g., the Optical Line Terminal
          (OLT), are in a P2MP link with the router, e.g., the BNG.  This
          is achieved by placing all hosts in a single VLAN on the router
          and configuring the OLT to block any frame from being forwarded
          between its access ports; traffic from each host can travel
          only up toward the router, not sideways to another host,
          thereby preventing direct host-to-host communication.

     The following summarizes the two key aspects of the FBBv6-P2MP
     architecture as described in [TR177] and the associated benefits:

       . Implementing DAD Proxy [RFC6957]:

         In a P2MP architecture described above, the normal ND DAD
         procedure will breaks down because hosts cannot exchange NSs
         with one another. To address this, the router participates in
         the DAD process as a DAD Proxy to resolve address duplication.

         The benefits are:

            o Multicast traffic from all hosts to the router is
               effectively converted into unicast, as hosts can only
               communicate directly with the router.




  Xiao                    Expires Nov. 26, 2025                 [Page 11]


  Internet-Draft            nd-considerations                    May 2025


            o The Trusting-all-nodes model is limited to the router. By
               applying simple filtering, e.g., dropping RAs from hosts,
               the router can mitigate security risks, even from
               malicious hosts

       . Assigning a unique /64 prefix to each host:

         Assigning each host a unique /64 prefix results in several
         operational improvements:

            o The router can proactively install a forwarding entry for
               that prefix towards the host, eliminating the need for
               Router-NCE-on-Demand.
            o Since each host resides in a different subnet, traffic
               between hosts is routed through the router, eliminating
               the need for hosts to perform address resolution for one
               another.
            o Without address resolution, router multicast to hosts is
               limited to unsolicited RAs. As each host resides in its
               own subnet, these RAs are sent as unicast packets to
               individual hosts. This follows the approach specified in
               [RFC6085], where the host's MAC address replaces the
               multicast MAC address in the RA.

     Since all three causes of ND issues are addressed, all ND issues
     (Section 2.4) are also addressed.

  3.3. Unique IPv6 Prefix per Host (UPPH)

     UPPH solutions are described in [RFC8273] and [RFC9663]. Both are
     Informational RFCs. [RFC8273] relies on SLAAC for unique prefix
     allocation while [RFC9663] relies on DHCP-PD. That difference in
     allocation mechanism does not change the discussion on ND issues,
     because every IPv6 node is still required to run SLAAC, even when it
     receives its prefix via DHCP-PD. Therefore, discussing [RFC8273]
     alone is sufficient.

     [RFC8273] "improves host isolation and enhanced subscriber
     management on shared network segments" such as Wi-Fi or Ethernet.
     The key points are:

       . When a prefix is allocated to the host, the router can
          proactively install a forwarding entry for that prefix towards
          the host.  There is no more Router-NCE-on-Demand.





  Xiao                    Expires Nov. 26, 2025                 [Page 12]


  Internet-Draft            nd-considerations                    May 2025


       . Without address resolution, router multicast to hosts consists
          only of unsolicited RAs. They will be sent to hosts one by one
          in unicast because the prefix for every host is different.
       . Since different hosts are in different subnets, hosts will send
          traffic to other hosts via the router. There is no host-to-host
          address resolution.

     Therefore, ND issues caused by Router-NCE-on-Demand and router
     multicast to hosts are prevented.

     [RFC8273] indicates that a "network implementing a unique IPv6
     prefix per host can simply ensure that devices cannot send packets
     to each other except through the first-hop router". But when hosts
     are on a shared medium like Ethernet, ensuring "devices cannot send
     packets to each other except through the first-hop router" requires
     additional measures like Private VLAN [RFC5517]. Without such
     additional measures, on a shared medium, hosts can still reach each
     other in L2 as they belong to the same Solicited-Node Multicast
     Group. Therefore, Trusting-all-nodes and host multicast to routers
     may cause issues. Of the host multicast issues (i.e., Issues 1, 3,
     5, 6, and 7), Unique Prefix per Host prevents Issues 5 and 7,
     because there is no need for address resolution among hosts (Issue
     5) and there is no possibility of GUA duplication (Issue 7). But
     Issues 1, 3, and 6 may occur.

  3.4. Wireless ND and Subnet ND

     Wireless ND (WiND) [RFC6775][RFC8505][RFC8928][RFC8929] (Standards
     Track) defines a fundamentally different ND solution for Low-Power
     and Lossy Networks (LLNs) [RFC7102]. WiND changes host and router
     behaviors to use multicast only for router discovery. The key points
     are:

       . Hosts use unicast to proactively register their addresses at
          the routers. Routers use unicast to communicate with hosts and
          become an abstract registrar and arbitrator for address
          ownership.
       . The router also proactively installs NCEs for the hosts. This
          avoids the need for address resolution for the hosts.
       . The router sets Prefix Information Option (PIO) L-bit to 0.
          Each host communicates only with the router (Section 6.3.4 of
          [RFC4861]).
       . Other functionalities that are relevant only to LLNs.

     WiND addresses all ND issues (Section 2.4) in LLNs. However, WiND
     support is not mandatory for general-purpose hosts. Therefore, it



  Xiao                    Expires Nov. 26, 2025                 [Page 13]


  Internet-Draft            nd-considerations                    May 2025


     cannot be relied upon as a deployment option without imposing
     additional constraints on the participating nodes.

  3.5. Scalable Address Resolution Protocol

     Scalable Address Resolution Protocol [RFC7586] was an Experimental
     solution. That experiment ended in 2017, two years after the RFC was
     published. Because the idea has been used in mitigation solutions
     for more specific scenarios (described in Sections 3.6 and 3.7), it
     is worth describing here. The usage scenario is Data Centers (DCs),
     where large L2 domains span across multiple sites. In each site,
     multiple hosts are connected to a switch. The hosts can be Virtual
     Machines (VMs), so the number can be large.  The switches are
     interconnected by a native or overlay L2 network.

     The switch will snoop and install (IP, MAC address) proxy table for
     the local hosts. The switch will also reply to address resolution
     requests from other sites to its hosts with its own MAC address. In
     doing so, all hosts within a site will appear to have a single MAC
     address to other sites. As such, a switch only needs to build a MAC
     address table for the local hosts and the remote switches, not for
     all the hosts in the L2 domain. Consequently, the MAC address table
     size of the switches is significantly reduced. A switch will also
     add the (IP, MAC address) replies from remote switches to its proxy
     ND table so that it can reply to future address resolution requests
     from local hosts for such IPs directly. This greatly reduces the
     number of address resolution multicast in the network.

     Unlike MBBv6, FBBv6, and UPPH, which try to address all ND issues
     discussed in Section 2.4, SARP focuses on reducing address
     resolution multicast to improve the performance and scalability of
     large L2 domains in DCs.

  3.6. ARP and ND Optimization for TRILL

     ARP and ND Optimization for TRILL [RFC8302] (Standards Track) is
     similar to SARP (Section 3.5). It can be considered an application
     of SARP in the TRILL environment.

     Like SARP, ARP, and ND Optimization for TRILL focuses on reducing
     multicast address resolution. That is, it addresses Issue 5 (Section
     2.1).







  Xiao                    Expires Nov. 26, 2025                 [Page 14]


  Internet-Draft            nd-considerations                    May 2025


  3.7. Proxy ARP/ND in Ethernet Virtual Private Networks (EVPN)

     Proxy ARP/ND in EVPN is specified in [RFC9161] (Standards Track).
     The usage scenario is DCs where large L2 domains span across
     multiple sites. In each site, multiple hosts are connected to a
     Provider Edge (PE) router.  The PEs are interconnected by EVPN
     tunnels.

     PE of each site snoops the local address resolution NAs to build
     (IP, MAC address) Proxy ND table entries. PEs then propagate such
     Proxy ND entries to other PEs via the Border Gateway Protocol (BGP).
     Each PE also snoops local hosts' address resolution NSs for remote
     hosts. If an entry exists in its Proxy ND table for the remote
     hosts, the PE will reply directly.  Consequently, the number of
     multicast address resolution messages is significantly reduced.

     Like SARP, Proxy ARP/ND in EVPN also focuses on reducing address
     resolution multicast.

  3.8. Reducing Router Advertisements

     Maintaining IPv6 connectivity requires that hosts be able to receive
     periodic multicast RAs [RFC4861].  Hosts that process unicast
     packets while they are asleep must also process multicast RAs while
     they are asleep. An excessive number of RAs can significantly reduce
     the battery life of mobile hosts. [RFC7772] (Best Current Practice)
     specifies a solution to reduce RAs:

       . The router should respond to RS with unicast RA (rather than
          the normal multicast RA) if the host's source IP address is
          specified and the host's MAC address is valid. This way, other
          hosts will not receive this RA.
       . The router should reduce the multicast RA frequency

     [RFC7772] addresses Issue 2 (Section 2.1).

  3.9. Gratuitous Neighbor Discovery (GRAND)

     GRAND [RFC9131] (Standards Track) changes ND in the following ways:

       . A node sends unsolicited NAs upon assigning a new IPv6 address
          to its interface.
       . A router creates a new NCE for the node and sets its state to
          STALE.





  Xiao                    Expires Nov. 26, 2025                 [Page 15]


  Internet-Draft            nd-considerations                    May 2025


     When a packet for the host later arrives, the router can use the
     existing STALE NCE to forward it immediately ([RFC4861] Section
     7.2.2). It then verifies reachability by sending a unicast NS rather
     than a multicast one for address resolution. In this way, GRAND
     eliminates the Router Forwarding Delay. But it does not solve other
     Router-NCE-on-Demand issues. For example, NCE Exhaustion can still
     happen.

  3.10. Source Address Validation Improvement (SAVI) and Router
     Advertisement Guard

     SAVI [RFC7039] (Informational) binds an address to a port on an L2
     switch and rejects claims from other ports for that address.
     Therefore, a node cannot spoof the IP address of another node.

     Router Advertisement Guard (RA-Guard) [RFC6105][RFC7113]
     (Informational) only allows RAs from a port that a router is
     connected to. Therefore, nodes on other ports cannot pretend to be a
     router.

     SAVI and RA-Guard address the on-link security issues.

  3.11. RFC 6583 Dealing with NCE Exhaustion Attacks

     [RFC6583] (Informational) deals with the NCE Exhaustion attack issue
     (Section 2.3). It recommends that:

       . Operators should
            o Filter unused address space so that messages to such
               addresses can be dropped rather than triggering NCE
               creation.
            o Implement rate-limiting mechanisms for ND message
               processing to prevent CPU and memory resources from being
               overwhelmed.
       . Vendors should
            o Prioritizing NDP processing for existing NCEs over creating
               new NCEs

     [RFC6583] acknowledges that "some of these options are 'kludges',
     and can be operationally difficult to manage". [RFC6583] partially
     addresses the Router NCE Exhaustion issue. In practice, router
     vendors cap the number of NCEs per interface to prevent cache
     exhaustion. If the link has more addresses than that cap, the router
     cannot keep an entry for every address, and packets destined for
     addresses without an NCE are simply dropped [RFC9663].




  Xiao                    Expires Nov. 26, 2025                 [Page 16]


  Internet-Draft            nd-considerations                    May 2025


  3.12. Registering Self-generated IPv6 Addresses using DHCPv6

     In IPv4, network administrators can retrieve a host's IP address
     from the DHCP server and use it for subscriber management. In IPv6
     and SLAAC, this is not possible (Section 2.3).

     [RFC9686] (Standards Track) defines a method for informing a DHCPv6
     server that a host has one or more self-generated or statically
     configured addresses. This enables network administrators to
     retrieve the IPv6 addresses for each host from the DHCPv6 server.
     [RFC9686] provides a solution for Issue 15 (Section 2.3).

  3.13. Enhanced DAD

     Enhanced DAD [RFC7527] (Standards Track) addresses a DAD failure
     issue in a specific situation: a looped back interface. DAD will
     fail in a looped-back interface because the sending host will
     receive the DAD message back and will interpret it as another host
     is trying to use the same address. The solution is to include a
     Nonce option [RFC3971] in each DAD message so that the sending host
     can detect that the looped-back DAD message is sent by itself.

     Enhanced DAD does not solve any ND issue. It extends ND to work in a
     new scenario: looped-back interface. It is reviewed here only for
     completeness.

  3.14. ND Mediation for IP Interworking of Layer 2 VPNs

     ND mediation is specified in [RFC6575] (Standards Track). When two
     Attachment Circuits (ACs) are interconnected by a Virtual Private
     Wired Service (VPWS), and the two ACs are of different media (e.g.,
     one is Ethernet while the other is Frame Relay), the two PEs must
     interwork to provide mediation service so that a Customer Edge (CE)
     can resolve the MAC address of the remote end. [RFC6575] specifies
     such a solution.

     ND Mediation does not address any ND issue. It extends ND to work in
     a new scenario: two ACs of different media interconnected by a VPWS.
     It is reviewed here only for completeness.

  3.15. ND Solutions Defined before the Latest Versions of ND

     The latest versions of ND and SLAAC are specified in [RFC4861] and
     [RFC4862]. Several ND mitigation solutions were published before
     [RFC4861]. They are reviewed in this section only for completeness.




  Xiao                    Expires Nov. 26, 2025                 [Page 17]


  Internet-Draft            nd-considerations                    May 2025


  3.15.1. Secure Neighbor Discovery (SeND)

     The purpose of SeND [RFC3971] (Standards Track) is to ensure that
     hosts and routers are trustworthy. SeND defined three new ND
     options, i.e., Cryptographically Generated Addresses (CGA) [RFC3972]
     (Standards Track), RSA public-key cryptosystem, and Timestamp/Nonce,
     an authorization delegation discovery process, an address ownership
     proof mechanism, and requirements for the use of these components in
     the ND protocol.

  3.15.2. Cryptographically Generated Addresses (CGA)

     The purpose of CGA is to associate a cryptographic public key with
     an IPv6 address in the SeND protocol. The key point is to generate
     the Interface Identifier (IID) of an IPv6 address by computing a
     cryptographic hash of the public key.  The resulting IPv6 address is
     called a CGA.  The corresponding private key can then be used to
     sign messages sent from the address.

     CGA assumes that a legitimate host does not care about the bit
     combination of the IID that would be created by some hash procedure.
     The attacker needs an exact IID to impersonate the legitimate hosts,
     but then the attacker is challenged to do a reverse hash calculation
     which is a strong mathematical challenge.

     CGA is part of SeND. There is no reported deployment.

  3.15.3. ND Proxy

     ND Proxy [RFC4389] (Experimental) aims to enable multiple links
     joined by an ND Proxy device to work as a single link.

       . When an ND Proxy receives an ND request from a host on a link,
          it will proxy the message out the "best" (defined in the next
          paragraph) outgoing interface. If there is no best interface,
          the ND Proxy will proxy the message to all other links. Here,
          proxy means acting as if the ND message originates from the ND
          Proxy itself. That is, the ND Proxy will change the ND
          message's source IP and source MAC address to the ND Proxy's
          outgoing interface's IP and MAC address, and create an NCE
          entry at the outgoing interface accordingly.
       . When ND Proxy receives an ND reply, it will act as if the ND
          message is destined for itself, and update the NCE entry state
          at the receiving interface. Based on such state information,
          the ND Proxy can determine the "best" outgoing interface for




  Xiao                    Expires Nov. 26, 2025                 [Page 18]


  Internet-Draft            nd-considerations                    May 2025


          future ND requests. The ND Proxy then proxies the ND message
          back to the requesting host.

     ND Proxy is widely used in SARP (Sections 3.5), ND Optimization for
     TRILL (Sections 3.6), and Proxy ARP/ND in EVPN (Sections 3.7).

  3.15.4. Optimistic DAD

     Optimistic DAD [RFC4429] (Standards Track) seeks to minimize address
     configuration delays in the successful case and to reduce disruption
     as far as possible in the failure case. That is, Optimistic DAD lets
     hosts immediately use the newly formed address to communicate before
     DAD completes, assuming that DAD will succeed anyway. If the address
     turns out to be duplicate, Optimistic DAD provides a set of
     mechanisms to minimize the impact. Optimistic DAD modified the
     original ND [RFC2461] and SLAAC [RFC2462], but the solution was not
     incorporated into the latest specifications of [RFC4861] and
     [RFC4862]. However, implementations of Optimistic DAD exist.

     Optimistic DAD does not solve any ND issue (Section 2). It is
     reviewed here only for completeness.

  4. Guidelines for Prevention of Potential ND Issues

     By knowing the potential ND issues and associated mitigation
     solutions, network administrators of existing IPv6 deployments can
     assess whether these issues may occur in their networks and, if so,
     whether to deploy the mitigation solutions proactively. Deploying
     these solutions may take time and additional resources. Therefore,
     it is advisable to plan.

     Network administrators planning to start their IPv6 deployments can
     use the issue-solution information to help plan their deployments.
     Moreover, they can take proactive action to prevent potential ND
     issues.

  4.1. Learning Host Isolation from the Existing Solutions

     While various ND solutions may initially appear unrelated,
     categorizing them into four distinct groups highlights an important
     observation: "host isolation" is an effective strategy for
     mitigating ND-related issues.

     Group 1: L3 and L2 Isolation





  Xiao                    Expires Nov. 26, 2025                 [Page 19]


  Internet-Draft            nd-considerations                    May 2025


     This group includes MBBv6 and FBBv6, which isolate hosts at both L3
     and L2 by placing each host within its subnet and link. This
     prevents ND issues caused by multicast and Trusting-all-nodes, as
     each host operates within its isolated domain. Furthermore, since
     routers can route packets to a host based on its unique prefix, the
     need for Router-NCE-on-Demand is also eliminated. Therefore, L3 and
     L2 Isolation prevent all ND issues.

     Group 2: L3 Isolation

     This group includes UPPH solutions like [RFC8273] and [RFC9663],
     which isolate hosts into separate subnets while potentially leaving
     them on the same shared medium. This approach mitigates ND issues
     caused by router multicast to hosts and eliminates the need for
     "Router-NCE-on-Demand", as detailed in Section 3.3.

     Group 3: Partial L2 Isolation

     This group encompasses solutions such as WiND, SARP, ND Optimization
     for TRILL, and Proxy ND in EVPN. These solutions use a proxy device
     to represent the hosts behind it, effectively isolating those hosts
     into distinct multicast domains. While hosts are still located
     within the same subnet, their separation into different multicast
     domains reduces the scope of ND issues related to multicast-based
     address resolution.

     Group 4: Non-Isolating Solutions

     The final group includes remaining solutions that do not implement
     host isolation. These solutions do not prevent ND issues but instead
     focus on addressing specific ND problems.

     The analysis demonstrates that the stronger the isolation of hosts,
     the more ND issues can be mitigated. This correlation is intuitive,
     as isolating hosts reduces the multicast scope, minimizes the number
     of nodes that must be trusted, and may eliminate the need for
     "Router-NCE-on-Demand", the three primary causes of ND issues.

     This understanding can be used to prevent ND issues.

  4.2. Applicability of Various Isolation Methods

  4.2.1. Applicability of L3+L2 Isolation

     Benefits:




  Xiao                    Expires Nov. 26, 2025                 [Page 20]


  Internet-Draft            nd-considerations                    May 2025


    o  All ND issues (Section 2.4) can be effectively mitigated.

     Constraints:

     1. L2 Isolation:

     Actions must be taken to isolate hosts in L2. The required effort
     varies by the chosen method and deployment context. For example, the
     P2P method [RFC7066] is heavy-weight, while the Private VLAN method
     [RFC5517] is more manageable.

     2. Unique Prefix Allocation:

     A large number of prefixes will be required, with one prefix
     assigned per host. This is generally not a limitation for IPv6. For
     instance, members of a Regional Internet Registry (RIR) can obtain a
     /29 prefix allocation [RIPE738], which provides 32 billion /64
     prefixes - sufficient for any foreseeable deployment scenarios.
     Practical implementations, such as MBBv6 assigning /64 prefixes to
     billions of mobile UEs [RFC6459] and FBBv6 assigning /56 prefixes to
     hundreds of millions of routed RGs [TR177], demonstrate the
     feasibility of this approach.

     3. Privacy Issue from Unique Prefix Identifiability:

     Assigning a unique prefix to each host may theoretically reduce
     privacy, as hosts can be directly identified by their assigned
     prefix. However, alternative host identification methods, such as
     cookies, are commonly used. Therefore, unique prefix identifiability
     may not make much difference. The actual impact on privacy is
     therefore likely to be limited.

     4. Router Support for L3 Isolation:

     The router must support an L3 Isolation solution, e.g., [RFC8273] or
     [RFC9663].

     5. A Large Number of Router Interfaces May be Needed:

     If the P2P method is used, the router must instantiate a separate
     logical interface for every attached host. In this case, a large
     number of interfaces will be needed at the router.

     6. Router as a Bottleneck:





  Xiao                    Expires Nov. 26, 2025                 [Page 21]


  Internet-Draft            nd-considerations                    May 2025


     Since all communication between hosts is routed through the router,
     the router may become a performance bottleneck in high-traffic
     scenarios.

     7. Incompatibility with Host-Based Multicast Services:

     Services that rely on multicast communication among hosts, such as
     Multicast Domain Name System [RFC6762], will be disrupted.

  4.2.2. Applicability of L3 Isolation

     Benefits:

       . All ND issues (Section 2.4) are mitigated, with the exception
          of:
            o LLA DAD multicast degrading performance,
            o LLA DAD not reliable in wireless networks, and
            o On-link security

         These remaining issues depend on the characteristics of the
         shared medium:

            o If the shared medium is Ethernet, the issues related to LLA
               DAD multicast are negligible.
            o If nodes can be trusted, such as in private networks, on-
               link security concerns are not significant.

       . No need for L2 Isolation. Consequently, this method can be
          applied in a wide range of scenarios, making it possibly the
          most practical host isolation method.

     Constraints, as discussed in Section 4.2.1:

     1. Unique Prefix Allocation

     2. Router Support for L3 Isolation

     3. Router as a Bottleneck

     4. Privacy Issue from Unique Prefix Identifiability.

  4.2.3. Applicability of Partial L2 Isolation

     Benefits:

       . Reduced Multicast Traffic:



  Xiao                    Expires Nov. 26, 2025                 [Page 22]


  Internet-Draft            nd-considerations                    May 2025


         This method reduces multicast traffic, particularly for address
         resolution, by dividing the subnet into multiple multicast
         domains.

     Constraint:

       . Router Support for Partial L2 Isolation:

     The router must implement a Partial L2 Isolation solution such as
     WiND, SARP, ND Optimization for TRILL, and Proxy ND in EVPN to
     support this method.

  4.3. Guidelines for Applying Isolation Methods

     Based on the applicability analysis provided in the preceding
     sections, network administrators can determine whether to implement
     an isolation method and, if so, which method is most appropriate for
     their specific deployment.

     A simple guideline is to consider the isolation methods in the order
     listed in the preceding sections, progressing from the strongest
     isolation to the weakest:

       . Stronger isolation methods can prevent more ND issues, but may
          also impose higher entry requirements.
       . Weaker isolation methods have fewer entry requirements but may
          leave some ND issues unmitigated.

     The choice between L3+L2 Isolation and L3 Isolation often depends on
     the cost of implementing L2 Isolation:

       . If the cost is acceptable, L3+L2 Isolation is preferable
          because it eliminates every ND issue listed in Section 2.4.
       . Otherwise, L3 Isolation addresses most of those issues while
          keeping the implementation effort reasonable.

     Selecting an isolation method that is either too strong or too weak
     does not result in serious consequences:

       . Choosing an overly strong isolation method may require the
          network administrator to meet higher entry requirements
          initially, such as measures for L2 Isolation, additional
          prefixes, or additional router capabilities.
       . Choosing a "weaker isolation method" may necessitate deploying
          supplemental ND mitigation techniques to address any unresolved
          ND issues.



  Xiao                    Expires Nov. 26, 2025                 [Page 23]


  Internet-Draft            nd-considerations                    May 2025


     In either case, the resulting solution can be functional and
     effective.

  5. Security Considerations

     This document is a review of known ND issues and solutions,
     including security. It does not introduce any new solutions.
     Therefore, it does not introduce new security issues.

  6. IANA Considerations

     This document has no request to IANA.

  7. References

  7.1. Normative References

     [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861.

     [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
               Address Autoconfiguration", RFC 4862.

  7.2. Informative References

     [AddrAcc] T. Chown, C. Cummings, D.Carder, "IPv6 Address
               Accountability Considerations", Internet draft, Oct. 2024.

     [MADINAS] J. Henry, Y. Lee, "Randomized and Changing MAC Address:
               Context, Network Impacts, and Use Cases", draft-ietf-
               madinas-use-cases-19.

     [RFC2026] S. Bradner, "The Internet Standards Process -- Revision
               3", RFC 2026.

     [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery
               for IP Version 6 (IPv6)", RFC 2461, obsoleted by RFC 4861.

     [RFC2462] S. Thomson, T. Narten, "IPv6 Stateless Address
               Autoconfiguration", RFC 2462, obsoleted by RFC 4862.

     [RFC3587] R. Hinden, S. Deering, E. Nordmark, "IPv6 Global Unicast
               Address Format", RFC 3587.

     [RFC3756] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
               Discovery (ND) Trust Models and Threats", RFC 3756.



  Xiao                    Expires Nov. 26, 2025                 [Page 24]


  Internet-Draft            nd-considerations                    May 2025


     [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
               Discovery (SEND)", RFC3971.

     [RFC3972] T. Aura, "Cryptographically Generated Addresses (CGA)",
               RFC3972.

     [RFC4193] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC 4193.

     [RFC4389] D. Thaler, M. Talwar, C. Patel, "Neighbor Discovery
               Proxies (ND Proxy)", RFC 4389.

     [RFC4429] N. Moore, "Optimistic Duplicate Address Detection (DAD)
               for IPv6", RFC 4429.

     [RFC4903] D. Thaler, "Multi-Link Subnet Issues", RFC 4903.

     [RFC5517] S. HomChaudhuri, M. Foschiano, "Cisco Systems' Private
               VLANs: Scalable Security in a Multi-Client Environment",
               RFC 5517.

     [RFC6085] S. Gundavelli, M. Townsley, O. Troan, W. Dec, "Address
               Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085.

     [RFC6105] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
               Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105.

     [RFC6459] J. Korhonen, J. Soininen, B. Patil, T. Savolainen, G.
               Bajko, K. Iisakkila, "IPv6 in 3rd Generation Partnership
               Project (3GPP) Evolved Packet System (EPS)", RFC 6459.

     [RFC6575] H. Shah, E. Rosen, G. Heron, V. Kompella, "Address
               Resolution Protocol (ARP) Mediation for IP Interworking of
               Layer 2 VPNs", RFC 6575.

     [RFC6583] I. Gashinsky, J. Jaeggli, W. Kumari, "Operational Neighbor
               Discovery Problems", RFC 6583.

     [RFC6762] S. Cheshire, M. Krochmal, "Multicast DNS", RFC 6762.

     [RFC6775] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann,
               "Neighbor Discovery Optimization for IPv6 over Low-Power
               Wireless Personal Area Networks (6LoWPANs)", RFC 6775.

     [RFC6957] F. Costa, J-M. Combes, X. Pougnard, H. Li, "Duplicate
               Address Detection Proxy", RFC 6957



  Xiao                    Expires Nov. 26, 2025                 [Page 25]


  Internet-Draft            nd-considerations                    May 2025


     [RFC7039] J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, "Source
               Address Validation Improvement (SAVI) Framework", RFC
               7039.

     [RFC7066] J. Korhonen, J. Arkko, T. Savolainen, S. Krishnan, "IPv6
               for Third Generation Partnership Project (3GPP) Cellular
               Hosts", RFC 7066.

     [RFC7102] JP. Vasseur, "Terms Used in Routing for Low-Power and
               Lossy Networks", RFC 7102.

     [RFC7113] F. Gont, "Implementation Advice for IPv6 Router
               Advertisement Guard (RA-Guard)", RFC 7113.

     [RFC7278] Extending an IPv6 /64 Prefix from a Third Generation
               Partnership Project (3GPP) Mobile Interface to a LAN
               Link", RFC7278.

     [RFC7342] L. Dunbar, W. Kumari, I. Gashinsky, "Practices for Scaling
               ARP and Neighbor Discovery (ND) in Large Data Centers",
               RFC 7342.

     [RFC7527] R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W.
               George, "Enhanced Duplicate Address Detection", RFC 7527.

     [RFC7586] Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi, "The
               Scalable Address Resolution Protocol (SARP) for Large Data
               Centers", RFC7586.

     [RFC7772] A. Yourtchenko, L. Colitti, "Reducing Energy Consumption
               of Router Advertisements", RFC 7772.

     [RFC8273] J. Brzozowski, G. Van de Velde, "Unique IPv6 Prefix per
               Host", RFC 8273.

     [RFC8302] Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair,
               "Transparent Interconnection of Lots of Links (TRILL): ARP
               and Neighbor Discovery (ND) Optimization", RFC 8302.

     [RFC8415] T. Mrugalski, M. Siodelski, A. Yourtchenko, M. Richardson,
               S. Jiang, T. Lemon, T. Winters, "Dynamic Host
               Configuration Protocol for IPv6 (DHCPv6)", RFC 8415.







  Xiao                    Expires Nov. 26, 2025                 [Page 26]


  Internet-Draft            nd-considerations                    May 2025


     [RFC8505] P. Thubert, E. Nordmark, S. Chakrabarti, C. Perkins,
               "Registration Extensions for IPv6 over  Low-Power Wireless
               Personal Area Network (6LoWPAN) Neighbor Discovery", RFC
               8505.

     [RFC8928] P. Thubert, B. Sarikaya, M. Sethi, R. Struik, "Address-
               Protected Neighbor Discovery for Low-Power and Lossy
               Networks", RFC 8928.

     [RFC8929] P. Thubert, C.E. Perkins, E. Levy-Abegnoli, "IPv6 Backbone
               Router", RFC 8929.

     [RFC9099] E. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey, "Operational
               Security Considerations for IPv6 Networks", RFC 9099.

     [RFC9119] C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zuniga,
               "Multicast Considerations over IEEE 802 Wireless Media",
               RFC 9119.

     [RFC9131] J. Linkova, "Gratuitous Neighbor Discovery: Creating
               Neighbor Cache Entries on First-Hop Routers", RFC 9131.

     [RFC9161] J. Rabadan, S. Sathappan, K. Nagaraj, G. Hankins, T. King,
               "Operational Aspects of Proxy ARP/ND in Ethernet Virtual
               Private Networks", RFC 9161.

     [RFC9663] L. Colitti, J. Linkova, X. Ma, "Using DHCP-PD to Allocate
               Unique IPv6 Prefix per Client in Large Broadcast
               Networks", RFC 9663.

     [RFC9686] W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova,
               S. Jiang, "Registering Self-generated IPv6 Addresses using
               DHCPv6", RFC 9686.

     [RIPE738] IPv6 Address Allocation and Assignment Policy,
               https://www.ripe.net/publications/docs/ripe-738

     [SND]     P. Thubert, M. Richardson, "Architecture and Framework for
               IPv6 over Non-Broadcast Access", Internet draft, June
               2023.

     [TR177] S. Ooghe, B. Varga, W. Dec, D. Allan, "IPv6 in the context
               of TR-101", Broadband Forum, TR-177.






  Xiao                    Expires Nov. 26, 2025                 [Page 27]


  Internet-Draft            nd-considerations                    May 2025


  8. Acknowledgments

     The authors would like to thank Eric Vyncke, Gunter Van de Velde,
     Lorenzo Colitti, Erik Kline, Warren Kumari, Mohamed Boucadair, Gorry
     Fairhurst, Pascal Thubert, Jen Linkova, Brian Carpenter, Mike
     Ackermann, Nalini Elkins, Ed Horley, Ole Troan, David Thaler,
     Chongfeng Xie, Chris Cummings, Dale Carder, Tim Chown, Priyanka
     Sinha, Aijun Wang, Ines Robles, Magnus Westerlund, Barry Leiba, Deb
     Cooley and Paul Wouters for their reviews and comments. The authors
     would also like to thank Tim Winters for being the document
     shepherd.

  Authors' Addresses

     XiPeng Xiao
     Huawei Technologies Dusseldorf
     Hansaallee 205, 40549 Dusseldorf, Germany
     Email: xipengxiao@huawei.com

     Eduard Vasilenko
     Huawei Technologies
     17/4 Krylatskaya st, Moscow, Russia 121614
     Email: vasilenko.eduard@huawei.com

     Eduard Metz
     KPN N.V.
     Email: eduard.metz@kpn.com

     Gyan Mishra
     Verizon Inc.
     Email: gyan.s.mishra@verizon.com

     Nick Buraglio
     Energy Sciences Network
     Email: buraglio@es.net











  Xiao                    Expires Nov. 26, 2025                 [Page 28]



