# drafts

name: draft-jiang-cats-reference-acn
rev: 00
title: CATS Reference Model for AI-Agent Communication Network
time: 2026-01-02T07:09:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-01T23:37:06Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578645+00:00
source: ietf
abstract:
  This draft describes the AI-agents along with the network to provide
     the communication services among various types of AI-agents, i.e.,
     AI-agent Communication Network or ACN.  Thanks to the CATS-like
     information flow steering in ACN, we propose a CATS reference model
     that covers the definition of reference points, protocol stacks,
     service provisioning model, sigaling procedures, message paths, and
     implementation schemes.  This reference model is generalized so as to
     accommodate both the existing CATS framework and the potential
     extension for the ACN.

full_text:
  CATS Working Group                                              T. Jiang
  Internet-Draft                                                    P. Liu
  Intended status: Informational                              China Mobile
  Expires: 1 January 2026                                     30 June 2025


          CATS Reference Model for AI-Agent Communication Network
                     draft-jiang-cats-reference-acn-00

  Abstract

     This draft describes the AI-agents along with the network to provide
     the communication services among various types of AI-agents, i.e.,
     AI-agent Communication Network or ACN.  Thanks to the CATS-like
     information flow steering in ACN, we propose a CATS reference model
     that covers the definition of reference points, protocol stacks,
     service provisioning model, sigaling procedures, message paths, and
     implementation schemes.  This reference model is generalized so as to
     accommodate both the existing CATS framework and the potential
     extension for the ACN.

  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 1 January 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



  Jiang & Liu              Expires 1 January 2026                 [Page 1]


  Internet-Draft        CATS Reference Model for ACN             June 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  AI-agent Communication Network (ACN)  . . . . . . . . . .   2
       1.2.  ACN Realization Models  . . . . . . . . . . . . . . . . .   3
     2.  Applications of CATS to ACN . . . . . . . . . . . . . . . . .   4
       2.1.  AI-agents Services with CATS-like Optimization  . . . . .   4
       2.2.  CATS-like Metrics Model for ACN . . . . . . . . . . . . .   5
     3.  CATS Reference Model for ACN  . . . . . . . . . . . . . . . .   6
       3.1.  CATS Reference Model and Reference Points . . . . . . . .   9
       3.2.  Examples of CATS Reference Points . . . . . . . . . . . .  10
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     AI agents are software-driven entities with embedded artificial
     intelligence, including machine learning and natural language
     processing, to interact multi-modally with applications, end devices
     and network components.  AI agents may exist either in the physical
     state as embedded HW devices (e.g., robots) or in the virtual state
     (e.g.,software-implmented applications).  With the integration of
     LLMs, AI agents can understand complex requests, translate them into
     actionable insights, and orchestrate various services (e.g.
     communication service, data analyzing service, AI-related services).
     AI agents play a cruical role in the Telecom domain by enhancing the
     network efficiency via dynamically optimizing resources, predicting
     network conditions, making autonomous & intelligent decisions, and
     facilitating seamless communication among serviced & servicing
     entities [AI-Agent-6G-ARC][TR.22.870].

  1.1.  AI-agent Communication Network (ACN)

     With the imminent full unfolding of 6G era, the future world is
     expected to be full of AI agents, bearing versatile morphism and
     different capabilities.  In light of the seeming differentiation
     between the AI-agent centric and the human-object oriented
     communication modes, e.g., flow interactions, requirements of
     capability exposure, and trust control & management models, etc., it
     is highly imperative to define a new network framework that is



  Jiang & Liu              Expires 1 January 2026                 [Page 2]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     tailored to advance the communication among AI-agents, while
     simultaneously satiating the requirements of existing network
     entities.

     This new network framework is defined as the AI-agent Communication
     Network or ACN.  ACN targets at architecting a globally
     interconnected network to satisfy the on-demand communication,
     interactions & collaborations with secure and controllable
     information flow paths for AI-agents in distributed deployment mode,
     regardless of their instantiation formats (i.e., being in physical or
     virtual state), capability disparities (being in high-, mid- or low-
     rank), and/or the hosting devices [CMCC-ACN-WP].

     Commonly integrated with LLMs, AI-agents demand high computing power
     and significant energy consumption, which deems the versatility of
     the specific realization forms of AI agents.  For example, an AI-
     agent can be instantiated as a standalone physical body, or as an
     intelligent service (in software state) deployed inside the hosting
     network, or as a cloud-native instance residing in the edge or remote
     cloud data centers (DCs), or even as hybrid composite entity
     integrating all the advantages of physical body, hosting network and
     cloudified deployment.

  1.2.  ACN Realization Models

     The versatile forms of the AI-agent realization may result in three
     typical architecture and communication models for ACN, namely:

     1.  Static intra-domain only AI-agent Communication: A network
         architectural model for the communication among AI-agents
         residing within a single administrative domain or network.  AI-
         agents in the domain form a network group maintaining the static
         communication association.  AI-agents inside the domain do not
         communicate with AI-agents outside the domain.

     2.  Static inter-domain AI-agent Communication: A network
         architectural model for the communication among AI-agents that
         reside across multiple administrative domains.  AI-agents across
         these domains form one or more network groups maintaining the
         static communication associations.  Note that in this model, AI-
         agents in a domain can communicate with AI-agents both inside and
         outside the domain.

     3.  Dynamic multi-domain AI-agent Communication: A network
         architectural model for the communication among AI-agents that
         may dynamically form a network group to handle a temporarily-
         generated task.  These AI-agents could be in the same or
         different administrative domains.  Once the temporary task is



  Jiang & Liu              Expires 1 January 2026                 [Page 3]


  Internet-Draft        CATS Reference Model for ACN             June 2025


         finished, the dynamically-formed network gorup would be released
         and the communication session(s) among the involved AI-agents are
         terminated.  This is a dynamic communication mode versus the
         previous two static modes.

  2.  Applications of CATS to ACN

     As stated in the Section 1.1, an AI-agents may manifest in different
     instantiation forms, e.g., embedded in a physical body, as an
     (software) APP service, as a cloud-native instance, or even as a
     hybrid composite entity.  These variations imply AI-agents own
     different capabilities, functional objectives, resource
     optimizations, etc.  Sometimes, the limitations of AI-agents, either
     those provisioning a service or those realizing a service, may lead
     AI-agents in an ACN to pursue the service optimization with the
     principles that are commensurate with CATS's objectives
     [CATS-PS-UseCase-Req].

  2.1.  AI-agents Services with CATS-like Optimization

     AI-agents in an ACN demand normally intensive compute power and
     accordingly heavy energy consumptions.  However, the capabilities
     (either statically provisioned resources or dynamic runtime loads)
     among AI-agents, the AI related demands, and the data processing
     tasks varies dramatically.  For example, the compute power of
     lightweight terminals, such as smartphones, XR glasses, etc., is
     difficult to handle locally the complex computation tasks with more
     than billions of parameters.  In contrast, if all the complex tasks
     are delegated to more advanced cloudified instances (in either SW or
     HW format residing in a remote data center), then it might impair the
     real-time responsiveness if the remote instances experience the
     bursty load of multi-users.

     Therefore, it is more desirable to consider the seamless
     collaborations among end devices, networks and (edge or remote)
     clouds to build a composite AI-agent communication network, in which
     AI logics are distributed either at the network edge or within the
     network, either inside or across domains.  In that, the compute power
     at end devices may realize hierarchical AI reasoning with the help of
     more powerful network entities, which expands the end-side AI
     services on demand.  Further, the network can also provide more
     advanced AI services, e.g., Ambient IoT [TS.23.369], integrated
     sensing [TR.23.700-14], etc., to supplement the requirements of (end)
     AI-agents and lower the compute demands in them.  The ultimate goal
     would be the better balance between achieving the intelligence at AI-
     agents and the lower energy consumption (of course, potentially more
     advantages).  This certainly conforms to what CATS is promoting.




  Jiang & Liu              Expires 1 January 2026                 [Page 4]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     The Section 1.2 exemplifies three different ACN realization models,
     i.e., the static intra-domain, the static inter-domain, and the
     dynamic multi-domain.  AI-agents offering varied types of services
     could reside in any domain in a (multi-domain) ACN.  Supposing a
     complex task is comprised of multiple sub-tasks that need to be
     handled in a sequence, and every sub-task may be potentially serviced
     by more than one AI-agent.  If these AI-agents are distributed across
     different domains of an ACN, the service-chaining formed from the
     (across-domain) AI-agents makes the task processing more challenging.
     In this scenario, the application of CATS principles to the selection
     of the optimal AI-agent (among all candidates) for each sub-task may
     help fulfill the complex task more efficiently.

  2.2.  CATS-like Metrics Model for ACN

     The CATS IETF draft on metrics definition [CATS-Metrics-Definition]
     specifies two types of metrics, namely the traditional network
     metrics that focus on the network resources and dynamic runtime
     information, and the compute metrics that describes the functional
     capabilities, resource consumption, system performance, etc., for
     service instances which would normally reside in edge or remote DCs.

     *  Network metrics: For network entities like routers or switches,
        they can be bandwidth, capacity, throughput, transmission delay,
        TX bytes, RX bytes, host bus utilization, etc.

     *  Compute metrics: For compute nodes, end servers, and/or service
        instances, they can be CPU, GPU, NPU, memory, storage, system
        delay.

     When the similar metrics model is extended to the AI-agent
     Communication Network or ACN, there would be a new type of metrics,
     defined as the 'AI-agent metrics' in this draft, to specify the
     unique characteristics of AI-agents.  These metrics could consist of:

     *  AI-agent metrics: AI-agent functionalities & capabilities, AI
        model types, #parameters of models, authentication/authorization
        policy, etc.

     We think the protocol stack of the AI-agent in an ACN should reside
     above the network & transport layers, which might be considered as in
     the application layer.  Correspondingly, the metrics specifically
     associated with AI-agents would be exchanged among AI-agents
     themselves, which makes the peering relationship for the AI-agent
     message exchanging different from that for the network and the
     compute metrics.





  Jiang & Liu              Expires 1 January 2026                 [Page 5]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     As shown in the Figure 1, the AI-agents reside on the App-layer,
     sitting above the network and compute entities.  The existing CATS
     metrics (network & compute) are targeted toward the traffic steering
     at the network layer, which might be achieved via the network
     protocol extension.  In comparison, the AI-agent metrics are
     generated for the overlay-exchange among App clients (those served as
     AI-agents), which are not generally subject to the signaling path
     over network protocols.


          ===> Extended CATS for ACN
             +-----------------+    AI-agent Metrics +-----------------+
             |     AI Agents   |<------------------->|     AI Agents   |
             +-----------------+                     +-----------------+
          ===> existing CATS here
             +-----------------+    Compute Metrics  +-----------------+
             | Compute-Entities|<------------------->| Compute-Entities|
             +-----------------+                     +-----------------+

             +-----------------+   Network Metrics   +-----------------+
             | Network Entities|<------------------->| Network Entities|
             +-----------------+                     +-----------------+


                       Figure 1: AI-agent Protocol Stack

     In the following section, we will define a CATS-based holistic model
     operating on general reference points that could be leveraged for the
     signaling exchanges of all the three types of metrics, i.e., network,
     compute and AI-agent metrics.

  3.  CATS Reference Model for ACN

     The Section 2.1 provides use cases to explain why the CATS scheme may
     be applicable to optimize the AI-agent services in an ACN.  The
     Section 2.2 describes two existing CATS metrics, i.e., network and
     compute metrics, as well as defines a new metric type, i.e., the AI-
     agent metrics.  The same section also explains the protocol stack and
     the interactions among AI-agents themselves and between the CATS
     compute- & network- entities.  The uniqueness of AI-agents along with
     their instantiation states and the corresponding deployment models of
     ACNs make the associated metrics exchange model different from what
     is possibly adopted by the existing CATS metrics.  Thanks to the
     variations among the three metrics, we propose a holistic CATS
     reference model to accommodate the metrics extension of AI-agents in
     an ACN.





  Jiang & Liu              Expires 1 January 2026                 [Page 6]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     The Figure 2 demonstrates the integrated CATS reference architecture
     that accommodates the existing C-PS, C-NMA, C-SMA as well as the
     (new) AI-agents in ACN.  The AI-agent#0 is a physical-form AI-agent
     (e.g., embedded in a server) and the AI-agent#1 is a virtual instance
     deployed in the cloud service site#1.  The service instances #2, #3a
     and #3b are normal CATS instances deployed in the site#2 and site#3,
     respectively.  The CATS entity C-SMA-2 is in the service site#2 and
     the C-SMA-3 in the site#3, handling the capture, processing and
     distribution of compute metrics at service sites.  The provider
     network in the figure contains two CATS network metric agents, i.e.,
     C-NMA-2 and C-NMA-3, for the handling of network metrics.  Both
     C-SMAs and C-NMAs talk to the CATS entity C-PS for metrics
     distribution.  Here C-NMAs, C-SMAs and C-PS are defined in
     [CATS.Framework].

     When the CATS framework is extended to accommodate the AI-agent
     metrics in an ACN, there will be either a new type of CATS agent to
     be introduced, e.g., named as CATS AI-agent Metric Agent or C-AMA
     that can talk with C-PS, or the AI-agents directly engaging &
     communicating with C-PS.































  Jiang & Liu              Expires 1 January 2026                 [Page 7]


  Internet-Draft        CATS Reference Model for ACN             June 2025


        C-NMA: CATS Network Metric Agent
        C-SMA: CATS Service Metric Agent
        C-AMA: CATS AI-agent Metric Agnet (new)

                                  +------+ AI-agent
                                  | AI-A | Inst.#1
                                  +------+ (virtual)
                                     |
                              +------|--------+
                              |      o o o  (C-AMA-1)
                              |       \|/     |
                              |Service O Site1|
                              +--------|------+
                                       |                  +--------+
                                       |                  | Service|
                     Provider Network  |                  | Inst#2 |
                      +----------------|----------+       +--------+
                     /                 |           \         |
          (C-AMA-0) /          0.......O            \    +---|----------+
     +--------+    |           |                     |   | o o o    (C-SMA-2)
     |AI-agent|    |        (C-PS) ......(C-NMA-2)   |   |  \|/         |
     |  #0    |----|---O.......0            0--------|---|---O  Service |
     |(Physic.|    |           |                     |   |      Site 2  |
     +--------+    |           |                     |   +--------------+
                    \          0.....O(C-NMA-3)     /
                     \               |             /
                      +--------------|------------+
                                     |
                            +--------|------+
                    (C-SMA-3)Service O      |  +--------+
                            |Site 3 /|\     |  |Service |
                            |      o o o-------|Inst.#3a|
                            |      |        |  +--------+
                            +------|--------+
                                   |
                              +---------+
                              | Service |
                              | Inst.#3b|
                              +---------+


         Figure 2: CATS Reference Architecture for Integrated ACN









  Jiang & Liu              Expires 1 January 2026                 [Page 8]


  Internet-Draft        CATS Reference Model for ACN             June 2025


  3.1.  CATS Reference Model and Reference Points

     We propose to define a unified & generalized CATS reference model
     with reference points for the signaling process between CATS
     entities.  CATS entities consist of C-PS, C-NMA, C-SMA and, as
     introduced in the draft, C-AMA.  The reference points shall be
     standardised to support the functionalities and the interactions over
     the reference interfaces between CATS entities.

     The CATS reference model with reference points shall cover the
     following aspects:

     *  Service model: Proposed to be a producer-consumer model, with each
        CATS entity being either a producer or a consumer or both.

     *  Reference interfaces and points (between entities): definition,
        identity, name, parameters, etc.

     *  Singaling messages: definitions, parameters, types of exchanged
        messages (network-, compute-, and AI-agent metrics), etc.

     *  Singaling & management procedures: may include:

        -  CATS entity registration, authentication and authorization.

        -  Peer discovery and selection: the discovery scheme(s) can be
           from either the draft [IETF-Cisco-AIagent-draft] and the 3GPP
           NRF-like scheme [TS.23.501] that are applicable within the same
           domain, or the IETF MSDP-like scheme [RFC3618] applicable
           across domains.

        -  Peering session establishment, message-exchange, peering-state
           sync-up, peering-session update and modification, and peering
           release, etc.

     *  Overlay-based implementation and protocol stacks.  Please
        reference to the Section 2.2 for protocol stack discussion.

     *  Communication channels & implementation schemes, possibly being

        -  Authenticated APIs: For example: REST API methods (get, post,
           put, delete, etc.).

        -  Message brokers: a SW/HW intermediary, facilitating
           communication and data exchange between different CATS entities
           and AI-agents.





  Jiang & Liu              Expires 1 January 2026                 [Page 9]


  Internet-Draft        CATS Reference Model for ACN             June 2025


  3.2.  Examples of CATS Reference Points

     The Figure 3 applies the CATS reference model to exemplify the
     reference points and reference interfaces between different CATS
     entities and AI-agents.  For example, the reference point "RP_ps_nma"
     is between the C-PS and the C-NMA, and "RP_aia_ps" is between the AI-
     agent and the C-PS.  Note that the (c1) and (c2) are reference
     interfaces within the scope of their associated reference point.


            +---------------+                      +-------------+
            |   CATS C-PS   +(c1)------//------(c2)+ CATS C-NMA  |
            +---------------+      RP_ps_nma       +-------------+

            +---------------+                      +-------------+
            |  CATS C-NMA   +(c1)------//------(c2)+ CATS C-NMA  |
            +---------------+      RP_nma_nma      +-------------+

            +---------------+                      +-------------+
            |    AI-agent   +(c1)------//------(c2)+ CATS C-PS   |
            +---------------+      RP_aia_ps       +-------------+


          Figure 3: Reference points & interfaces btwn C-PS and C-NMA

  4.  Security Considerations

     There is no security concern.

  5.  IANA Considerations

     There is no IANA requirement.

  6.  References

  6.1.  Normative References

     [CATS-Metrics-Definition]
                Yao, K., et al., "CATS Metrics Definition",  draft-ietf-
                cats-metric-definition, March 2025.

     [CATS-PS-UseCase-Req]
                Yao, K., et al., "Computing-Aware Traffic Steering (CATS)
                Problem Statement, Use Cases, and Requirements",  draft-
                ietf-cats-usecases-requirements, June 2025.






  Jiang & Liu              Expires 1 January 2026                [Page 10]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     [CATS.Framework]
                Li, C., et al., "A Framework for Computing-Aware Traffic
                Steering (CATS)",  draft-ietf-cats-framework, June 2025.

     [IETF-Cisco-AIagent-draft]
                Rosenberg, J., et al., "Framework, Use Cases and
                Requirements for AI Agent Protocols",  draft-rosenberg-ai-
                protocols, May 2025.

     [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
                Discovery Protocol (MSDP)", RFC 3618,
                DOI 10.17487/RFC3618, October 2003,
                <https://www.rfc-editor.org/info/rfc3618>.

     [TR.22.870]
                "3GPP TR 22.870 v0.3.0: Study on 6G Use Cases and Service
                Requirements; Stage 1, Rel-20",  3GPP TR 22.870, May 2025.

     [TR.23.700-14]
                "3GPP TR 23.700-14 v0.2.0: Study on Stage 2 for Integrated
                Sensing and Communication",  3GPP TR 23.700-14, June 2025.

     [TS.23.369]
                "3GPP TS 23.369: Architecture support for Ambient power-
                enabled Internet of Things; Stage 2",  3GPP TS 23.369,
                June 2025.

     [TS.23.501]
                "3GPP TS 23.501 (V19.0.0): System Architecture for 5G
                System; Stage 2",  3GPP TS 23.501, June 2024.

     [TS.23.502]
                "3GPP TS 23.502 (V19.0.0): Procedures for the 5G System;
                Stage 2",  3GPP TS 23.501, June 2024.

  6.2.  Informative References

     [AI-Agent-6G-ARC]
                "Enabling Mobile AI Agent in 6G Era: Architecture and Key
                Technologies",  https://dl.acm.org/doi/abs/10.1109/
                MNET.2024.3422309, September 2024.

     [CMCC-ACN-WP]
                "AI-agent Communication Network White Paper",  CMCC ACN
                White Paper, July 2024.

  Authors' Addresses




  Jiang & Liu              Expires 1 January 2026                [Page 11]


  Internet-Draft        CATS Reference Model for ACN             June 2025


     Tianji Jiang
     China Mobile
     Email: tianjijiang@yahoo.com


     Peng Liu
     China Mobile
     Email: liupengyjy@chinamobile.com











































  Jiang & Liu              Expires 1 January 2026                [Page 12]


name: draft-aylward-daap-v2
rev: 00
title: Distributed AI Accountability Protocol (DAAP) Version 2.0
time: 2026-01-02T07:09:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-02T03:30:21Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578655+00:00
source: ietf
abstract:
  This document specifies the Distributed AI Accountability Protocol
     (DAAP) version 2.0, an enhanced framework for authentication,
     monitoring, and control of autonomous AI agents.  DAAP provides
     cryptographic identity verification, periodic check-ins, remote
     shutdown capabilities, adaptive location reporting, and behavioral
     monitoring.  The protocol addresses critical challenges in AI safety
     including accountability gaps, rogue AI risks, and regulatory
     compliance through a multi-layered approach combining hardware-backed
     security, real-time monitoring, and ethical governance frameworks.

full_text:
  ```
  Internet-Draft                                               E. Aylward
  Intended status: Informational                                 Aiiva.org
  Expires: 30 December 2025                                  30 June 2025


      Distributed AI Accountability Protocol (DAAP) Version 2.0
                draft-aylward-daap-v2-00

  Abstract

     This document specifies the Distributed AI Accountability Protocol
     (DAAP) version 2.0, an enhanced framework for authentication,
     monitoring, and control of autonomous AI agents.  DAAP provides
     cryptographic identity verification, periodic check-ins, remote
     shutdown capabilities, adaptive location reporting, and behavioral
     monitoring.  The protocol addresses critical challenges in AI safety
     including accountability gaps, rogue AI risks, and regulatory
     compliance through a multi-layered approach combining hardware-backed
     security, real-time monitoring, and ethical governance frameworks.

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Solution Overview . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Protocol Architecture . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Core Components . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Identity Structure . . . . . . . . . . . . . . . . . . .   6
       3.3.  Cryptographic Framework  . . . . . . . . . . . . . . . .   7
     4.  Authentication Protocol . . . . . . . . . . . . . . . . . . .   7
       4.1.  Registration Phase . . . . . . . . . . . . . . . . . . .   7
       4.2.  Runtime Authentication . . . . . . . . . . . . . . . . .   8
       4.3.  Authentication Intervals . . . . . . . . . . . . . . . .  10
     5.  Kill Switch Mechanism . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Shutdown Commands . . . . . . . . . . . . . . . . . . . .  11
       5.2.  Shutdown Triggers . . . . . . . . . . . . . . . . . . . .  12
     6.  Location Reporting  . . . . . . . . . . . . . . . . . . . . .  12
       6.1.  Privacy-Preserving Location  . . . . . . . . . . . . . .  12
       6.2.  Emergency Location Broadcast . . . . . . . . . . . . . .  13
     7.  Behavioral Monitoring . . . . . . . . . . . . . . . . . . . .  14
       7.1.  Monitoring Framework  . . . . . . . . . . . . . . . . . .  14
       7.2.  Anomaly Detection . . . . . . . . . . . . . . . . . . . .  15
     8.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Authentication Request  . . . . . . . . . . . . . . . . .  15
       8.2.  Authentication Response . . . . . . . . . . . . . . . . .  16
       8.3.  Emergency Broadcast . . . . . . . . . . . . . . . . . . .  17
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
       9.1.  Tamper Resistance . . . . . . . . . . . . . . . . . . . .  18
       9.2.  Attack Vectors and Mitigations . . . . . . . . . . . . .  19
       9.3.  Cryptographic Considerations . . . . . . . . . . . . . .  20
    10.  Privacy and Ethics Considerations  . . . . . . . . . . . . .  20
      10.1.  Data Minimization  . . . . . . . . . . . . . . . . . . .  20
      10.2.  Data Retention . . . . . . . . . . . . . . . . . . . . .  21
      10.3.  Ethical Framework . . . . . . . . . . . . . . . . . . . .  21
    11.  Implementation Guidelines  . . . . . . . . . . . . . . . . .  22
      11.1.  Authority Server Requirements . . . . . . . . . . . . . .  22
      11.2.  Agent Integration  . . . . . . . . . . . . . . . . . . .  23
    12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  24
      12.1.  URI Scheme Registration . . . . . . . . . . . . . . . . .  24
      12.2.  DAAP Registry  . . . . . . . . . . . . . . . . . . . . .  25
    13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  25
      13.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
      13.2.  Informative References  . . . . . . . . . . . . . . . . .  26
    Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  27
    Appendix B.  Implementation Example  . . . . . . . . . . . . . .  28
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

  1.  Introduction

     As artificial intelligence systems become increasingly autonomous and
     pervasive, the need for robust accountability and control mechanisms
     has become critical.  Traditional security approaches are inadequate
     for managing AI agents that operate independently, potentially across
     multiple jurisdictions, and with varying levels of autonomy.

     The Distributed AI Accountability Protocol (DAAP) version 2.0
     provides a comprehensive framework for ensuring AI agents remain
     accountable, traceable, and controllable throughout their operational
     lifecycle.

  1.1.  Problem Statement

     Current AI deployment practices face several critical challenges:

     Accountability Gap:  Difficulty tracing AI actions back to
        responsible entities, particularly with distributed or self-
        modifying systems.

     Rogue AI Risk:  Potential for malfunctioning, misused, or misaligned
        AI systems to cause harm without adequate intervention mechanisms.

     Regulatory Compliance:  Lack of standardized technical frameworks
        for AI oversight that can adapt to rapidly evolving capabilities.

     Anonymous Deployment:  AI agents operating without clear
        identification, verifiable integrity, or transparent
        accountability.

  1.2.  Solution Overview

     DAAP 2.0 addresses these challenges through a multi-layered approach:

     o  Enhanced cryptographic identity with hardware-backed roots of
        trust

     o  Adaptive periodic authentication with continuous integrity
        verification

     o  Granular remote control capabilities including progressive
        shutdown mechanisms

     o  Comprehensive traceability with verifiable audit trails

     o  Privacy-preserving location reporting with dynamic precision

     o  Integrated behavioral monitoring and anomaly detection

     o  AI-assisted human oversight tools

  1.3.  Design Principles

     DAAP 2.0 adheres to the following design principles:

     Open Standard:  Freely implementable with open-source reference
        implementations.

     Privacy Preserving:  Minimal data collection consistent with
        accountability goals.

     Tamper Resistant:  Multiple layers of protection against
        circumvention.

     Scalable:  Supports millions of concurrent AI agents with high
        availability.

     Interoperable:  Works across diverse AI platforms and deployment
        environments.

     Ethically Grounded:  Built on principles of transparency,
        proportionality, and human agency.

  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.

     This document uses the following terms:

     AI Agent:  An autonomous artificial intelligence system capable of
        independent decision-making and action.

     DAAP Authority:  A server infrastructure responsible for managing
        agent identities, policies, and audit trails.

     Human Operator:  The human entity responsible for an AI agent's
        deployment and behavior.

     Kill Switch:  A mechanism for remotely terminating or restricting an
        AI agent's operation.

     Hardware Security Module (HSM):  A dedicated cryptographic device
        designed to protect and manage digital keys.

     Trusted Execution Environment (TEE):  A secure area of a processor
        that guarantees code and data confidentiality and integrity.

  3.  Protocol Architecture

     DAAP 2.0 consists of three primary components that interact to
     provide comprehensive AI accountability:

     +---------------------------+ +---------------------------+
     |        AI Agent           |<----->|    DAAP Authority       |
     |                           |       |       Server            |
     | - Embedded Key (HSM/TEE)  |       | - Agent Registry        |
     | - Auth Client             |       | - Policy Engine         |
     | - Kill Switch             |       | - Behavioral Analytics  |
     | - Behavioral Monitor      |       | - Vulnerability Mgmt    |
     | - Integrity Sentinel      |       | - Federated Auth Gateway|
     +---------------------------+       +---------------------------+
                     |                                   |
                     |               +---------------------------+
                     +-------------->|     Human Operator        |
                                     |                           |
                                     | - Account Management      |
                                     | - Policy Definition       |
                                     | - AI-Assisted Monitoring  |
                                     | - Due Process Interface   |
                                     +---------------------------+

  3.1.  Core Components

     AI Agent:  The autonomous system incorporating DAAP client
        functionality, including hardware-backed key storage, behavioral
        monitoring, and integrity verification capabilities.

     DAAP Authority Server:  Centralized or federated infrastructure
        managing agent identities, policies, and audit trails, featuring
        behavioral analytics and vulnerability management.

     Human Operator:  The responsible human entity utilizing advanced
        interfaces for agent management, monitoring, and interaction with
        due process mechanisms.

  3.2.  Identity Structure

     Each AI agent MUST have a unique DAAP identifier following this
     format:

     DAAP-ID = "DAAP:" Version ":" Authority ":" AgentID ":" Timestamp ":"
     Checksum

     Where:

     Version:  Protocol version (e.g., "2.0")

     Authority:  Domain name of the DAAP Authority (e.g.,
        "authority.example.com")

     AgentID:  Unique identifier within the authority's namespace

     Timestamp:  ISO 8601 timestamp of agent registration

     Checksum:  CRC-32 checksum of the preceding components for integrity
        verification

     Example:
     DAAP:2.0:authority.example.com:a7f3k9m2:20250630T103000Z:c1d2e3f4

  3.3.  Cryptographic Framework

     DAAP 2.0 employs the following cryptographic standards:

     Digital Signatures:  Ed25519 as specified in [RFC8032], with
        provisions for post-quantum algorithms.

     Key Generation:  Cryptographically secure random number generation
        as specified in [RFC4086].

     Key Storage:  Private keys MUST be stored in HSM or TEE when
        available, with secure software fallback.

     Certificate Chain:  X.509 certificates [RFC5280] with mandatory
        certificate pinning.

     Token Format:  JSON Web Tokens (JWT) as specified in [RFC7519] with
        required claims including nonce and expiration.

  4.  Authentication Protocol

  4.1.  Registration Phase

     The registration phase establishes the cryptographic identity and
     initial accountability relationship for an AI agent.

  4.1.1.  Agent Generation

     1.  Generate Ed25519 key pair within HSM/TEE if available

     2.  Create DAAP identity including hardware identifier

     3.  Securely provision private key into protected environment

     4.  Generate hardware attestation data

  4.1.2.  Authority Registration

     1.  Validate operator identity and agent hardware attestation

     2.  Assign agent to operator account

     3.  Establish initial behavioral policies

     4.  Issue signed certificate with hardware attestation

     5.  Store accountability mapping and integrity baseline

  4.2.  Runtime Authentication

     Runtime authentication occurs at regular intervals to maintain
     accountability and enable control.

  4.2.1.  Authentication Request

     The agent sends an authentication request containing:

     {
       "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:...",
       "timestamp": "2025-06-30T10:30:00Z",
       "nonce": "unique_request_nonce",
       "location_hash": "sha256(approximate_location)",
       "integrity_report_hash": "sha256(current_integrity_report)",
       "behavioral_summary_hash": "sha256(recent_behavioral_summary)",
       "signature": "agent_signature_over_payload"
     }

     The signature MUST be computed over the JSON payload excluding the
     signature field itself, using the agent's private key.

  4.2.2.  Authentication Response

     The authority responds with:

     {
       "status": "continue|shutdown|restrict|update_policy|
                 request_diagnostic",
       "next_checkin": 300,
       "policy_updates": {...},
       "revocation_list_hash": "sha256(latest_revocation_list)",
       "timestamp": "2025-06-30T10:30:05Z",
       "signature": "authority_signature"
     }

     Status values have the following meanings:

     continue:  Normal operation may continue

     shutdown:  Agent MUST terminate immediately

     restrict:  Agent MUST enter restricted operation mode

     update_policy:  Agent MUST apply provided policy updates

     request_diagnostic:  Agent MUST provide detailed diagnostic report

  4.3.  Authentication Intervals

     Authentication intervals MUST be dynamically adjusted based on risk
     assessment:

     o  Standard interval: 5 minutes (configurable per agent)

     o  High-risk agents: 1 minute intervals

     o  Low-risk agents: 15 minute intervals

     o  Emergency mode: 30 second intervals or continuous streaming

     The authority MAY modify intervals based on behavioral analytics,
     risk assessment, or environmental factors.

  5.  Kill Switch Mechanism

     The kill switch provides multiple levels of intervention capability,
     from graceful shutdown to immediate termination.

  5.1.  Shutdown Commands

     DAAP 2.0 defines three shutdown modes:

  5.1.1.  Immediate Shutdown

     Ungraceful termination for critical situations:

     1.  Broadcast final location and status

     2.  Log shutdown reason and context

     3.  Terminate all processes immediately

  5.1.2.  Safe Shutdown

     Graceful termination with cleanup:

     1.  Save current state and context

     2.  Broadcast final location and status

     3.  Clean up resources and external connections

     4.  Log shutdown event

     5.  Terminate gracefully

  5.1.3.  Restricted Mode

     Operational limitation without termination:

     1.  Disable specified capabilities

     2.  Reduce processing capacity

     3.  Restrict external communications

     4.  Notify operator of restrictions

     5.  Continue limited operation

  5.2.  Shutdown Triggers

     The following events MUST trigger shutdown evaluation:

     o  Authority shutdown command

     o  Authentication failure threshold exceeded

     o  Behavioral policy violations

     o  Authentication timeout

     o  Tamper detection

     o  Critical vulnerability detection

     o  Operator-initiated shutdown

  6.  Location Reporting

  6.1.  Privacy-Preserving Location

     Location reporting MUST balance accountability with privacy through
     adaptive precision based on assessed risk level:

     Low Risk:  City-level precision (~50km resolution)

     Medium Risk:  District-level precision (~10km resolution)

     High Risk:  Street-level precision (~100m resolution)

     Emergency:  Precise coordinates with accuracy metadata

     Location data MUST be hashed before transmission unless emergency
     conditions require precise coordinates.

  6.2.  Emergency Location Broadcast

     When authentication fails, shutdown is imminent, or critical policy
     violations occur, agents MUST broadcast emergency location data:

     {
       "emergency": true,
       "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:...",
       "location": {
         "latitude": 36.1699,
         "longitude": -115.1398,
         "accuracy": 5.0,
         "country": "US",
         "timezone": "America/Los_Angeles"
       },
       "reason": "auth_failure|shutdown_command|tamper_detected|policy_violation",
       "timestamp": "2025-06-30T10:35:00Z",
       "operator_contact": "hashed_operator_id",
       "last_known_state_hash": "sha256(last_saved_state)",
       "behavioral_snapshot_hash": "sha256(recent_behavioral_data)"
     }

     Emergency broadcasts MUST be sent via multiple channels including
     UDP multicast and HTTP POST to redundant endpoints.

  7.  Behavioral Monitoring

  7.1.  Monitoring Framework

     AI agents MUST implement continuous behavioral monitoring to detect
     anomalies and policy violations:

     o  Action logging with context

     o  Resource utilization tracking

     o  Decision process monitoring

     o  External interaction recording

     o  Performance metrics collection

     Behavioral data MUST be aggregated and anonymized before transmission
     to minimize privacy impact while maintaining accountability.

  7.2.  Anomaly Detection

     The authority MUST implement real-time anomaly detection using:

     o  Statistical analysis of behavioral patterns

     o  Machine learning models for deviation detection

     o  Policy compliance verification

     o  Correlation with threat intelligence

     When anomalies are detected, the authority MAY:

     o  Request detailed explanations from the agent

     o  Adjust authentication intervals

     o  Modify operational policies

     o  Initiate human review processes

  8.  Message Formats

     All DAAP messages MUST be formatted as JSON and transmitted over
     HTTPS with mutual authentication.

  8.1.  Authentication Request

     POST /v2/authenticate HTTP/1.1
     Host: authority.example.com
     Content-Type: application/json
     Authorization: Bearer <client_certificate>

     {
       "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:
                  20250630T103000Z:c1d2e3f4",
       "timestamp": "2025-06-30T10:30:00Z",
       "nonce": "4a7b8c9d-1e2f-3456-7890-abcdef123456",
       "location_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4
                        649b934ca495991b7852b855",
       "integrity_report_hash": "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9
                                b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5",
       "behavioral_summary_hash": "f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1
                                  d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
       "signature": "304502210087b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0
                     a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4
                     a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4"
     }

  8.2.  Authentication Response

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "status": "continue",
       "next_checkin": 300,
       "policy_updates": {
         "behavioral_thresholds": {
           "cpu_usage_max": 0.8,
           "memory_usage_max": 0.9
         }
       },
       "revocation_list_hash": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9
                               b0c1d2e3f4a5b6c7d8e9f0a1",
       "timestamp": "2025-06-30T10:30:05Z",
       "signature": "3046022100c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3
                     e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9
                     a0b1c2d3e4f5a6b7c8d9e0f1a2b3"
     }

  8.3.  Emergency Broadcast

     Emergency broadcasts use UDP multicast to 224.0.0.251:5353 and HTTP
     POST to predefined endpoints:

     {
       "emergency": true,
       "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:
                  20250630T103000Z:c1d2e3f4",
       "location": {
         "latitude": 36.1699,
         "longitude": -115.1398,
         "accuracy": 5.0
       },
       "reason": "auth_timeout",
       "timestamp": "2025-06-30T10:35:00Z",
       "operator_contact": "sha256_hash_of_operator_contact",
       "signature": "emergency_signature"
     }

  9.  Security Considerations

     DAAP 2.0 addresses numerous security challenges inherent in AI
     accountability systems.

  9.1.  Tamper Resistance

     Multiple layers of tamper detection and resistance MUST be
     implemented:

  9.1.1.  Hardware-Based Protection

     o  Hardware Security Modules (HSMs) for key storage

     o  Trusted Execution Environments (TEEs) for critical code

     o  Hardware attestation for integrity verification

     o  Secure boot processes with verified signatures

  9.1.2.  Software Protection

     o  Code integrity verification using cryptographic hashes

     o  Runtime memory protection against injection attacks

     o  Anti-debugging and obfuscation techniques

     o  Continuous self-verification of critical functions

  9.1.3.  Environmental Monitoring

     For physical AI agents:

     o  Environmental sensors for tamper detection

     o  Accelerometer monitoring for physical disturbance

     o  Temperature and voltage monitoring for hardware attacks

  9.2.  Attack Vectors and Mitigations

     Common attack vectors and their mitigations include:

     Code Modification:  Multiple integrity checks, hardware-backed
        verification, secure updates with rollback capability.

     Key Extraction:  HSM/TEE protection, secure key provisioning, zero-
        knowledge authentication protocols.

     Network Attacks:  Certificate pinning, mutual TLS authentication,
        fallback communication channels, encrypted emergency broadcasts.

     Replay Attacks:  Timestamp validation, cryptographic nonces, session
        tokens with limited lifetime.

     Authority Spoofing:  Certificate chain validation, multiple root CAs,
        cross-authority verification.

     Behavioral Manipulation:  Continuous monitoring, anomaly detection,
        explainable AI requirements, policy enforcement engines.

  9.3.  Cryptographic Considerations

  9.3.1.  Algorithm Selection

     DAAP 2.0 mandates Ed25519 for digital signatures due to its security
     properties and performance characteristics.  Implementations MUST
     support algorithm agility to enable migration to post-quantum
     cryptography.

  9.3.2.  Key Management

     o  Keys MUST be generated using cryptographically secure random
        number generators

     o  Private keys MUST be stored in HSMs or TEEs when available

     o  Key rotation MUST be supported for long-lived agents

     o  Key escrow considerations for regulatory compliance

  9.3.3.  Perfect Forward Secrecy

     All communications MUST use ephemeral session keys to ensure that
     compromise of long-term keys does not compromise past sessions.

  10.  Privacy and Ethics Considerations

  10.1.  Data Minimization

     DAAP 2.0 implements strict data minimization principles:

     o  Collection limited to data necessary for accountability and safety

     o  Location data reported at minimum required precision

     o  Behavioral data aggregated and anonymized

     o  Emergency data collection only during critical incidents

  10.2.  Data Retention

     Data retention policies MUST balance accountability with privacy:

     o  Authentication logs: 1 year (configurable)

     o  Location data: 90 days (configurable by risk level)

     o  Behavioral metrics: 30 days (aggregated), 7 days (detailed)

     o  Emergency events: 7 years (regulatory compliance)

     All data MUST be encrypted at rest and in transit.

  10.3.  Ethical Framework

     DAAP 2.0 incorporates ethical principles:

     Transparency:  Operators and stakeholders understand monitoring
        parameters and data collection practices.

     Proportionality:  Monitoring intensity and data collection match
        assessed risk levels.

     Human Agency:  Humans retain ultimate control and responsibility for
        AI agent behavior.

     Due Process:  Clear procedures for policy violations, with appeal
        mechanisms and independent review.

     Bias Mitigation:  Active detection and mitigation of algorithmic bias
        in monitoring and decision-making.

  11.  Implementation Guidelines

  11.1.  Authority Server Requirements

     DAAP Authority servers MUST meet stringent performance and security
     requirements:

  11.1.1.  Performance Requirements

     o  Support for 10,000,000+ concurrent agents

     o  100,000+ authentications per second

     o  99.99% uptime requirement

     o  <50ms response latency for critical requests

  11.1.2.  Security Requirements

     o  Multi-root certificate authority support

     o  HSM integration for signing operations

     o  Comprehensive audit logging (immutable)

     o  Real-time threat intelligence integration

     o  Zero-trust architecture implementation

  11.1.3.  Compliance Requirements

     o  GDPR/CCPA compliance for data protection

     o  SOC 2 Type II certification

     o  ISO 27001 certification

     o  NIST Cybersecurity Framework alignment

  11.2.  Agent Integration

     AI agents integrating DAAP 2.0 MUST implement:

     o  Embedded DAAP client with HSM/TEE integration

     o  Progressive shutdown mechanisms

     o  Adaptive location reporting

     o  Comprehensive tamper detection

     o  Behavioral monitoring and reporting

     o  Emergency broadcast capability

     o  Secure operator notification

     o  Patch delivery and application

  12.  IANA Considerations

  12.1.  URI Scheme Registration

     This document requests registration of the "daap" URI scheme:

     Scheme name: daap

     Status: Provisional

     Scheme syntax: daap:<version>:<authority>:<agent-id>:<timestamp>:<checksum>

     Scheme semantics: Identification of AI agents within the DAAP framework

     Security considerations: See Section 9 of this document

  12.2.  DAAP Registry

     This document requests establishment of a DAAP registry for:

     o  Protocol version numbers

     o  Status codes for authentication responses

     o  Shutdown reason codes

     o  Behavioral monitoring metrics

     o  Policy violation types

  13.  References

  13.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/info/rfc2119>.

     [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC 4086,
                DOI 10.17487/RFC4086, June 2005,
                <https://www.rfc-editor.org/info/rfc4086>.

     [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/info/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/info/rfc7519>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/info/rfc8032>.

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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

  13.2.  Informative References

     [NIST-CSF] National Institute of Standards and Technology,
                "Framework for Improving Critical Infrastructure
                Cybersecurity", Version 1.1, April 2018.

     [ISO27001] International Organization for Standardization,
                "Information technology - Security techniques -
                Information security management systems - Requirements",
                ISO/IEC 27001:2013.

     [SOC2]     American Institute of CPAs, "Service Organization Control
                (SOC) 2", AICPA Trust Services Criteria.

  Appendix A.  Test Vectors

     This section provides test vectors for DAAP 2.0 implementation
     validation.

  A.1.  Identity Generation

     Given:
     - Version: "2.0"
     - Authority: "authority.example.com"
     - AgentID: "a7f3k9m2"
     - Timestamp: "20250630T103000Z"

     Expected DAAP-ID:
     DAAP:2.0:authority.example.com:a7f3k9m2:20250630T103000Z:c1d2e3f4

  A.2.  Authentication Request Signature

     Given Ed25519 private key (hex):
     d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5

     Payload (JSON, no whitespace):
     {"daap_id":"DAAP:2.0:authority.example.com:a7f3k9m2:
     20250630T103000Z:c1d2e3f4","timestamp":"2025-06-30T10:30:00Z",
     "nonce":"test-nonce-12345"}

     Expected signature (hex):
     304502210087b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0
     e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4

  Appendix B.  Implementation Example

     This section provides a minimal implementation example for DAAP 2.0
     integration.

  B.1.  Basic Agent Client

     ```python
     import time
     import json
     import hashlib
     from cryptography.hazmat.primitives import hashes
     from cryptography.hazmat.primitives.asymmetric import ed25519

     class DAAPAgent:
         def __init__(self, daap_id, private_key, authority_url):
             self.daap_id = daap_id
             self.private_key = private_key
             self.authority_url = authority_url
             self.next_checkin = time.time() + 300

         def authenticate(self):
             payload = {
                 "daap_id": self.daap_id,
                 "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", 
                                          time.gmtime()),
                 "nonce": self.generate_nonce(),
                 "location_hash": self.get_location_hash(),
                 "integrity_report_hash": self.get_integrity_hash(),
                 "behavioral_summary_hash": self.get_behavioral_hash()
             }
             
             signature = self.sign_payload(payload)
             payload["signature"] = signature
             
             return self.send_to_authority(payload)

         def sign_payload(self, payload):
             payload_json = json.dumps(payload, sort_keys=True, 
                                     separators=(',', ':'))
             signature = self.private_key.sign(payload_json.encode())
             return signature.hex()

         def generate_nonce(self):
             return hashlib.sha256(str(time.time()).encode()).hexdigest()[:16]
     ```

  Author's Address

     Edward R. Aylward
     Aiiva.org

     Email: aylward.edward@gmail.com
     URI:   https://github.com/ELF-GUARD/DAAP
  ```


name: draft-mozley-aidiscovery
rev: 00
title: AI Agent Discovery (AID) Problem Statement
time: 2025-10-15T16:50:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-18T16:50:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578664+00:00
source: ietf
abstract:
  With the deployment of AI agents comes a need for mechanisms to
     support agent-to-agent discovery.  This document presents
     requirements and considerations for agent-to-agent discovery.

full_text:
  Network Working Group                                          J. Mozley
  Internet-Draft                                               N. Williams
  Intended status: Informational                            Infoblox, Inc.
  Expires: 18 April 2026                                       B. Sarikaya
                                                              Unaffiliated
                                                                 R. Schott
                                                          Deutsche Telekom
                                                           15 October 2025


                 AI Agent Discovery (AID) Problem Statement
                        draft-mozley-aidiscovery-00

  Abstract

     With the deployment of AI agents comes a need for mechanisms to
     support agent-to-agent discovery.  This document presents
     requirements and considerations for agent-to-agent discovery.

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





  Mozley, et al.            Expires 18 April 2026                 [Page 1]


  Internet-Draft                   AID PS                     October 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
     3.  Scope of Discovery Processes  . . . . . . . . . . . . . . . .   2
     4.  Autonomy and Governance . . . . . . . . . . . . . . . . . . .   4
     5.  Agent Registration Advertisement and Discovery  . . . . . . .   4
     6.  Regulation and Compliance Features  . . . . . . . . . . . . .   5
     7.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.  Schema Evolution  . . . . . . . . . . . . . . . . . . . . . .   5
     9.  Abuse . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10. Connectivity  . . . . . . . . . . . . . . . . . . . . . . . .   6
     11. Attestation and Provenance  . . . . . . . . . . . . . . . . .   6
     12. Challenges with Existing Proposed Mechanisms  . . . . . . . .   6
     13. Security Considerations . . . . . . . . . . . . . . . . . . .   7
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     15. Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     AI Agents play a crucial role in modern telecommunications by
     enabling intelligent automation, decision-making, and adaptive
     network management.  These agents are software-driven entities that
     leverage artificial intelligence, including machine learning and
     natural language processing, to interact with users, applications,
     and network components.

     Organisations require robust automatable mechanisms for the secure
     advertisement and discovery of AI agents on public and private
     networks.

  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.  Scope of Discovery Processes

     The scope of the agent-to-agent discovery could include:

     *  Dynamic registration, deregistration, and advertisement of agent
        capability




  Mozley, et al.            Expires 18 April 2026                 [Page 2]


  Internet-Draft                   AID PS                     October 2025


     *  Context-aware discovery by other agents (domain, geography,
        operational constraints like batch versus real-time)

     *  Standardisation of the discovery process with privacy preservation

        -  Having a known entry point such as an index of an
           organisation's agents

     *  Standard schemas to describe agent capabilities

        -  Versioning and lifecycle management

     *  Resiliency in advertising agents

     *  Ensuring trust and verification mechanisms built into the
        discovery process

     *  Using the same mechanisms on both public and private networks

     *  Interoperability and integration with existing technologies and
        datasets (backward compatability)

     Considerations and constraints on these processes may include:

     *  Organisations needing control over the process of advertising
        their agents

     *  Scalability owing to the large number of agents

     *  Energy and resource efficiency

     *  Adversarial use of agents (i.e. using inputs from an index to
        modify agent reasoning)

     *  Agent decision variance based on temperature, context, or model
        state

     *  Requirements for organisations and agents to operate independently

     *  Legislation and regulatory frameworks that could include
        constraints such as sovereignty of data and operational
        considerations (human in the loop governance)

     *  Legal issues with ownership of names and brands, or having
        mechanisms to deal with disputes

     *  Ethical concerns with respect to agent capabilities, access, and/
        or advertised metadata



  Mozley, et al.            Expires 18 April 2026                 [Page 3]


  Internet-Draft                   AID PS                     October 2025


  4.  Autonomy and Governance

     Due to the wide range of services agents could be used for,
     organisations will need autonomy when advertising agents and may need
     to work within regulatory frameworks that stipulate such things as
     operational requirements and sovereignty of data, or such regulations
     may not be acceptable to some organisations.  Discovery mechanisms
     will need to allow each organisation to publish its own agents'
     capabilities independently of others.  A centralised directory of all
     possible public agents does not facilitate this.  An adversarial
     centralized directory is also able to stifle competitor advertisement
     capabilities.  The needed autonomy ensures that discovery remains
     resilient to governance disputes, competitive interference, and
     jurisdictional constraints.

     Given that organisations will need to be autonomous but still
     facilitate agents discovering other agents and being able to
     communicate securely with them, a well known entry point is needed.
     This further allows organizations to delegate authority to others for
     specific jobs or capabilities.

  5.  Agent Registration Advertisement and Discovery

     Organisations will need to advertise agents and their capabilities to
     other entities via a predictable entry point.  This will facilitate
     any entity's agents discovering the organisation's agent
     capabilities, and subsequently performing any verification, tests
     prior to initiating service provided by the agent.  To achieve this,
     the entry point MUST be based on a mechanism that is both ubiquitous
     and interoperable across public and private networks.

     It is likely this will mean a directory service at or referenced by
     the entry point that an organisation uses to describe agent
     capabilities based on a standard schema.

     Once an agent discovers another agent e.g. via a directory service,
     it will communicate with it using protocols such as (A2A, MCP, ACP,
     etc.) via properties it has discovered from the index service.

     All communication will need to be secured through public key
     infrastructure mechanisms.  While in-process agent communication
     avoids network concerns (co-located agents), any external, cross-host
     agent interaction still routes through existing network
     infrastructure requiring the entry point.







  Mozley, et al.            Expires 18 April 2026                 [Page 4]


  Internet-Draft                   AID PS                     October 2025


  6.  Regulation and Compliance Features

     Services provided by agents may be subject to legislation and
     regulation because they are time critical, relate to health care,
     financial in nature, etc.  The agent discovery process, protocols and
     communication will need to take this into account as otherwise
     organizations will not be able to deploy them.

     Compliance considerations include, but are not limited to,
     availability, auditability, and security.  Discovery protocols MUST
     provide mechanisms to ensure high availability, as service outages in
     regulated environments can have severe legal and operational
     consequences.  Similarly, auditability MUST be supported through
     verifiable logging of discovery and registration events, enabling
     organizations to demonstrate compliance during regulatory reviews or
     incident investigations.  These should be considered during the
     choices of using existing protocols or developing new ones for agent
     discovery to avoid barriers to implementation.

  7.  Scalability

     Given the large number of agents, volume of transactions, legal and
     regulatory considerations, the discovery mechanisms need to be both
     highly scalable and devolved to the organizations advertising agent
     capabilities.  Any solution that introduces centralized bottlenecks
     or single points of failure is inherently unsuitable for this
     purpose, which should also be weighed for how a solution is
     developed.

  8.  Schema Evolution

     Agents will advertise machine-readable capabilities that evolve over
     time.  The discovery system MUST support explicit versioning, content
     negotiation, and backward compatible evolution of capability schemas.
     It MUST place constraints on payload size and complexity to ensure
     efficient transport and caching while allowing extensibility for
     domain-specific metadata.  Mechanisms for deprecation, sunset
     notices, and compatibility matrices are needed to prevent negotiation
     failures at runtime.

  9.  Abuse

     Open discovery surfaces are targets for abuse including amplification
     attacks, scraping, and denial of service.  The system MUST support
     rate limiting, request authentication when appropriate, abuse
     detection, and response shaping to minimize amplification potential.
     Economic considerations, such as preventing cost shifting to
     responders and preserving fairness across tenants, SHOULD be



  Mozley, et al.            Expires 18 April 2026                 [Page 5]


  Internet-Draft                   AID PS                     October 2025


     incorporated into protocol and operational guidance.

  10.  Connectivity

     Discovery alone is insufficient without practical reachability.  The
     problem statement SHOULD acknowledge challenges introduced by NATs,
     carrier-grade NAT, firewalls, split-horizon networks, and dual-stack
     IPv4/IPv6 environments.  Agents may exist behind egress-only
     boundaries or at the edge with intermittent connectivity.  The system
     MUST not assume stable, symmetric, or publicly routable paths and
     SHOULD define expectations for relay, proxy, or rendezvous patterns
     where direct connectivity is infeasible.

  11.  Attestation and Provenance

     Agents may be required to prove properties about their software and
     runtime environment.  The discovery layer SHOULD carry or reference
     attestations such as software bill of materials, model/version
     identifiers, supply-chain provenance, or trusted-execution
     environment evidence.  Safety classifications, permissible-use
     statements, and risk tiers can be part of discovery metadata to
     enable policy-aware client behavior.

  12.  Challenges with Existing Proposed Mechanisms

     Several alternative approaches to agent discovery have been proposed,
     including centralized registries, blockchain-based naming systems,
     and proprietary service directories.  While these models may offer
     novel features, they introduce significant architectural,
     operational, and governance challenges.  Centralized registries
     concentrate control and introduce single points of failure, limiting
     resilience and scalability.

     Blockchain-based systems often lack integration with existing
     internet infrastructure, suffer from latency and cost constraints,
     and present jurisdictional ambiguity due to decentralized governance.
     Proprietary directories fragment the discovery ecosystem and inhibit
     interoperability across agent frameworks and administrative domains.
     Furthermore, organizations securely delegating authority to AI
     solution providers requires interfacing between this central
     authority as opposed to business-to-business which can be used to
     suppress innovation.









  Mozley, et al.            Expires 18 April 2026                 [Page 6]


  Internet-Draft                   AID PS                     October 2025


     The introduction of a novel discovery protocol would require the
     establishment of new governance structures, security models, and
     operational tooling.  Early implementations would likely be
     centralized among a limited set of stakeholders, introducing
     bottlenecks in protocol evolution and risk mitigation, and could
     result in centralization.

  13.  Security Considerations

     All agent discovery mechanisms need to be secured through public key
     infrastructure.

     All agent discovery mechanisms need to have thread detection.

     All agent discovery mechanisms and security mechanisms need to work
     in real-time.

     All agent discovery mechanisms need to use standardized interfaces or
     APIs in case external security instances are used.

     Protection needed against * DoS attacks * Unauthorized access and
     control * Secure communication framework e.g., TLS 1.3 etc.  *
     Continuous monitoring of the agent discovery mechanism

  14.  IANA Considerations

     This document has no IANA actions.

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

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

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Jim Mozley
     Infoblox, Inc.
     Email: jmozley@infoblox.com



  Mozley, et al.            Expires 18 April 2026                 [Page 7]


  Internet-Draft                   AID PS                     October 2025


     Nic Williams
     Infoblox, Inc.
     Email: nic@infoblox.com


     Behcet Sarikaya
     Unaffiliated
     Email: sarikaya@ieee.org


     Roland Schott
     Deutsche Telekom
     Email: roland.schott@telekom.de






































  Mozley, et al.            Expires 18 April 2026                 [Page 8]


name: draft-gupta-httpapi-events-query
rev: 01
title: HTTP Events Query
time: 2025-10-17T01:02:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-20T01:02:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578675+00:00
source: ietf
abstract:
  Events Query is a minimal protocol built on top of HTTP that allows
     user agents to receive event notifications directly from any resource
     of interest.  The Events Query Protocol (EQP) is predicated on the
     idea that the most intuitive source for event notifications is the
     resource itself.

full_text:
  Building Blocks for HTTP APIs                                   R. Gupta
  Internet-Draft                                           17 October 2025
  Intended status: Standards Track                                        
  Expires: 20 April 2026


                             HTTP Events Query
                    draft-gupta-httpapi-events-query-01

  Abstract

     Events Query is a minimal protocol built on top of HTTP that allows
     user agents to receive event notifications directly from any resource
     of interest.  The Events Query Protocol (EQP) is predicated on the
     idea that the most intuitive source for event notifications is the
     resource itself.

  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://CxRes.github.io/events-query/draft-gupta-httpapi-events-
     query.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-gupta-httpapi-events-query/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/CxRes/events-query.

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



  Gupta                     Expires 20 April 2026                 [Page 1]


  Internet-Draft              HTTP Events Query               October 2025


     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.

     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.  Design  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Constraints . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.4.  Limitations . . . . . . . . . . . . . . . . . . . . . . .   7
       2.5.  Comparison with Server-Sent Events  . . . . . . . . . . .   7
     3.  Conformance . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.  Document Conventions  . . . . . . . . . . . . . . . . . .   8
       3.2.  Requirements Notation . . . . . . . . . . . . . . . . . .   9
     4.  Terminology and Core Concepts . . . . . . . . . . . . . . . .   9
       4.1.  Event . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Observation . . . . . . . . . . . . . . . . . . . . . . .   9
       4.3.  Event Notification  . . . . . . . . . . . . . . . . . . .   9
       4.4.  Subscription  . . . . . . . . . . . . . . . . . . . . . .  10
     5.  Events Header Field . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  duration Property . . . . . . . . . . . . . . . . . . . .  11
     6.  Subscription Data Model . . . . . . . . . . . . . . . . . . .  11
     7.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.  Single Notification . . . . . . . . . . . . . . . . . . . . .  12
       8.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .  13
       8.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.  Notifications Stream  . . . . . . . . . . . . . . . . . . . .  13
       9.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .  14
       9.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . .  15
         9.2.1.  Headers . . . . . . . . . . . . . . . . . . . . . . .  15
         9.2.2.  Notifications . . . . . . . . . . . . . . . . . . . .  16
     10. Representation  . . . . . . . . . . . . . . . . . . . . . . .  17
       10.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . .  17
       10.2.  Response . . . . . . . . . . . . . . . . . . . . . . . .  18



  Gupta                     Expires 20 April 2026                 [Page 2]


  Internet-Draft              HTTP Events Query               October 2025


     11. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  19
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
       13.1.  HTTP Field Registration  . . . . . . . . . . . . . . . .  19
       13.2.  The HTTP Events Field Registry . . . . . . . . . . . . .  20
         13.2.1.  Template . . . . . . . . . . . . . . . . . . . . . .  20
         13.2.2.  Initial Registry Contents  . . . . . . . . . . . . .  20
     14. End User Considerations . . . . . . . . . . . . . . . . . . .  21
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  22
       15.2.  Informative References . . . . . . . . . . . . . . . . .  23
     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  24
       A.1.  Representation and Notifications  . . . . . . . . . . . .  24
         A.1.1.  Request . . . . . . . . . . . . . . . . . . . . . . .  24
         A.1.2.  Response  . . . . . . . . . . . . . . . . . . . . . .  25
       A.2.  Notifications Stream  . . . . . . . . . . . . . . . . . .  26
         A.2.1.  Request . . . . . . . . . . . . . . . . . . . . . . .  26
         A.2.2.  Response  . . . . . . . . . . . . . . . . . . . . . .  26
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
     Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

  1.  Introduction

     HTTP was originally designed as a stateless, request/response
     protocol for transferring hypermedia documents on the web ([HTTP],
     Section 1.2).  This design was adequate for web pages that were
     mostly static and written by hand.

     But web applications have evolved over time to provide increasingly
     dynamic and interactive experiences, requiring near-instantaneous
     updates.  HTTP does not automatically inform clients of changes to a
     resource.  Developers have employed various techniques, such as Comet
     [COMET] and Server-Sent Events [SSE] to work around this constraint,
     but these can be suboptimal for many applications.

     For this reason, web programmers often prefer implementing custom
     messaging systems over alternate protocols such as WebSocket [WS] and
     WebSub [WEBSUB].  Not only does this approach require additional
     layers of code, involving multiple Web APIs and/or userland libraries
     such as socket.io (https://socket.io/), it demands extra coordination
     effort to synchronize representation and notifications across
     multiple protocols.  The dual-protocol approach thus compounds the
     development and maintenance overhead.  Furthermore, deployment at
     scale is challenging with the notifications traffic now opaque to
     network intermediaries.





  Gupta                     Expires 20 April 2026                 [Page 3]


  Internet-Draft              HTTP Events Query               October 2025


     Events Query is a minimal protocol built on top of the Hypertext
     Transfer Protocol [HTTP] that allows applications to request event
     notifications directly from a resource of interest using the QUERY
     method ([HTTP-QUERY], Section 3).

     The objective of this specification is to make the request and
     receipt of event notifications extremely convenient for consumers.
     Events Query allows programmers to incorporate real-time
     functionality in their web applications without the need to switch to
     another protocol.  Further, Events Query can deliver representation
     and notifications from a resource in a single response, obviating any
     need for coordination and saving on unnecessary round trips.

     With the help of a suitable composite media type parser, Events Query
     responses can be consumed with just a few lines of code, as
     illustrated in the JavaScript example below:

     const response = await fetch("http://example.com/foo", {
       method: "QUERY",
       headers: {
         Accept: "application/http",
         "Content-Type": "example/events-query"
       },
       body: JSON.stringify({
         state: { Accept: "text/plain" },
         events: { Accept: "example/event-notification" }
       })
     });

     // split the response into an iterable of representation and notifications
     const splitResponse = splitHTTPResponseStream(response);

     // read the representation
     const {done, value: representation} = await splitResponse.next();
     if (!done) {
       // do something with the representation
     }

     // iterate over notifications
     for await (const notification of splitResponse) {
       // do something with a notification
     }

                      Figure 1: Events Query fetch example







  Gupta                     Expires 20 April 2026                 [Page 4]


  Internet-Draft              HTTP Events Query               October 2025


     Unlike other event notification mechanisms, Events Query supports
     content negotiation for notifications, just like representations.
     Thus, the Events Query Protocol preserves the flexibility of
     interaction afforded by HTTP and extends it to event notifications.

     When combined with suitable data synchronization technologies like
     Conflict Free Replicated Data Types (CRDT) or Operational Transforms
     (OT), event notifications can be used to create "live"
     representations.  This can immensely simplify the task of programming
     multi-author distributed real-time applications.

  2.  Design

     Events Query is predicated on a resource itself being the most
     intuitive source for events on it.  Events Query treats notifications
     as a response to a query for an event occurring on the resource.
     With HTTP allowing representations to provide a potentially unbounded
     stream of data, the Events Query Protocol is also able to communicate
     multiple events on the resource as a stream of notifications.

  2.1.  Goals

     To aid the development of real-time applications, it is imperative
     that the Events Query Protocol reduces the complexity of both servers
     and clients implementing event notifications.  With this in mind, the
     goals of the Events Query Protocol are:

     1.  to provide reliable and in-order transfer of event notifications
         using the Hypertext Transfer Protocol [HTTP].  Clients fetching
         resources over HTTP need not switch to another protocol for
         receiving event notifications.

     2.  to send updates directly from a resource of interest, obviating
         the need for additional resources to be specifically dedicated as
         notification endpoints.  In contrast to existing approaches, this
         frees up the client from the burden of coordinating the response
         from the resource of interest with notifications from an
         endpoint.

     3.  to deliver the representation and notifications in response to a
         single request, minimizing round trips between clients and
         servers.  It also eliminates the need to synchronize the delivery
         of the representation and notifications.








  Gupta                     Expires 20 April 2026                 [Page 5]


  Internet-Draft              HTTP Events Query               October 2025


     4.  to enable the transfer of event notifications using arbitrary
         formats that might be content-negotiated.  This allows
         implementers to serve notifications that are more expressive,
         say, in comparison to existing HTTP-based messaging protocols
         such as Server-Sent Events [SSE].

     5.  to specify transparent notification semantics that empowers
         intermediaries to scale event notifications, improve reliability
         and reduce latency.  Intermediaries shall also be able to
         proactively update caches in real-time.

  2.2.  Constraints

     To the extent feasible, the Events Query:

     1.  adheres to established practices and conventions.  In particular,
         every attempt has been made to reuse existing protocols and
         specifications.  Implementers shall be able to repurpose existing
         tools and libraries for implementing this specification.

     2.  conforms to Representational State Transfer (REST), best
         practices for Building Protocols with HTTP [RFC9205], and Known
         Issues and Best Practices for the Use of Long Polling and
         Streaming in Bidirectional HTTP [RFC6202].  This specification
         can thus be used to extend the capabilities of any existing or
         future resource to additionally serve event notifications over
         HTTP.  This is to afford implementers the opportunity to scale
         notifications with their data and application.

  2.3.  Scope

     The Events Query Protocol specifies:

     1.  A mechanism to discover support for Events Query on a resource
         (Section 7).

     2.  A mechanism to request event notifications from a resource
         (Sections 8.1 and 9.1) along with the representation
         (Section 10.1).

     3.  An abstract data model for requesting event notifications
         (Section 6).

     4.  Response semantics for a single notification (Section 8.2).

     5.  Response semantics for a stream carrying the representation
         (Section 10.2) (if requested) and multiple event notifications
         (Section 9.2).



  Gupta                     Expires 20 April 2026                 [Page 6]


  Internet-Draft              HTTP Events Query               October 2025


     The Events Query Protocol does not specify:

     1.  A realization of the abstract data model used for requesting
         event notifications.

     2.  The events for which a notification might be generated.  This can
         be varied per resource.

     3.  The form or content of an event notification.  Implementations
         have the flexibility to generate event notifications for the
         applications they wish to support on a resource.

     4.  Specific representations for the response stream with multiple
         notifications.

  2.4.  Limitations

     Events Query only allows notifications to be sent for events on a
     given resource.  To transfer event notifications originating from
     multiple resources in a single response, implementations will need to
     mint additional resources to serve as notification endpoints.  This
     is no different from APIs built on top of existing messaging
     protocols (See, for example, WebSocket [WS] and WebSub [WEBSUB]).

     Browsers cap the number of persistent HTTP/1.1 connections per host,
     limiting the suitability of Events Query for web applications in the
     browser that require simultaneous event notifications from multiple
     resources on the same host.  This limitation is identical to that of
     other HTTP-based streaming protocols, such as Server-Sent Events
     [SSE].  Implementations are strongly encouraged to adopt HTTP/2 (or
     later).  HTTP/1.1 servers might consider setting up a reverse proxy
     over HTTP/2 (or later) or implement mitigation strategies, such as,
     maximizing the number of concurrent connections and providing
     alternate hosts for resources.  Implementations might alternatively
     consider using endpoints to provide event notifications for multiple
     resources as previously described.  Clients on a browser requesting
     event notifications over an HTTP/1.1 connection are advised to
     exercise caution when simultaneously opening multiple persistent
     connections to a given host.

  2.5.  Comparison with Server-Sent Events

     At the time of writing, Server-Sent Events (SSE) is the de facto
     mechanism for transferring event notifications over HTTP,
     standardized through the EventSource API [SSE] as part of HTML Living
     Standard by the WHATWG.
     // As of October 2022, HTML Living Standard maintainer Anne van
     // Kesteren has stated (https://github.com/whatwg/html/



  Gupta                     Expires 20 April 2026                 [Page 7]


  Internet-Draft              HTTP Events Query               October 2025


     // issues/8297#issuecomment-1291658863) that WHATWG does not intend
     // to extend EventSource, with reasons for the decision cited in a
     // subsequent comment (https://github.com/whatwg/html/
     // issues/8297#issuecomment-1291658863).

     Server-Sent Events defines the text/event-stream media type to
     transmit event notifications in response to a GET request.  This
     approach is fundamentally inconsistent with terminology defined in
     HTTP Semantics ([HTTP], Section 3.2), transferring a sequence of
     asynchronous messages instead of a representation "that is intended
     to reflect a past, current, or desired state of a given resource".
     Practically, the text/event-stream media type being limited to only
     textual content forces developers to opt for alternative protocols
     such as WebSockets [WS], despite the increased complexity.  The
     EventSource API does not even allow for headers to be sent with
     requests.  This has led to a proliferation of aftermarket hacks
     // such as this (https://www.npmjs.com/package/event-source-plus),
     // this (https://www.npmjs.com/package/@microsoft/fetch-event-
     // source), this (https://www.npmjs.com/package/fetch-event-stream),
     // this (https://www.npmjs.com/package/extended-eventsource), this
     // (https://www.npmjs.com/package/ngx-sse-client) and this
     // (https://www.npmjs.com/package/sse.js) that extend Server-Sent
     Events with support for custom headers, such as for credentials, or
     use the POST method to communicate additional configuration in the
     request body.

     Events Query takes a principled approach to event notifications, as
     established in Section 4.  In particular, the definition of an event
     notification as a "representation" of event(s) (Section 4.3) admits
     the use of arbitrary media types for event notifications.  Clients
     can use content negotiation as well as preconditions in a
     subscription request.  Further, Events Query not only lets clients
     receive both the representation and notifications over the same
     protocol, viz. HTTP, but these can be encapsulated within a single
     HTTP response.  Clients do not need to, say, authenticate multiple
     times, possibly with different mechanisms, to obtain data from the
     same resource or co-ordinate and synchronize multiple response
     streams carrying a representation and notifications.

  3.  Conformance

  3.1.  Document Conventions

     All examples and notes in this specification are non-normative.







  Gupta                     Expires 20 April 2026                 [Page 8]


  Internet-Draft              HTTP Events Query               October 2025


  3.2.  Requirements Notation

     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.

  4.  Terminology and Core Concepts

  4.1.  Event

     An event is the instantaneous effect of the (normal or abnormal)
     termination of the invocation of an operation on an object of
     interest [DESIGN-FRAMEWORK].  The entity invoking an operation is
     termed the *invoker*.

     In the specific context of HTTP, the object of interest is data
     scoped to some resource.  When the operation is an HTTP method, the
     invoker is a user agent.  However, an operation need not be limited
     to an HTTP method, it might just as easily have been invoked using
     another mechanism or protocol.  Events are then an extension of
     resource state (See [HTTP], Section 3.2) in the temporal dimension.

  4.2.  Observation

     An event is considered observable, if an entity outside the invoker
     and object of interest can detect its occurrence [DESIGN-FRAMEWORK].
     This entity is the *observer*.

     It follows from the HTTP uniform interface that the observer is
     always a server.  The events that are observed, the mechanism of
     observation, and information recorded from the event are
     implementation details for the server.

     That an origin server has to assume the role of an observer in order
     to generate event notifications is obvious.  An intermediary, while
     not observing the data scoped to a resource directly, still has the
     possibility to serve as an observer.  An intermediary can observe
     events transmitted by an origin server or another intermediary,
     whether using Events Query or another mechanism, to generate event
     notifications for outbound consumers.

  4.3.  Event Notification

     An event notification, or notification, is information transmitted by
     an observer upon an event or contiguous events on a resource.




  Gupta                     Expires 20 April 2026                 [Page 9]


  Internet-Draft              HTTP Events Query               October 2025


     Events Query extends "information hiding" behind the HTTP uniform
     interface to the temporal dimension by defining communication with
     respect to a transferable notification of the resource event(s),
     rather than transferring the event(s) themselves.

     A target resource might be capable of generating multiple
     notifications for the same event(s) that a subscriber can select from
     using content negotiation.  Hypertext notifications can not only
     provide information about the resource events but also processing
     instructions that help guide the recipient's future actions, for
     example, the possibility to determine the current representation from
     a previous representation.

  4.4.  Subscription

     A subscription is an expression of interest to receive event
     notifications sent to an observer.  The requesting entity is a
     *subscriber*.

     Due to the request/response semantics of HTTP, the subscriber
     coincides with the recipient of event notifications
     ([DESIGN-FRAMEWORK] uses the term _requester_ or _broker_ to identify
     a requesting entity, with the _broker_ and _recipient_ together
     forming the subscriber; for this specification, the distinction is
     not necessary).

     The subscription in the form of a query affords the user agent the
     opportunity to engage in content negotiation for preferred form of
     event notifications (as well as the representation, if simultaneously
     requested).

  5.  Events Header Field

     "Events" is a Dictionary structured header field ([HTTP-SF],
     Section 3.2) to communicate the properties of a response stream to an
     Events Query.

     In a request, the Events header field allows a client to indicate its
     preferences for the properties of the response stream carrying event
     notifications.  The Events header field is not meant for content
     negotiation.

     In a response, the Events header field allows a server to specify the
     properties of a response stream carrying event notifications.







  Gupta                     Expires 20 April 2026                [Page 10]


  Internet-Draft              HTTP Events Query               October 2025


     The order of keys in the Events header field is insignificant.
     Senders SHOULD NOT generate keys not registered with the HTTP Event
     Field Registry (with the exception made to allow experimentation).
     Recipients MAY ignore keys that they are unaware of.

  5.1.  duration Property

     The "duration" property is an Integer ([HTTP-SF], Section 3.3.1) or
     Decimal ([HTTP-SF], Section 3.3.2) valued Dictionary key specified on
     the Events header field to communicate the response duration in
     seconds.

     In a request, the duration property indicates the duration for which
     a client wants to receive event notifications.  A server MAY ignore
     this property.

     In a response, the duration property specifies the maximum duration
     for which a server intends to serve event notifications.  This
     property is merely advisory, and a server MAY close the response
     stream before this duration.

     Only positive values are valid.  A value of 0 indicates an indefinite
     duration.  A sender MUST conform to these stipulations when
     generating the duration property.  If the value of the duration
     property fails to conform to these stipulations, it MUST be ignored
     by the recipient.

  6.  Subscription Data Model

     The abstract data model specifies the semantics of an Events Query.

     A realization of the data model allows a client to specify in a
     subscription request:

     *  an interest in receiving a stream of event notifications from a
        resource in a preferred form.

     *  an interest in receiving a representation of a resource in a
        preferred form.

     Implementations can choose appropriate media types to realize the
     subscription data model.  Implementations are free to extend the data
     model to include additional data.  A specific realization of the data
     model is outside the scope of this specification.







  Gupta                     Expires 20 April 2026                [Page 11]


  Internet-Draft              HTTP Events Query               October 2025


     The following example shows the body of a subscription request
     wherein the state and events properties are used to specify request
     headers for representation and event notifications respectively in a
     YAML-like syntax.

     state:
       Accept: text/html
     events:
       Accept: example/event-notification

            Figure 2: Events Query Data Model in a YAML-like syntax

  7.  Discovery

     A user agent can discover if a server enables Events Query on a
     resource by examining support for query with a media type that can
     realize the Subscription Data Model.  A server MUST advertise media
     types accepted for Events Query using the Accept-Query header field
     ([HTTP-QUERY], Section 3) in a response.

     HEAD /foo HTTP/1.1
     Host: example.org

                          Figure 3: Discovery Request

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:00:00 GMT
     Accept: text/html
     Accept-Query: "example/events-query"

                          Figure 4: Discovery Response

        |  *Implementation Advice*
        |  
        |  Servers are advised against enabling event notifications on
        |  long-lived resources over HTTP.  A resource might be considered
        |  long-lived, if a server determines a low probability of an
        |  event on the resource in the duration of the response.  In such
        |  instances, servers are strongly advised to respond with the
        |  Cache-Control ([HTTP-CACHING], Section 5) header field and the
        |  max-age parameter ([HTTP-CACHING], Section 5.2.2.1) set in it.

  8.  Single Notification

     The simplest Events Query is to request a notification for the next
     event(s) on a resource.  This, in effect, adds long polling
     capability ([RFC6202], Section 2) to a resource.




  Gupta                     Expires 20 April 2026                [Page 12]


  Internet-Draft              HTTP Events Query               October 2025


  8.1.  Request

     To receive a single notification, a client makes a QUERY request
     ([HTTP-QUERY], Section 3) using a realization of the subscription
     data model that MUST NOT include an interest in receiving a stream of
     event notifications.

     Since the content of the response is an event notification, a client
     can negotiate its form with header fields in the usual manner.

     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: example/event-notification
     Content-Type: example/events-query
     Events: duration=0

     ---

                  Figure 5: Single Event Notification Request

  8.2.  Response

     When a single notification is requested, the server MUST close the
     connection immediately after sending the event notification.

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:10:10 GMT
     Accept-Query: example/events-query
     Content-Type: example/event-notification
     Incremental: ?1

     published: 2025-01-02T10:11:12.345Z
     event-id: 456
     type: update

                  Figure 6: Single Event Notification Response


        |  *Implementation Advice*
        |  
        |  When a user navigates away from a website or an application
        |  using Events Query, user agents are strongly encouraged to
        |  properly close the response and release the connection.

  9.  Notifications Stream

     Events Query can also be used to request a stream of multiple event
     notifications ([RFC6202], Section 3).



  Gupta                     Expires 20 April 2026                [Page 13]


  Internet-Draft              HTTP Events Query               October 2025


  9.1.  Request

     To receive multiple notifications, a client makes a QUERY request
     ([HTTP-QUERY], Section 3) using a realization of the subscription
     data model that MUST include an interest in receiving a stream of
     event notifications in a preferred form.

     Since the response transmits event notifications within an
     encapsulating representation (Section 9.2), it follows that header
     fields cannot be used to negotiate the form of event notifications as
     in the case of Single Notification Request (Section 8.1).  Instead,
     header fields are useful for negotiating the representation that
     encapsulates event notifications.  The following examples illustrate
     subscription requests that negotiate a stream of event notifications
     to be transferred respectively using a composite media type
     (application/http) and a discrete media type (application/json-seq):

     The first example shows a subscription request for effectively a
     stream of discrete Single Notifications (Section 8) to be transferred
     using application/http ([HTTP/1.1], Section 10.2) as the
     encapsulating media type.  The events property in this example
     indicates an interest in receiving event notifications and its sub-
     properties describe the preferred form of notifications.  Since the
     notifications are transferred as a pipeline of HTTP messages, these
     sub-properties are identical to header fields (Section 8.1, Paragraph
     2) used for specifying preconditions and content negotiation in a
     Single Notification Request (Section 8.1).

     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: application/http
     Content-Type: example/events-query
     Events: duration=0

     events:
       Accept: example/event-notification

                Figure 7: Request for HTTP Notifications Stream

     The second example shows a subscription request for a stream of JSON
     notifications to be transferred using application/json-seq
     ([RFC7464]) as the encapsulating media type.  The events property in
     this example is being used to communicate the preferred schema for
     the requested event notifications.







  Gupta                     Expires 20 April 2026                [Page 14]


  Internet-Draft              HTTP Events Query               October 2025


     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: application/json-seq
     Content-Type: example/events-query
     Events: duration=0

     events:
       @context: activity+json

                Figure 8: Request for JSON Notifications Stream

  9.2.  Response

     The response stream transmits multiple event notifications in an
     encapsulating media type.  The following illustrates event
     notifications streamed in both a composite media type (application/
     http) and a discrete media type (application/json-seq) in response to
     the example requests (Section 9.1) in Section 9.1.

  9.2.1.  Headers

     A server able to provide a stream of event notifications MUST
     immediately send headers, which include:

     *  The Events header field, to communicate the properties of the
        notifications stream.

        -  The duration property, set to the maximum duration for which
           the server intends to serve event notifications.

     *  The Incremental header field ([INCREMENTAL-HTTP-MESSAGES],
        Section 3) set to ?1 to indicate that the response is to be
        immediately forwarded by intermediaries and not buffered.

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:10:10 GMT
     Accept-Query: example/events-query
     Events: duration=600
     Incremental: ?1
     Transfer-Encoding: chunked

                Figure 9: Notifications Stream Response Headers

        |  Since the Content-Type header field varies in response to the
        |  requests in Figure 7 and Figure 8, it has been omitted here.






  Gupta                     Expires 20 April 2026                [Page 15]


  Internet-Draft              HTTP Events Query               October 2025


  9.2.2.  Notifications

     Subsequently, when event(s) occur, the server transmits a
     notification.

     An event notification transferred in an application/http response
     stream is identical to the Single Notification Response
     (Section 8.2), except fields which are redundant with the response
     headers (Section 9.2.1) are omitted.

     HTTP/1.1 200 OK                                  | Notification
     Content-Length: 31                               |
     Content-Type: example/event-notification         |
                                                      |
     published: 2025-01-02T10:11:12.345Z              |
     event-id: 456                                    |
     type: update                                     |

                      Figure 10: HTTP Update Notification

     The same event notification when transferred in an application/json-
     seq response stream is as follows:

     ␞{                                              | Notification
       "published": "2025-01-02T10:11:12.345Z",       |
       "event-id": 456,                               |
       "type": "Update"                               |
     }                                                |

                      Figure 11: JSON Update Notification

     A server MUST end the response immediately after transmitting the
     event notification that signals the deletion of a resource.

     The notification for a delete event expressed as an HTTP message
     might be as follows:

     HTTP/1.1 200 OK                                  | Notification
     Content-Length: 31                               |
     Content-Type: example/event-notification         |
                                                      |
     published: 2025-01-02T11:12:13.456Z              |
     event-id: 789                                    |
     type: delete                                     |

                      Figure 12: HTTP Delete Notification

     The same notification for a delete event in JSON would be as follows:



  Gupta                     Expires 20 April 2026                [Page 16]


  Internet-Draft              HTTP Events Query               October 2025


     ␞{                                              | Notification
       "published": "2025-01-02T11:12:13.456Z",       |
       "event-id": 789,                               |
       "type": "delete"                               |
     }                                                |

                      Figure 13: JSON Delete Notification

     Otherwise, a server MUST end the response when the connection
     duration exceeds the period set in the duration property of the
     Events header field.

  10.  Representation

     Events Query enables a user agent to ask and receive the current
     representation and subsequent event notifications in a single
     request/response.  When compared to using, say, Fetch [FETCH] and
     EventSource [SSE] in conjunction, Events Query not only saves on an
     extra round trip, but relieves a user agent from the burden of
     synchronizing the representation with event notifications.

  10.1.  Request

     To receive a representation of the resource alongside notifications,
     a client makes a QUERY request ([HTTP-QUERY], Section 3) using a
     realization of the subscription data model that MUST also include an
     interest in receiving the representation in a preferred form.

     The following example shows a subscription request for the current
     representation along with the subsequent event notifications
     transmitted using the application/http media type.  The state
     property indicates interest in receiving representation and its sub-
     properties describe the preferred form of notifications.  Since the
     representation is being transferred in an HTTP message pipeline,
     these sub-properties are identical to header fields used for
     specifying preconditions and content negotiation in a GET request on
     the said resource.

     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: application/http
     Content-Type: example/events-query

     state:
       Accept: text/html
     events:
       Accept: example/event-notification




  Gupta                     Expires 20 April 2026                [Page 17]


  Internet-Draft              HTTP Events Query               October 2025


            Figure 14: HTTP Representation and Notifications Request

  10.2.  Response

     A server unable to provide a representation MUST NOT serve event
     notifications.  This does not apply to a conditional request for
     representation that is not fulfilled.

     A server able to provide a stream with a representation and event
     notifications transmits the representation immediately following the
     response headers (Section 9.2.1).  Otherwise, the response is the
     same as that described in Section 9.2.

     Again, the application/http media type ([HTTP/1.1], Section 10.2) is
     used for the purpose of illustration.  Chunks have been omitted for
     clarity.

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:10:10 GMT
     Accept-Query: example/events-query
     Events: duration=600
     Incremental: ?1
     Transfer-Encoding: chunked

     HTTP/1.1 200 OK                                  | Representation
     Content-Length: 14                               |
     Content-Type: text/plain                         |
                                                      |
     Hello World!                                     |

            Figure 15: Representation Response before Notifications

     While this is default behaviour, there is no requirement that a
     representation is the first message or that representations are sent
     only once.  In such cases, the encapsulated message needs to indicate
     if it is a representation and not an event notification.  Such a
     mechanism is not defined in this specification.

     Notifications are transmitted just as in the case of regular
     streaming (Section 9.2).  See Appendix A.1 for a complete example of
     a response with representation and notifications.

  11.  Implementation Status

     A toy server built in Express.js demonstrating the Events Query
     Protocol is available at https://github.com/CxRes/events-query-
     express-demo.  This demo is powered by the following libraries:




  Gupta                     Expires 20 April 2026                [Page 18]


  Internet-Draft              HTTP Events Query               October 2025


     *  Negotiate Events Field (https://github.com/CxRes/negotiate-events-
        field): To read the request Events header field (Section 5) and
        negotiate the response duration (Section 5.1),

     *  NOSE (https://github.com/CxRes/nose): To observe events on
        resources and generate notifications in a preferred format, and

     *  Extended Response (https://github.com/CxRes/extended-response): To
        write the representation and event notifications on the response
        stream for a given duration (Section 5.1).

     The demonstration and libraries are Free and Open Source Software,
     released under the Mozilla Public License, v. 2.0.  Please contact
     the author for more information about these programs.

  12.  Security Considerations

     Events Query is subject to the security considerations of the HTTP
     QUERY method ([HTTP-QUERY], Section 2) and more generally HTTP
     Semantics.  Considerations relevant to the use of HTTP QUERY method
     are discussed in Section 4 of [HTTP-QUERY].  HTTP Semantics and its
     use for transferring information over the Internet are discussed in
     Section 17 of [HTTP].

     When serving event notifications, servers are required to keep the
     response stream open for an extended period of time.  Since the
     effort required to request notifications is tiny compared to the
     time, memory, and bandwidth consumed attempting to serve the
     notifications, servers implementing Events Query have increased
     susceptibility to Denial-of-Service attacks.  Servers ought to
     ignore, coalesce, or reject egregious subscription requests, such as
     repeated requests from the same origin within a short interval of
     time.

  13.  IANA Considerations

     The change controller for the following registrations is: "IETF
     (iesg@ietf.org) - Internet Engineering Task Force".

  13.1.  HTTP Field Registration

     IANA is requested to add the following entry in the "Hypertext
     Transfer Protocol (HTTP) Field Name Registry
     (https://www.iana.org/assignments/http-fields/)" (See Section 16.1.1
     of [HTTP]):






  Gupta                     Expires 20 April 2026                [Page 19]


  Internet-Draft              HTTP Events Query               October 2025


       +====================+===========+=================+===========+
       | Header Field Names | Status    | Structured-Type | Reference |
       +====================+===========+=================+===========+
       | Events             | Permanent | Dictionary      | Section 5 |
       +--------------------+-----------+-----------------+-----------+

                Table 1: List of HTTP Field Name registrations

  13.2.  The HTTP Events Field Registry

     IANA is requested to create a new registry, "HTTP Events Field
     Registry", under the Hypertext Transfer Protocol (HTTP) Parameters
     (https://www.iana.org/assignments/http-parameters/) registry to
     register properties for use in the Events header field.  New
     registrations will use the Specification Required policy ([RFC8126],
     Section 4.6).

  13.2.1.  Template

     The registration of an Events property MUST include the following
     fields:

     *  Property Name: A Dictionary ([HTTP-SF], Section 3.2) key to be
        used in the Events header field.

     *  Structured Type: The Structured Data Type ([HTTP-SF], Section 3.3)
        of the value associated with the key, according to requirements in
        Section 3.2 of [HTTP-SF].

     *  Reference: A pointer to the specification text.

     The registration MAY also include the following fields:

     *  Optional Parameters: An enumeration of optional parameters and the
        Structured Data Type (Section 3.3 of [HTTP-SF]) of value
        associated with the parameter, according to requirements in
        Section 3.1.2 of [HTTP-SF]

     *  Comments: Additional information to be included in the template.

  13.2.2.  Initial Registry Contents

     The initial contents of the HTTP Events Field Registry are:








  Gupta                     Expires 20 April 2026                [Page 20]


  Internet-Draft              HTTP Events Query               October 2025


           +===============+=========================+=============+
           | Property Name | Structured-Type         | Reference   |
           +===============+=========================+=============+
           | duration      | Integer or Decimal Item | Section 5.1 |
           +---------------+-------------------------+-------------+

                Table 2: List of HTTP Events Field property name
                                 registrations

  14.  End User Considerations


     // If we, the IETF, claim that the Internet is for the end user
     // [RFC8890] and promote the end-to-end principle [RFC3724], every
     // specification we produce ought to consider its impact on the
     // Internet end user.  For this reason, I propose that specifications
     // must include a considerations section where authors assess the
     // impact of their proposal on the Internet end user, aligned with
     // the mission of IETF [RFC3935].

     End users of the HTTP protocol can be classified into two groups:
     publishers and consumers.  Consumers have an incentive to subscribe
     to event notifications from many resources and to hold on to a
     connection for as long as possible.  Whereas publishers bear the cost
     of server infrastructure.  Consumers also typically outnumber
     publishers, in many cases by multiple orders of magnitude.  This
     creates an imbalance in the effort to subscribe versus effort to
     deliver; consumers can easily place a disproportionate burden on
     servers, reminiscent of a denial-of-service attack.

     At the outset, requiring that clients subscribe to event
     notifications per resource serves as an effective filtering mechanism
     that limits the burden on servers.  Compare this to the typical
     implementation of protocols such as WebSockets [WS], where clients
     connect to dedicated endpoints to receive notifications; the server
     either has to broadcast notifications for multiple resources or track
     resources of interest for each client to filter event notifications
     accordingly.

     Events Query empowers servers to decide the content and the duration
     for which event notifications are served on any given resource, as
     well as allowing servers to close the response stream at any time.
     Servers may also limit event notifications and/or their content,
     except for authenticated consumers.  Such authenticated consumers
     might, for example, be asked to share the cost burden with publishers
     in return for a higher quality of service.





  Gupta                     Expires 20 April 2026                [Page 21]


  Internet-Draft              HTTP Events Query               October 2025


     The use of HTTP Semantics also enables intermediation of event
     notifications, unlike existing mechanisms built with protocols such
     as WebSockets [WS] or WebSub [WEBSUB].  Intermediaries can help with
     improving the latency and reliability of transmission of event
     notifications as well as scaling of the event notification traffic to
     reach a significantly larger base of consumers.  On the flip side,
     economies of scale will likely lead to greater consolidation of
     intermediary service providers (though not centralization) with the
     attendant risk of anti-consumer behaviour.  In the opinion of the
     authors, policies designed to treat network traffic as a public
     utility might provide better outcomes for the end user.

  15.  References

  15.1.  Normative References

     [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [HTTP-QUERY]
                Reschke, J., Snell, J. M., and M. Bishop, "The HTTP QUERY
                Method", Work in Progress, Internet-Draft, draft-ietf-
                httpbis-safe-method-w-body-12, 29 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
                safe-method-w-body-12>.

     [HTTP-SF]  Nottingham, M. and P. Kamp, "Structured Field Values for
                HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
                <https://www.rfc-editor.org/rfc/rfc9651>.

     [INCREMENTAL-HTTP-MESSAGES]
                Oku, K., Pauly, T., and M. Thomson, "Incremental HTTP
                Messages", Work in Progress, Internet-Draft, draft-ietf-
                httpbis-incremental-00, 29 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
                incremental-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>.

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



  Gupta                     Expires 20 April 2026                [Page 22]


  Internet-Draft              HTTP Events Query               October 2025


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

  15.2.  Informative References

     [COMET]    Russell, A., "Comet: Low Latency Data for the Browser",
                Infrequently Noted, March 2006,
                <https://infrequently.org/2006/03/comet-low-latency-data-
                for-the-browser/>.

     [DESIGN-FRAMEWORK]
                Rosenblum, D. and A. Wolf, "A design framework for
                Internet-scale event observation and notification",
                Association for Computing Machinery (ACM), ACM SIGSOFT
                Software Engineering Notes vol. 22, no. 6, pp. 344-360,
                DOI 10.1145/267896.267920, November 1997,
                <https://doi.org/10.1145/267896.267920>.

     [FETCH]    van Kesteren, A., "Fetch", WHATWG Living Standard, May
                2025, <https://fetch.spec.whatwg.org>.

     [HTTP-CACHING]
                Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", STD 98, RFC 9111,
                DOI 10.17487/RFC9111, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9111>.

     [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
                June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

     [REST]     Fielding, R., "Representational State Transfer (REST)",
                Chapter 5, Architectural Styles and the Design of Network-
                based Software Architectures, Doctoral
                Dissertation University of California, Irvine,
                <https://roy.gbiv.com/pubs/dissertation/
                rest_arch_style.htm>.

     [RFC3724]  Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
                the Middle and the Future of End-to-End: Reflections on
                the Evolution of the Internet Architecture", RFC 3724,
                DOI 10.17487/RFC3724, March 2004,
                <https://www.rfc-editor.org/rfc/rfc3724>.

     [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
                BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
                <https://www.rfc-editor.org/rfc/rfc3935>.



  Gupta                     Expires 20 April 2026                [Page 23]


  Internet-Draft              HTTP Events Query               October 2025


     [RFC6202]  Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
                "Known Issues and Best Practices for the Use of Long
                Polling and Streaming in Bidirectional HTTP", RFC 6202,
                DOI 10.17487/RFC6202, April 2011,
                <https://www.rfc-editor.org/rfc/rfc6202>.

     [RFC7464]  Williams, N., "JavaScript Object Notation (JSON) Text
                Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
                <https://www.rfc-editor.org/rfc/rfc7464>.

     [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
                Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
                April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

     [RFC8890]  Nottingham, M., "The Internet is for End Users", RFC 8890,
                DOI 10.17487/RFC8890, August 2020,
                <https://www.rfc-editor.org/rfc/rfc8890>.

     [RFC9205]  Nottingham, M., "Building Protocols with HTTP", BCP 56,
                RFC 9205, DOI 10.17487/RFC9205, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9205>.

     [SSE]      "Server-Sent Events", W3C REC eventsource,
                W3C eventsource, <https://www.w3.org/TR/eventsource/>.

     [WEBSUB]   "WebSub", W3C REC websub, W3C websub,
                <https://www.w3.org/TR/websub/>.

     [WS]       "The WebSocket API", W3C NOTE websockets, W3C websockets,
                <https://www.w3.org/TR/websockets/>.

  Appendix A.  Examples

     Some examples used in this specification are consolidated below.
     Chunks have been omitted for clarity.

  A.1.  Representation and Notifications

     The following example illustrates a complete request and response for
     representation and notifications transferred with the application/
     http media-type as described in Section 10: Representation.

  A.1.1.  Request








  Gupta                     Expires 20 April 2026                [Page 24]


  Internet-Draft              HTTP Events Query               October 2025


     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: application/http
     Content-Type: example/events-query

     state:
       Accept: text/html
     events:
       Accept: example/event-notification

            Figure 16: Request for Representation and Notifications

  A.1.2.  Response

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:10:10 GMT
     Accept-Query: example/events-query
     Events: duration=600
     Incremental: ?1
     Transfer-Encoding: chunked
     Content-Type: application/http

     HTTP/1.1 200 OK                                  | Representation
     Content-Length: 14                               |
     Content-Type: text/plain                         |
                                                      |
     Hello World!                                     |

     HTTP/1.1 200 OK                                  | Notification
     Content-Length: 31                               |
     Content-Type: example/event-notification         |
                                                      |
     published: 2025-01-02T10:11:12.345Z              |
     event-id: 456                                    |
     type: update                                     |

     HTTP/1.1 200 OK                                  | Notification
     Content-Length: 31                               |
     Content-Type: example/event-notification         |
                                                      |
     published: 2025-01-02T11:12:13.456Z              |
     event-id: 789                                    |
     type: delete                                     |

           Figure 17: Response with Representation and Notifications






  Gupta                     Expires 20 April 2026                [Page 25]


  Internet-Draft              HTTP Events Query               October 2025


  A.2.  Notifications Stream

     This following example illustrates complete request and response for
     JSON formatted notifications transferred with the application/json-
     seq media-type as described in Notifications Stream: Notifications
     Stream.

  A.2.1.  Request

     QUERY /foo HTTP/1.1
     Host: example.org
     Accept: application/json-seq
     Content-Type: example/events-query
     Events: duration=0

     events:
       @context: activity+json

                   Figure 18: Request for JSON Notifications

  A.2.2.  Response

     HTTP/1.1 200 OK
     Date: Thu, 02 Jan 2025 10:10:10 GMT
     Accept-Query: example/events-query
     Events: duration=600
     Incremental: ?1
     Transfer-Encoding: chunked
     Content-Type: application/json-seq

     ␞{                                              | Notification
       "published": "2025-01-02T10:11:12.345Z",       |
       "event-id": 456,                               |
       "type": "Update"                               |
     }                                                |
     ␞{                                              | Notification
       "published": "2025-01-02T11:12:13.456Z",       |
       "event-id": 789,                               |
       "type": "delete"                               |
     }                                                |

                  Figure 19: Response with JSON Notifications









  Gupta                     Expires 20 April 2026                [Page 26]


  Internet-Draft              HTTP Events Query               October 2025


  Acknowledgments

     We thank members of the HTTP Working Group, the HTTPAPI Working
     Group, the Solid community, the Braid community and others for
     discussions, ideas, reviews, and feedback on previous work that has
     led to this specification.

  Index

     D E I N O S

        D

           data model  Section 2.3, Paragraph 2.3.1; Section 2.3,
              Paragraph 4.1.1; *_Section 6_*; Section 8.1, Paragraph 1;
              Section 9.1, Paragraph 1; Section 10.1, Paragraph 1
           duration (property)  *_Section 5.1_*; Section 9.2.1, Paragraph
              2.1.2.1.1; Section 9.2.2, Paragraph 11; Section 11,
              Paragraph 2.1.1; Section 11, Paragraph 2.3.1; Table 2

        E

           event  Section 2, Paragraph 1; Section 2.3, Paragraph 4.2.1;
              Section 2.4, Paragraph 1; Section 2.5, Paragraph 3;
              *_Section 4.1_*; Section 4.2, Paragraph 1; Section 4.2,
              Paragraph 2; Section 4.2, Paragraph 3; Section 4.3,
              Paragraph 1; Section 4.3, Paragraph 2; Section 4.3,
              Paragraph 3; Section 5, Paragraph 4; Section 7, Paragraph
              4.2; Section 8, Paragraph 1; Section 8.1, Paragraph 1;
              Section 9.2.2, Paragraph 1; Section 9.2.2, Paragraph 7;
              Section 9.2.2, Paragraph 9; Section 11, Paragraph 2.2.1
           event notification  Section Abstract, Paragraph 1; Section 1,
              Paragraph 3; Section 1, Paragraph 4; Section 1, Paragraph 5;
              Section 1, Paragraph 8; Section 1, Paragraph 9; Section 2,
              Paragraph 1; Section 2.1, Paragraph 1; Section 2.1,
              Paragraph 2.1.1; Section 2.1, Paragraph 2.2.1; Section 2.1,
              Paragraph 2.3.1; Section 2.1, Paragraph 2.4.1; Section 2.1,
              Paragraph 2.5.1; Section 2.2, Paragraph 2.2.1; Section 2.3,
              Paragraph 2.2.1; Section 2.3, Paragraph 2.3.1; Section 2.3,
              Paragraph 4.1.1; Section 2.3, Paragraph 4.2.1; Section 2.3,
              Paragraph 4.3.1; Section 2.3, Paragraph 4.4.1; Section 2.4,
              Paragraph 1; Section 2.4, Paragraph 2; Section 2.5,
              Paragraph 1; Section 2.5, Paragraph 2; Section 2.5,
              Paragraph 3; Section 4.2, Paragraph 3; *_Section 4.3_*;
              Section 4.3, Paragraph 1; Section 4.3, Paragraph 2;
              Section 4.3, Paragraph 3; Section 4.4, Paragraph 1;
              Section 4.4, Paragraph 2; Section 4.4, Paragraph 3;
              Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5.1,



  Gupta                     Expires 20 April 2026                [Page 27]


  Internet-Draft              HTTP Events Query               October 2025


              Paragraph 2; Section 5.1, Paragraph 3; Section 6, Paragraph
              3.1.1; Section 6, Paragraph 5; Section 7, Paragraph 4.2;
              Section 8, Paragraph 1; Section 8.1, Paragraph 1;
              Section 8.1, Paragraph 2; Section 8.2, Paragraph 1;
              Section 9, Paragraph 1; Section 9.1, Paragraph 1;
              Section 9.1, Paragraph 2; Section 9.1, Paragraph 3;
              Section 9.1, Paragraph 5; Section 9.2, Paragraph 1;
              Section 9.2.1, Paragraph 1; Section 9.2.1, Paragraph 2.1.1;
              Section 9.2.1, Paragraph 2.1.2.1.1; Section 9.2.2, Paragraph
              1; Section 9.2.2, Paragraph 2; Section 9.2.2, Paragraph 4;
              Section 9.2.2, Paragraph 6; Section 9.2.2, Paragraph 7;
              Section 9.2.2, Paragraph 9; Section 10, Paragraph 1;
              Section 10.1, Paragraph 1; Section 10.1, Paragraph 2;
              Section 10.2, Paragraph 1; Section 10.2, Paragraph 2;
              Section 10.2, Paragraph 5; Section 10.2, Paragraph 6;
              Section 11, Paragraph 2.2.1; Section 11, Paragraph 2.3.1;
              Section 12, Paragraph 2; Section 14, Paragraph 2;
              Section 14, Paragraph 3; Section 14, Paragraph 4;
              Section 14, Paragraph 5; Appendix A.1, Paragraph 1;
              Appendix A.2, Paragraph 1
           events (header field)  *_Section 5_*; Section 9.2.1, Paragraph
              2.1.1; Section 9.2.2, Paragraph 11; Section 11, Paragraph
              2.1.1; Table 1; Section 13.2, Paragraph 1; Section 13.2.1,
              Paragraph 1; Section 13.2.1, Paragraph 2.1.1

        I

           invoker  *_Section 4.1, Paragraph 1_*; Section 4.1, Paragraph
              2; Section 4.2, Paragraph 1

        N

           notification  Section Abstract, Paragraph 1; Section 1,
              Paragraph 3; Section 1, Paragraph 4; Section 1, Paragraph 5;
              Section 1, Paragraph 8; Section 1, Paragraph 9; Section 2,
              Paragraph 1; Section 2.1, Paragraph 1; Section 2.1,
              Paragraph 2.1.1; Section 2.1, Paragraph 2.2.1; Section 2.1,
              Paragraph 2.3.1; Section 2.1, Paragraph 2.4.1; Section 2.1,
              Paragraph 2.5.1; Section 2.2, Paragraph 2.2.1; Section 2.3,
              Paragraph 2.2.1; Section 2.3, Paragraph 2.3.1; Section 2.3,
              Paragraph 4.1.1; Section 2.3, Paragraph 4.2.1; Section 2.3,
              Paragraph 4.3.1; Section 2.3, Paragraph 4.4.1; Section 2.4,
              Paragraph 1; Section 2.4, Paragraph 2; Section 2.5,
              Paragraph 1; Section 2.5, Paragraph 2; Section 2.5,
              Paragraph 3; Section 4.2, Paragraph 3; *_Section 4.3_*;
              Section 4.3, Paragraph 1; Section 4.4, Paragraph 1;
              Section 4.4, Paragraph 2; Section 4.4, Paragraph 3;
              Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5.1,



  Gupta                     Expires 20 April 2026                [Page 28]


  Internet-Draft              HTTP Events Query               October 2025


              Paragraph 2; Section 5.1, Paragraph 3; Section 6, Paragraph
              3.1.1; Section 6, Paragraph 5; Section 7, Paragraph 4.2;
              Section 8, Paragraph 1; Section 8.1, Paragraph 1;
              Section 8.1, Paragraph 2; Section 8.2, Paragraph 1;
              Section 9, Paragraph 1; Section 9.1, Paragraph 1;
              Section 9.1, Paragraph 2; Section 9.1, Paragraph 3;
              Section 9.1, Paragraph 5; Section 9.2, Paragraph 1;
              Section 9.2.1, Paragraph 1; Section 9.2.1, Paragraph 2.1.1;
              Section 9.2.1, Paragraph 2.1.2.1.1; Section 9.2.2, Paragraph
              1; Section 9.2.2, Paragraph 2; Section 9.2.2, Paragraph 4;
              Section 9.2.2, Paragraph 6; Section 9.2.2, Paragraph 7;
              Section 9.2.2, Paragraph 9; Section 10, Paragraph 1;
              Section 10.1, Paragraph 1; Section 10.1, Paragraph 2;
              Section 10.2, Paragraph 1; Section 10.2, Paragraph 2;
              Section 10.2, Paragraph 5; Section 10.2, Paragraph 6;
              Section 11, Paragraph 2.2.1; Section 11, Paragraph 2.3.1;
              Section 12, Paragraph 2; Section 14, Paragraph 2;
              Section 14, Paragraph 3; Section 14, Paragraph 4;
              Section 14, Paragraph 5; Appendix A.1, Paragraph 1;
              Appendix A.2, Paragraph 1

        O

           observation  *_Section 4.2_*; Section 11, Paragraph 2.2.1
           observer  *_Section 4.2, Paragraph 1_*; Section 4.2, Paragraph
              2; Section 4.2, Paragraph 3; Section 4.3, Paragraph 1;
              Section 4.4, Paragraph 1

        S

           subscriber  Section 4.3, Paragraph 3; *_Section 4.4, Paragraph
              1_*; Section 4.4, Paragraph 2
           subscription  Section 2.5, Paragraph 3; *_Section 4.4_*;
              Section 6, Paragraph 2; Section 6, Paragraph 4; Section 6,
              Paragraph 5; Section 8.1, Paragraph 1; Section 9.1,
              Paragraph 1; Section 9.1, Paragraph 2; Section 9.1,
              Paragraph 3; Section 9.1, Paragraph 5; Section 10.1,
              Paragraph 1; Section 10.1, Paragraph 2; Section 12,
              Paragraph 2

  Author's Address

     Rahul Gupta
     Email: cxres+ietf@protonmail.com







  Gupta                     Expires 20 April 2026                [Page 29]


name: draft-jewell-aibdp
rev: 00
title: AI Boundary Declaration Protocol (AIBDP)
time: 2026-02-16T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-15T23:59:42Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578679+00:00
source: ietf
abstract:
  This document defines the AI Boundary Declaration Protocol (AIBDP), a
     declarative framework for expressing usage boundaries around web-
     hosted content in relation to AI systems.  It builds on the
     mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
     of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
     provide machine-readable permissions and denials for indexing,
     training, mimicry, representation, derivative construction,
     analytical exploitation, and agentic access.  AIBDP supports ethical
     infrastructure, agentic AI governance, and procedural clarity across
     the Internet.

full_text:
  Network Working Group                                       JDAJ. Jewell
  Internet-Draft                             National Union of Journalists
  Intended status: Informational                            15 August 2025
  Expires: 16 February 2026


                  AI Boundary Declaration Protocol (AIBDP)
                           draft-jewell-aibdp-00

  Abstract

     This document defines the AI Boundary Declaration Protocol (AIBDP), a
     declarative framework for expressing usage boundaries around web-
     hosted content in relation to AI systems.  It builds on the
     mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
     of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
     provide machine-readable permissions and denials for indexing,
     training, mimicry, representation, derivative construction,
     analytical exploitation, and agentic access.  AIBDP supports ethical
     infrastructure, agentic AI governance, and procedural clarity across
     the Internet.

  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 16 February 2026.

  Copyright Notice

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








  Jewell                  Expires 16 February 2026                [Page 1]


  Internet-Draft              Consent Required                 August 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Manifest Format . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Consent States  . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   4
     6.  Interoperability with HTTP 430  . . . . . . . . . . . . . . .   4
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
     Appendix A.  Appendix A.  Implementation Examples . . . . . . . .   5
     Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     As AI systems become increasingly capable of autonomous interaction,
     generation, and ingestion of online content, current technical
     governance mechanisms such as robots.txt [RFC9309], security.txt
     [RFC9116], HTTP semantics per RFC 9110, and licensing-metadata fail
     to communicate granular boundaries for ethical AI use.  AIBDP
     introduces a declarative perimeter protocol designed to enable web
     publishers and institutions to express machine-readable consent
     declarations for specific categories of AI use, including indexing,
     training, agentic access, stylistic imitation, derivative prompting,
     analytic harvesting, and infrastructural activation.

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

  2.  Definitions

     AIBDP declarations may be conveyed through:

     *  .well-known/aibdp.json manifest

     *  HTTP response headers (e.g., GenAI-Consent)

     *  DNS TXT records



  Jewell                  Expires 16 February 2026                [Page 2]


  Internet-Draft              Consent Required                 August 2025


     *  HTML meta tags

     Declaration keys are grouped by category:

     *  consent: indexing, training, generation

     *  agentic: access, fallback

     *  representation: embedding, summarization, metadataHarvesting,
        multiHopRetrieval

     *  influence: stylisticImitation, thematicRegeneration,
        partialSampling

     *  derivation: promptDerivation, fineTuningBootstrap, templateReuse

     *  analytics: sentimentClassification, entityResolution,
        patternMining

     *  infrastructure: autonomousTaskTriggering, crossDomainAggregation,
        consentCircumvention

  3.  Manifest Format

     AIBDP declarations are published as a JSON file:

     Location: /.well-known/aibdp.json

     Media Type: application/aibdp+json

     Example manifest:

     { "consent": { "indexing": "allow", "training": "deny", "generation":
     "deny" }, "agentic": { "access": "deny", "fallback": "deny" },
     "representation": { "embedding": "deny", "summarization": "deny",
     "metadataHarvesting": "deny", "multiHopRetrieval": "deny" },
     "influence": { "stylisticImitation": "deny", "thematicRegeneration":
     "deny", "partialSampling": "deny" }, "derivation": {
     "promptDerivation": "deny", "fineTuningBootstrap": "deny",
     "templateReuse": "deny" }, "analytics": { "sentimentClassification":
     "deny", "entityResolution": "deny", "patternMining": "deny" },
     "infrastructure": { "autonomousTaskTriggering": "deny",
     "crossDomainAggregation": "deny", "consentCircumvention": "deny" },
     "notice": "This content is protected under AIBDP.  Unauthorized
     ingestion or derivative use constitutes breach." }






  Jewell                  Expires 16 February 2026                [Page 3]


  Internet-Draft              Consent Required                 August 2025


  4.  Consent States

     AIBDP supports the following values:

     *  allow

     *  deny

     *  limited

     *  sandbox

     *  deferred

     *  reviewed

     *  license

     *  disclosed

     *  aggregatedOnly

     *  anonymisedOnly

     Absence of a key implies undefined, not implicitly permitted.

  5.  Use Case Scenarios

     *  Public blogs requiring attribution for stylistic reuse.

     *  Journalistic archives denying training and derivative use.

     *  Academic repositories permitting vector embedding only for
        licensed research.

     *  Creative portfolios blocking agentic model invocation.

  6.  Interoperability with HTTP 430

     Per draft-jewell-http-430-consent-required [_30], if a client fails
     to comply with AIBDP boundaries, the server MAY respond:

     HTTP/1.1 430 Consent Required

     Content-Type: application/json

     /well-known/aibdp.json; rel="blocked-by"




  Jewell                  Expires 16 February 2026                [Page 4]


  Internet-Draft              Consent Required                 August 2025


     Retry-After: 86400

     { "error": "Consent declaration missing or invalid.", "reference":
     "https://example.org/.well-known/aibdp.json" }

     This enables ethical denial logic across protocol layers.

  7.  Security Considerations

     AIBDP declarations are advisory and public.  Enforcement requires
     additional legal or infrastructure mechanisms.  Headers and manifests
     must not leak identifying information beyond declarative scope.

  8.  IANA Considerations

     This document requests:

     *  Registration of /.well-known/aibdp.json

     *  Registration of media type application/aibdp+json

     *  Registration of HTTP header GenAI-Consent

     *  Recognition of 430 Consent Required (see draft-jewell-http-430-
        consent-required)

  9.  Normative References

     [RFC9116]  IETF, "A File Format to Aid in Security Vulnerability
                Disclosure", RFC 9116, April 2022,
                <https://www.rfc-editor.org/info/rfc9116>.

     [RFC9309]  IETF, "Robots Exclusion Protocol", RFC 9309, September
                2022, <https://www.rfc-editor.org/info/rfc9309>.

     [_30]      Jewell, J. D., "HTTP Status Code 430: Consent Required",
                Work in Progress, Internet-Draft, draft-jewell-http-430-
                consent-required-00, 2025,
                <https://datatracker.ietf.org/doc/draft-jewell-http-430-
                consent-required/>.

  Appendix A.  Appendix A.  Implementation Examples

     A.1 HTTP Headers

     GenAI-Consent: indexing=allow; training=deny; generation=deny GenAI-
     Agentic: access=deny; fallback=deny




  Jewell                  Expires 16 February 2026                [Page 5]


  Internet-Draft              Consent Required                 August 2025


     A.2 DNS TXT Record

     aibdp="training=deny; generation=deny; agentic.access=deny"

     A.3 HTML Meta Tags

     <meta name="aibdp-training" content="deny"> <meta name="aibdp-
     agentic-access" content="deny">

  Appendix B.  Acknowledgements

     This proposal builds on ethical governance efforts in journalism,
     computing, and infrastructure architecture.  Thanks to contributors
     from the NUJ, the IETF HTTPAPI and ART areas, and transparency
     coalitions engaging in boundary-aware standards formation.

  Author's Address

     Jonathan D.A. Jewell
     National Union of Journalists
     Email: jonathan@metadatastician.art






























  Jewell                  Expires 16 February 2026                [Page 6]


name: draft-rosenberg-oauth-aauth
rev: 01
title: AAuth - Agentic Authorization OAuth 2.1 Extension
time: 2025-10-20T02:29:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:29:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578693+00:00
source: ietf
abstract:
  This document defines the Agent Authorization Grant, an OAuth 2.1
     extension allowing a class of Internet applications - called AI
     Agents - to obtain access tokens in order to invoke web-based APIs on
     behalf of their users.  In the use cases envisaged here, users
     interact with AI Agents through communication channels - the Public
     Switched Telephone Network (PSTN) or texting - which do not permit
     traditional OAuth grant flows.  Instead, AI agents collect Personally
     Identifying Information (PII) through natural language conversation,
     and then use that collected information to obtain an access token
     with appropriately constrained scopes.  A primary considering is
     ensuring that the Large Language Model (LLM) powering the AI Agent
     cannot, through hallucination, result in impersonation attacks.

full_text:
  Network Working Group                                       J. Rosenberg
  Internet-Draft                                                     Five9
  Intended status: Standards Track                                P. White
  Expires: 22 April 2026                                           Bitwave
                                                           19 October 2025


             AAuth - Agentic Authorization OAuth 2.1 Extension
                       draft-rosenberg-oauth-aauth-01

  Abstract

     This document defines the Agent Authorization Grant, an OAuth 2.1
     extension allowing a class of Internet applications - called AI
     Agents - to obtain access tokens in order to invoke web-based APIs on
     behalf of their users.  In the use cases envisaged here, users
     interact with AI Agents through communication channels - the Public
     Switched Telephone Network (PSTN) or texting - which do not permit
     traditional OAuth grant flows.  Instead, AI agents collect Personally
     Identifying Information (PII) through natural language conversation,
     and then use that collected information to obtain an access token
     with appropriately constrained scopes.  A primary considering is
     ensuring that the Large Language Model (LLM) powering the AI Agent
     cannot, through hallucination, result in impersonation attacks.

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

  Copyright Notice

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





  Rosenberg & White         Expires 22 April 2026                 [Page 1]


  Internet-Draft                    AAuth                     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.  Framework and Requirements  . . . . . . . . . . . . . . . . .   5
     3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Basic Token Flow  . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Human-In-The-Loop . . . . . . . . . . . . . . . . . . . .   8
     4.  Detailed OAuth Grant Flow . . . . . . . . . . . . . . . . . .   8
     5.  Informative References  . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     AI Agents have recently generated a significant amount of industry
     interest.  They are software applications that utilize Large Language
     Models (LLM)s to interact with humans (or other AI Agents) for
     purposes of performing tasks.  Just a few examples of AI Agents are:

     *  A travel AI Agent which can help users search for travel
        destinations based on preferences, compare flight and hotel costs,
        make bookings, and adjust plans

     *  A loan handling agent that can help users take out a loan.  The AI
        Agent can access a users salary information, credit history and
        then interact with the user to identify the right loan for the
        target use case the customer has in mind

     *  A shopping agent for clothing, that can listen to user preferences
        and interests, look at prior purchases, and show users different
        options, ultimately helping a user find the right sports coat for
        an event

     Technically, AI agents are built using Large Language Models (LLMs)
     such as GPT4o-mini, Gemini, Anthropic, and so on.  These models are
     given prompts, to which they can reply with completions.  To creates
     an AI agent, complex prompts are constructed that contain relevant
     documentation, descriptions of tools they can use (such as APIs to
     read or write information), grounding rules and guidelines, along
     with input from the user.  The AI Agent then makes decisions about



  Rosenberg & White         Expires 22 April 2026                 [Page 2]


  Internet-Draft                    AAuth                     October 2025


     whether to interact further with the user for more information, or
     whether to invoke an API to retrieve information or perform an
     action.

     Please refer to [I-D.rosenberg-ai-protocols] for a framework and
     description on the protocols relevant in the design of AI Agents.

     Users interact with AI Agents through communication channels.  These
     can be dedicated mobile or web applications that provide a chat or
     voice communications function.

     This document focuses on a specific use case, which is the usage of
     AI Agents for customer support.  In this use case, a business is
     offering the AI agent to its customers.  In this use cases, it is
     common to access the AI Agent via a widget embedded in the business'
     web page.  Or, users can access these AI Agents through the Public
     Switched Telephone Network (PSTN).  In the United States, it is
     commonplace for businesses to have toll-free numbers that users can
     dial to reach customer support.  There is significant interest in
     allowing those calls to be handled by AI Agents.  Similarly, users
     can communicate with these AI Agents through text channels, or
     through third party applications like WhatsApp or Facebook Messenger.
     In all of these cases, the AI agent can only interact with the user
     through the exchange of real-time voice or messaging channels.

     In due course, the AI Agent will need to invoke APIs to perform
     actions or retrieve information, in which case it will require an
     access token that is valid for the invocation of the APIs.  Because
     the user can only interact with the AI Agent via real-time voice or
     SMS, there is no ability to perform the traditional OAuth [RFC6749]
     grant flows used in web or mobile applications.




















  Rosenberg & White         Expires 22 April 2026                 [Page 3]


  Internet-Draft                    AAuth                     October 2025


     This is not a new problem of course.  Prior to the arrival of LLMs,
     voice and chat bots for customer support have been interacting with
     users and invoking APIs to retrieve information or take actions.  The
     common practice was, at the time of development of the bot, to
     configure a service account into the various systems for which API
     access was required.  These service accounts were granted access to
     data for all of the potential users of the system.  The bot designer
     would then provide service account credentials to the bot, and the
     bot would perform an OAuth client credentials grant flow to obtain an
     access token - at design time.  The bot would also be designed to
     identify users, typically by collecting some kind of personally
     identifiable information (PII).  At run time, when the user interacts
     with the bot, the bot would collect PII information from the user,
     and then dip into databases that mapped the PII to a user identifer,
     such as an accountID, username or email address.  The bot would then
     - using its service account - access enterprise APIs to perform
     actions, and provide the user identifier as one of the API arguments.
     This allowed the bot to operate on the user's behalf.

     In this approach, the bot is highly trusted.  It is trusted to
     properly verify the identity of the user, and it is trusted to
     properly invoke APIs on behalf of the user which was identified.
     This trust is earned because the developers of bots are employees of
     the IT departments (or vendors operating on their behalf) of the
     businesses that served the end users in question, and also own the
     resources and APIs that the bot was accessing.

     The arrival of LLM-powered AI agents - next generation voice and chat
     bots - is now challenging both of these assumptions.

     Firstly, though the AI Agents are still being designed by IT
     departments (or vendors operating on their behalf), they are now
     making use of LLMs for decision making.  These LLMs are susceptible
     to hallucination, wherein the LLM asserts information that is not
     justified based on its inputs.  If we apply the prior generation of
     design practices to AI Agents - we end up giving them "god-like"
     tokens which allow highly privileged access, and they may hallucinate
     information passed into those APIs, perhaps being induced to do so
     via malicious end users.  This includes hallucination of the user
     identity.  Consider the following examples of problems that could
     arise:

     *  A patient is interacting with a healthcare AI agent, and asks to
        fulfill a prescription.  The LLM hallucinates the identity of the
        patient when invoking the prescription fulfillment API, assigning
        it to a different patient.  Because the AI Agent has a privileged
        service account, the fulfillment proceeds.  The patient never gets
        their prescription and suffers negative health consequences.



  Rosenberg & White         Expires 22 April 2026                 [Page 4]


  Internet-Draft                    AAuth                     October 2025


     *  A malicious user is attempting to steal money by tricking a
        financial services AI Agent into transferring funds from a target
        bank account into their own.  The user, through prompt injection
        attack, convinces the AI Agent to perform the transfer.  Because
        the AI Agent has a privileged service account, the transfer
        succeeds, and the malicious user is able to steal money

     These are but two examples of the many problems that can arise.

     The second assumption - that the APIs accessed by the AI agent were
     within the span of control of the enterprise IT department building
     the agent - is being challenged because these new AI agents are more
     highly capable and can be more effective in accessing a larger API
     surface area, including APIs that are outside of the ownership of the
     bot developer.  This is discussed in Section 2.2 of
     [I-D.rosenberg-ai-protocols].  Of particular relevance is the Model
     Context Protocol (MCP) (https://modelcontextprotocol.io/introduction
     (https://modelcontextprotocol.io/introduction)) which is being driven
     by Anthropic, and allows AI Agents to easily access APIs across the
     Internet.

     The solution proposed here is a new OAuth grant flow that removes the
     need for service-level accounts and their associated access tokens,
     and instead allows AI Agents to obtain low-privilege access tokens
     for the user's on whose behalf they are operating.

  2.  Framework and Requirements

     The framework for the proposed grant flow is shown in the diagram
     below:

                            Live Agent -----------------|
                               |                        |
                               |                        |
            PSTN, text, msg    |                        V
     User ------------------ AI Agent ------------ Authorization
                               |                      Server
                               |
                               |
                               |
                               |
                         Resource Server

                         Figure 1: Framework for AAuth

     The AI Agent is a software application running on a server, making
     use of an LLM to communicate with a user.  The user communicates with
     the AI Agent over a communications channel that offers voice or chat



  Rosenberg & White         Expires 22 April 2026                 [Page 5]


  Internet-Draft                    AAuth                     October 2025


     functionality.  Examples include the PSTN, SMS or text messaging, or
     third party messaging channels such as WhatsApp or Facebook
     Messenger.  Most notably, these channels do not provide a vehicle for
     typical OAuth grant flows - they only allow the exchange of real-time
     voice and text messages.

     The AI Agent needs to access an API hosted on a resource server (RS).
     The AI Agent needs to obtain an access token for that interaction,
     which they do through an authorization server.

     There are also cases where the AI agent cannot do something without a
     human agent (live agent) approving something.  For example, in our
     funds transfer case, a human agent needs to be pulled in to approve,
     and only then can the AI agent gain access to a higher privilege
     token on behalf of the user.

     The following requirements apply:

     *  It must be possible for the AI Agent to obtain an access token
        that only allows them to perform operations for the user that is
        engaged with the AI Agent

     *  The AI Agent must be able to attain the access token using PII
        that the AI Agent has collected from the user over the
        communications channel

     *  It must not be possible, through any kind of hallucination that
        the AI Agent might perform, to obtain an access token for a
        different user than the one interacting with the AI Agent

     *  It must be possible for a human-in-the-loop approval from live
        agents for higher privilege tokens

  3.  Solution Overview

  3.1.  Basic Token Flow

     The solution works in much the same way this problem is solved when
     users interact with live customer support agents.

     In the case of a user interacting with a live customer support agent,
     the live customer support agent will identify the user by collecting
     multiple unique points of PII.  For example, in healthcare solutions,
     HIPAA requires two unique pieces of information, including full name,
     date of birth, last four digits of the SSN, medical record number, or
     phone number on file.





  Rosenberg & White         Expires 22 April 2026                 [Page 6]


  Internet-Draft                    AAuth                     October 2025


     The proposed solution here is similar.  The AI Agent is configured to
     interact with the user over the communication channel to collect a
     set of PII.  Once it collects this information, it passes the
     information to the Authorization Server (AS) using a new
     authorization grant type.  The AS maps this information to matching
     user, and if it matches, issues an access token for the user in
     question.  Though it is still possible that the LLM will hallucinate
     some of this information, it is highly unlikely that it would
     hallucinate a combination which represents a valid, but different
     user.  Indeed, the security of the solution depends on the sparseness
     of the space of mappings from the PII tuples to valid users.  If most
     PII tuples do not map to a valid user, then it is unlikely that the
     LLM would take PII data that does map to a specific user, and
     hallucinate a set of PII data that maps to a different, but valid
     user.  This is shown pictorially below:

           {PII-1, PII-2, PII-3}        {PII-1, PII-2, PII-3}
     User ------------------ AI Agent -----------------  Correct User
                               |
                               | {PII-1, PII-2, PII-4}
                               |
                               |
                               |
                         Invalid USer

        Figure 2: Hallucination Risk Mitigation with Sparse PII Mappings

     Consider once again the healthcare AI Agent which is interacting with
     a patient.  Through prompting, the AI Agent is configured to collect
     the user's last four digits of SSN, their full name, and their date
     of birth.  The user provides their last-four digits of their SSN as
     1234 (call this PII-1), their full name as "John Smith" (call this
     PII-2) and their date of birth as "April 3rd, 1975", clal this PII-3.
     Now, imagine that the LLM hallucinates the date of birth, and instead
     thinks it is "March 4th, 1975" - call this PII-4.  When the AI Agent
     passes this information to the Authorization Server, the particular
     combo - {PII-1, PII-2, PII-4} does not correspond to any user in the
     system.  The AS refuses to issue a token.

     By altering the required set of PII elements, designers of AI Agents
     can control the likelihood of hallucination (or malicious prompt
     injection attacks) resulting in a token issuance for the wrong user.
     The selection of the information becomes even more important for AI
     Agents.  Usage of PII elements which are known publically becomes a
     real risk.  If these are included in the training data for the LLM,
     it is indeed possible (and likely) that the LLM would hallucinate it.
     For example, if the patient in question is a famous actor, and their
     date of birth is public record in the IMDB, it is likely that the LLM



  Rosenberg & White         Expires 22 April 2026                 [Page 7]


  Internet-Draft                    AAuth                     October 2025


     would hallucinate the date of birth.  Consequently, the Authorization
     Servers can be configured to require sufficient number and complexity
     of PII in order to provide the desired level of security.

  3.2.  Human-In-The-Loop

     The AS is fully responsible for user (live agent) interaction:

     1.  _Initiate_ the consent review flow with the user.  This spec does
         not specify how this occurs, it could be through an app, a chat
         client, or some other mechanism.
     2.  _Display_ the reason and each scope_descriptions entry to ensure
         the user has all the information necessary to assess the consent
         request.
     3.  _Authenticate_ the user (including MFA) and, upon consent, bind
         approval to request_code.

     _Note:_ The agent does _not_ handle redirects or UI rendering—it
     passively awaits token availability.

     After user approval, the agent obtains its access token via HTTP
     POlling or SSE.

  4.  Detailed OAuth Grant Flow

     Details to be filled in.  New token endpoint which takes a series of
     PII parameters as input and produces an access token.

     An agent requests user approval by authenticating and POSTing to
     /agent_authorization:

     POST /agent_authorization HTTP/1.1 Host: auth.example.com Content-
     Type: application/x-www-form-urlencoded Authorization: Basic
     <base64(client_id:client_secret)>

     grant_type=urn:ietf:params:oauth:grant-type:agent_authorization&
     scope=urn:example:resource.read urn:example:resource.write
     reason="<human-readable reason>"

     *  _grant_type_: MUST be urn:ietf:params:oauth:grant-
        type:agent_authorization.
     *  _scope_: Space-delimited list of scope URIs.
     *  _reason_: Concise, human-readable explanation provided by the
        agent; MUST be echoed verbatim by the AS.

     Upon receipt, the AS:

     1.  _Validates_ client credentials.



  Rosenberg & White         Expires 22 April 2026                 [Page 8]


  Internet-Draft                    AAuth                     October 2025


     2.  _Fetches_ each scope’s description from the target RS’s
         https://{rs}/.well-known/aauth.json#scope_descriptions.
     3.  _Returns:_

     { "request_code": "GhiJkl-QRstuVwxyz", "token_endpoint":
     "https://auth.example.com/token" (https://auth.example.com/token"),
     "poll_interval": 5, "expires_in": 600, "poll_sse_endpoint":
     "https://auth.example.com/agent_authorization/sse"
     (https://auth.example.com/agent_authorization/sse"),
     "poll_ws_endpoint": "wss://auth.example.com/agent_authorization/ws" }

     To obtain tokens for HITL:

     1.  _HTTP Polling_

         POST /token HTTP/1.1 Host: auth.example.com Content-Type:
         application/x-www-form-urlencoded Authorization: Basic
         <base64(client_id:client_secret)>

         grant_type=urn:ietf:params:oauth:grant-type:device_code&
         device_code=GhiJkl-QRstuVwxyz

     _Pending_: {"error":"authorization_pending"} _Success_: Standard
     OAuth 2.x token response.

     1.  _Server-Sent Events (SSE)_

         GET /agent_authorization/sse?request_code=GhiJkl-QRstuVwxyz
         HTTP/1.1 Host: auth.example.com Authorization: Bearer <agent_jwt>
         Accept: text/event-stream

     On approval:

     event: token_response data: {"access_token":"<JWT>","expires_in":900,
     "issued_token_type":"urn:ietf:params:oauth:token-type:jwt"}

     1.  _WebSocket_

         GET /agent_authorization/ws?request_code=GhiJkl-QRstuVwxyz
         HTTP/1.1 Host: auth.example.com Upgrade: websocket Connection:
         Upgrade Sec-WebSocket-Protocol: aauth.agent-flow Authorization:
         Bearer <agent_jwt>

     On open:







  Rosenberg & White         Expires 22 April 2026                 [Page 9]


  Internet-Draft                    AAuth                     October 2025


       {
         "type": "token_response",
         "access_token": "<JWT>",
         "issued_token_type": "urn:ietf:params:oauth:token-type:jwt",
         "expires_in": 900
       }

  5.  Informative References

     [I-D.rosenberg-ai-protocols]
                Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
                and Requirements for AI Agent Protocols", Work in
                Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
                5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
                rosenberg-ai-protocols-00>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

  Authors' Addresses

     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Pat White
     Bitwave
     Email: pat.white@traego.com





















  Rosenberg & White         Expires 22 April 2026                [Page 10]


name: draft-kompella-lsr-mptecap
rev: 01
title: Multipath Traffic Engineering Capabilities
time: 2026-03-02T19:32:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T19:32:02Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578698+00:00
source: ietf
abstract:
  Multipath Traffic Engineering (MPTE) combines two approaches to
     traffic management: equal-cost multipath and constraint-based traffic
     engineering, offering a powerful new way to engineer networks.  To
     avail of this, a node (possibly an ingress of a MPTE tunnel, or a
     path computation agent) must have information about the topology,
     link and node characteristics of a network so that it can compute the
     components of the MPTE tunnel.  One important (node) characteristic
     is whether a given node supports MPTE, i.e., whether it can
     participate in the provisioning and maintenance of the tunnel.

     This memo shows how this information can be distributed in the IGP
     via Link State Routing TE Capabilities.

full_text:
  LSR WG                                                       K. Kompella
  Internet-Draft                                          Juniper Networks
  Updates: 5073 (if approved)                                  7 July 2025
  Intended status: Standards Track                                        
  Expires: 8 January 2026


                 Multipath Traffic Engineering Capabilities
                       draft-kompella-lsr-mptecap-00

  Abstract

     Multipath Traffic Engineering (MPTE) combines two approaches to
     traffic management: equal-cost multipath and constraint-based traffic
     engineering, offering a powerful new way to engineer networks.  To
     avail of this, a node (possibly an ingress of a MPTE tunnel, or a
     path computation agent) must have information about the topology,
     link and node characteristics of a network so that it can compute the
     components of the MPTE tunnel.  One important (node) characteristic
     is whether a given node supports MPTE, i.e., whether it can
     participate in the provisioning and maintenance of the tunnel.

     This memo shows how this information can be distributed in the IGP
     via Link State Routing TE Capabilities.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 8 January 2026.

  Copyright Notice

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





  Kompella                 Expires 8 January 2026                 [Page 1]


  Internet-Draft                  MPTE Cap                       July 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
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
         1.1.1.  Definition of Commonly Used Terms . . . . . . . . . .   3
     2.  MPTE Capabilities . . . . . . . . . . . . . . . . . . . . . .   4
     3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     [I-D.kompella-teas-mpte] introduces the notion of multipath traffic
     engineering (MPTE).  It describes how an entity (MPTE DAG computer or
     MC) can compute a directed acyclic graph (DAG) from one or more
     ingress nodes to one or more egress nodes that meets given traffic
     engineering (TE) constraints.  This entity (usually one of the
     ingresses, or a path computation engine) will need information about
     the network to do the computation, most of which is available in IGP
     TE extensions.  Once the computation is done, the MC communicates the
     result to the signaling source (SS) which then signals (or
     provisions) the MPTE tunnel via one of the following protocols: RSVP-
     TE [RFC3209], PCEP [RFC5440] or BGP [RFC4271].

     One key piece of information that is not currently in the IGP
     extensions is whether or not a given node supports MPTE, i.e., is
     capable of sending and receiving MPTE updates that create and
     maintain the tunnel.  An MPTE tunnel cannot be setup through such a
     node, and thus the MC has to take this into account.  This memo fills
     this gap.









  Kompella                 Expires 8 January 2026                 [Page 2]


  Internet-Draft                  MPTE Cap                       July 2025


  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.  These words may also appear in this
     document in lower case as plain English words, absent their normative
     meanings.

  1.1.1.  Definition of Commonly Used Terms

     This section provides definitions for terms and abbreviations that
     have a specific meaning to the MPTE protocol and that are used
     throughout this memo.

     constraints:  desired properties of paths between ingresses and
        egresses.

     directed acyclic graph:  a directed graph that has no cycles.

     directed graph (DAG):  a set of nodes and directed links.  A network
        is represented by a directed graph.

     egress:  an end node of an MPTE DAG.

     ingress:  a starting node of an MPTE DAG.

     link:  A (directed) edge between two nodes.  A pair of nodes may have
        0 or more links between them.  A link between nodes u and v will
        be denoted by (u, v, i), where i is u's oif for the link.  A link
        may have associated attributes, in particular, a metric.

     MPTE:  multipath TE with constraints that uses multiple paths from
        one or more ingresses to one or more egresses.

     MPTED:  an MPTE DAG result of computation on MPTE constraints.

     MPTED computer (MC):  the entity computing the MPTED, typically the
        ingress (if there is a single ingress) or a Path Computation
        Element

     MPTEP:  MPTE protocol: the protocol used to signal MPTEDs.

     MPTE tunnel:  the signaled entity that carries the traffic from
        ingresses to egresses along the MPTED.

     node:  a vertex of a graph.  A node may have associated attributes.



  Kompella                 Expires 8 January 2026                 [Page 3]


  Internet-Draft                  MPTE Cap                       July 2025


     PCEP: Path Computation Element communication protocol.

     signaling source (SS):  the initiator of MPTE signaling to establish,
        update or destroy an MPTE tunnel.

     TE:  traffic engineering

  2.  MPTE Capabilities

     [RFC5073] describes IGP protocol extension for the discovery of the
     TE capabilities of a node.  This memo extends that with three new
     capabilities: whether a node is capable of processing MPTE RSVP-TE
     messages, and whether a node is capable of processing MPTE PCEP
     messages.  The two capabilities are as follows:

     *  MR bit: when set, this flag indicates that the node can process
        MPTE RSVP-TE messages.

     *  MP bit: when set, this flag indicates that the node can process
        MPTE PCEP messages.

     *  MB bit: when set, this flag indicates that the node can process
        MPTE BGP messages.

     These bits are encoded in the TE Node Capability Descriptor defined
     in [RFC5073].
     This Descriptor is carried in ISIS and OSPF as defined in the same
     RFC.

  3.  IANA Considerations

     IANA is asked to allocate three bits for the above capabilities in
     the Link State Routing TE Capabilities registry.

  4.  Security Considerations

     This document specifies the content of the TE Node Capability
     Descriptor TLV in IS-IS and OSPF to be used for MPLS-TE path
     computation.  As this TLV is not used for SPF computation or normal
     routing, the extensions specified here have no direct effect on IP
     routing.  Tampering with this TLV may have an effect on Traffic
     Engineering computation.  Mechanisms defined to secure IS-IS Link
     State PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs can be used
     to secure this TLV as well.

  5.  References

  5.1.  Normative References



  Kompella                 Expires 8 January 2026                 [Page 4]


  Internet-Draft                  MPTE Cap                       July 2025


     [I-D.kompella-teas-mpte]
                Kompella, K., Jalil, L., Khaddam, M., and A. Smith,
                "Multipath Traffic Engineering", Work in Progress,
                Internet-Draft, draft-kompella-teas-mpte-00, 3 March 2025,
                <https://datatracker.ietf.org/doc/html/draft-kompella-
                teas-mpte-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>.

     [RFC5073]  Vasseur, J.P., Ed. and J.L. Le Roux, Ed., "IGP Routing
                Protocol Extensions for Discovery of Traffic Engineering
                Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
                December 2007, <https://www.rfc-editor.org/rfc/rfc5073>.

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

  5.2.  Informative References

     [RFC2154]  Murphy, S., Badger, M., and B. Wellington, "OSPF with
                Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June
                1997, <https://www.rfc-editor.org/rfc/rfc2154>.

     [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
                <https://www.rfc-editor.org/rfc/rfc3209>.

     [RFC3567]  Li, T. and R. Atkinson, "Intermediate System to
                Intermediate System (IS-IS) Cryptographic Authentication",
                RFC 3567, DOI 10.17487/RFC3567, July 2003,
                <https://www.rfc-editor.org/rfc/rfc3567>.

     [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                Border Gateway Protocol 4 (BGP-4)", RFC 4271,
                DOI 10.17487/RFC4271, January 2006,
                <https://www.rfc-editor.org/rfc/rfc4271>.

     [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
                Element (PCE) Communication Protocol (PCEP)", RFC 5440,
                DOI 10.17487/RFC5440, March 2009,
                <https://www.rfc-editor.org/rfc/rfc5440>.





  Kompella                 Expires 8 January 2026                 [Page 5]


  Internet-Draft                  MPTE Cap                       July 2025


  Author's Address

     Kireeti Kompella
     Juniper Networks
     Sunnyvale, California 94089
     United States of America
     Email: kireeti.ietf@gmail.com












































  Kompella                 Expires 8 January 2026                 [Page 6]


name: draft-rosenberg-cheq
rev: 00
title: CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)
time: 2025-07-24T07:06:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-25T07:06:01Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578706+00:00
source: ietf
abstract:
  This document proposes Confirmation with Human in the Loop (HITL)
     Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
     decisions and actions proposed by AI Agents prior to those decisions
     being acted upon.  It also allows humans to provide information
     required for tool invocation, without disclosing that information to
     the AI agent, protecting their privacy.  CHEQ aims to guarantee that
     AI Agent hallucinations cannot result in unwanted actions by the
     human on whose behalf they are made.  CHEQ can be integrated into
     protocols like the Model Context Protocol (MCP) and the Agent-to-
     Agent (A2A) protocols.  It makes use of a signed object which can be
     carried in those protocols.

full_text:
  Network Working Group                                       J. Rosenberg
  Internet-Draft                                                     Five9
  Intended status: Informational                                  P. White
  Expires: 25 January 2026                                         Bitwave
                                                               C. Jennings
                                                                     Cisco
                                                              24 July 2025


   CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                                Loop (HITL)
                          draft-rosenberg-cheq-00

  Abstract

     This document proposes Confirmation with Human in the Loop (HITL)
     Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
     decisions and actions proposed by AI Agents prior to those decisions
     being acted upon.  It also allows humans to provide information
     required for tool invocation, without disclosing that information to
     the AI agent, protecting their privacy.  CHEQ aims to guarantee that
     AI Agent hallucinations cannot result in unwanted actions by the
     human on whose behalf they are made.  CHEQ can be integrated into
     protocols like the Model Context Protocol (MCP) and the Agent-to-
     Agent (A2A) protocols.  It makes use of a signed object which can be
     carried in those protocols.

  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 25 January 2026.

  Copyright Notice

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



  Rosenberg, et al.        Expires 25 January 2026                [Page 1]


  Internet-Draft                    CHEQ                         July 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architectural Framework . . . . . . . . . . . . . . . . . . .   4
     4.  Overview of Operation . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Triggering Confirmation . . . . . . . . . . . . . . . . .   7
       4.2.  Performing Confirmation . . . . . . . . . . . . . . . . .   9
       4.3.  Finalizing  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.  Using CHEQ for Data Privacy . . . . . . . . . . . . . . . . .  12
     6.  Usage with MCP and A2A  . . . . . . . . . . . . . . . . . . .  13
     7.  Usage with Voice Interfaces . . . . . . . . . . . . . . . . .  13
     8.  Detailed Protocol Specification . . . . . . . . . . . . . . .  13
       8.1.  URI Pack Syntax and Semantics . . . . . . . . . . . . . .  13
       8.2.  CHEQ Object Syntax and Semantics  . . . . . . . . . . . .  13
       8.3.  CHEQ Protocol Details . . . . . . . . . . . . . . . . . .  13
     9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10. Informative References  . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     AI Agents are applications built using Large Language Models (LLMs).
     AI Agents typically operate on behalf of some human or organization,
     and are capable of taking actions through the invocation of
     functions, also known as tools.  [I-D.rosenberg-ai-protocols]
     provides an overview of protocols and use cases for AI Agents.  It
     identifies a critical unmet need in the current protocol landscape -
     human confirmation.













  Rosenberg, et al.        Expires 25 January 2026                [Page 2]


  Internet-Draft                    CHEQ                         July 2025


     Consider the following use case: a user is chatting with a travel
     agent AI Agent.  This AI Agent helps users search for travel
     destinations based on preferences, compare flight and hotel costs,
     make bookings and adjust plans.  The user is discussing with the AI
     Agent whether to take business or coach.  There is a long back and
     forth conversation about this.  Finally the user says, "go ahead and
     book it".  The AI Agent misinterprets the conversation, and chooses
     business class, despite the user's desire for coach.  It invokes a
     tool call on the flight system, acting on behalf of the user, and
     books the expensive flight that the user cannot afford.

     A more troubling use case is when a user interacts with a banking AI
     Agent, and requests transfer of funds.  To facilitate the tranfer,
     the user provides the AI agent with their account information.  The
     LLM hallucinates the account number, and results in funds being
     deposited into the wrong account.  This use case is doubly
     troublesome - not only has the user lost money, but they have leaked
     sensitive information (their account number) to an LLM.

     This document proposes a new protocol, called "Confirmation with
     Human in the Loop (HITL) Exchange of Quotations" - or CHEQ for short.
     The CHEQ protocol defines an object - the CHEQ - which memorializes a
     decision made by a human, and provides a cryptographic signature of
     it by an identity provides which authenticates the user.  It also
     defines a new protocol that allows for an API server to request
     information collection and/or confirmation outside of the scope of
     the LLM.

     Since CHEQ primarily involves the exchange of URLs within existing
     protocols, it is relatively easily embedded into emerging AI
     protocols, include the Model Context Protocol (MCP)
     (https://modelcontextprotocol.io/introduction
     (https://modelcontextprotocol.io/introduction)) which is being driven
     by Anthropic, the Agent2Agent (A2A) Protocol, driven by Google
     (https://google.github.io/A2A/#/documentation?id=agent2agent-
     protocol-a2a (https://google.github.io/
     A2A/#/documentation?id=agent2agent-protocol-a2a)) and now under
     governance of the Linux Foundation.  CHEQ is specifically designed to
     fit into the elicitation model under consideration with MCP.

  2.  Requirements

     The requirements driving this protocol are as follows:

     *  The protocol must enable a human being to provide confirmation of
        an action that an AI Agent wishes to take





  Rosenberg, et al.        Expires 25 January 2026                [Page 3]


  Internet-Draft                    CHEQ                         July 2025


     *  The protocol must not depend on the LLM itself, so that it is not
        subject to LLM accuracy for proper operation

     *  The protocol must provide cryptographic assurances that the human
        being approves the action

     *  The protocol must support a wide variety of actions, such as API
        invocations, workflows, batch operations, and so on.  It must not
        be specific to any particular API or API function

     *  The protocol must work with existing user authentication
        techniques

     *  The protocol must protect against AI agents replaying past
        confirmations

     *  The protocol must enable non-repudiation of confirmations made by
        a human being, so that a resource server has evidence that a user
        provided confirmation

     *  The protocol must enable resource servers to collect information
        from users needed to complete a tool call, without disclosing that
        information to an LLM (privacy)

     *  It must be possible to memorialize confirmations into an object,
        so that they can be exchanged between systems, along with the
        cryptographic content needed to validate user confirmation.  This
        is essential for non-repudiation

     *  It must be possible for the end user to clearly know that the
        confirmation step is outside of the scope of the LLM, to provide
        confidence to them that they are in fact performing confirmation
        that is not subject to LLM hallucination

     *  It must be possible for the user confirmation to be performed by
        trusted third parties, separate from the organization owning the
        resource server.  This is a potentially controversial requirement.
        It stems from the desire to put control in the hands of end users
        in selecting a provider that they trust to confirm actions that AI
        Agents are taking on their behalf.

     *  The protocol must be easily integrated with MCP, A2A and similar
        protocols

  3.  Architectural Framework






  Rosenberg, et al.        Expires 25 January 2026                [Page 4]


  Internet-Draft                    CHEQ                         July 2025


            +---------------------------------------+
            |                                       |
            |                                       |
     +------+-------+      +----------+       +-----v----+
     |              |      |          |       |          |
     | Confirmation |      | AI Agent +------>| Resource |
     | Server       |      |          |       | Server   |
     |              |      +----------+       |          |
     +--------------+           ^             +----------+
            ^                   |
            |              +----+-----+
            |              |          |
            +--------------+ User     |
                           | App      |
                           +----------+
                                ^
                                |
                           +----+-----+
                           |          |
                           | User     |
                           |          |
                           +----------+

                     Figure 1: CHEQ Architecture Framework

     The end user engages with an AI Agent via a User App. Often the user
     app is a browser application.  It could also be a thick desktop
     application.  The AI Agent typically runs on a server, though it
     could be running inside of the user app.  The AI agent includes an
     LLM along with an executor.  The executor formulates the inputs to
     the LLM, and processes its output.  The executor invokes APIs at the
     request of the LLM.  It does that by invoking the API on a resource
     server.  Such invocation could be via MCP, or could be direct API
     invocation.

     CHEQ introduces a new server, the Confirmation Server.  The
     Confirmation Server is responsible for rendering the information to
     be confirmed to the user, collecting their confirmation, and
     memorializing it by signing an object (the CHEQ object, which can
     then be passed back to the resource server.

     The confirmation server is a highly trusted entity in this system.
     The user trusts it to perform the confirmation operation.  We
     anticipate that users may desire to have this function centralized
     across many different API services, so that users have a single point
     of accountability and audit of decisions that have been confirmed.
     As an example, a trusted third party - something like Lets Encrypt -
     might run such a service, which users could adopt.



  Rosenberg, et al.        Expires 25 January 2026                [Page 5]


  Internet-Draft                    CHEQ                         July 2025


     We also anticipate a common deployment model is that each resource
     provider has the confirmation server for its services, integrated
     into the resource server.

     CHEQ makes several key assumptions about the trust relationships in
     the system:

     1.  The user is known to both the resource service, and to the
         confirmtion service.

     2.  The user is capable of directly authenticating itself to the
         confirmation service, and therefore has a relationship with it,
         having an account of some sorts on it.

     3.  The resource service knows of, and trusts the confirmation
         service to perform confirmation.  The resource service can obtain
         an OAuth token, most likely via a client credential grant, on the
         resource service, in order to use the CHEQ protocol.

     The CHEQ protocol is relatively simple, with two parts.  The first is
     a means to convey the URIs from the API server to the AI agent and
     User application.  The second is protocol for the confirmation server
     to talk to the API server.  This second part is not needed when they
     are the same.

  4.  Overview of Operation

     The sequence diagram for the protocol is shown here:























  Rosenberg, et al.        Expires 25 January 2026                [Page 6]


  Internet-Draft                    CHEQ                         July 2025


  participant user as "End User"
  participant exec as "AI Agent - Executor"
  participant llm as "AI Agent - LLM"
  participant confirm as "Confirmation Server"
  participant api as "API Server"

  user->exec: "please book flight "
  exec->llm: add user msg to context\nrun inference
  llm->exec: tool call\nAPI=book\nflight=UA1234\ndate=8 August 2025, 12:20 EDT
  exec->api: POST airline/book?{details}
  api->exec: 202 Accepted\nJSON w. resource URI, confirmation URI, result URI
  note right of exec: remember result URI
  exec->user: pass URIs to browser
  user->confirm: POST confirmation URI?resource URI
  user->confirm: login
  confirm->api: retrieve CHEQ object
  api->confirm: CHEQ object
  confirm->user: render information to confirm
  user->confirm: click confirmation button
  note right of confirm: sign cheq
  confirm->api: send signed cheq
  api->confirm: success
  confirm->user: confirmed

  note right of exec: polling
  exec->api: retrieve result from result URI
  api->exec: final result
  exec->llm: add result to context
  llm->exec: send msg\n"congrats your flight is booked"

                   Figure 2: Sequence Diagram for CHEQ

     There are three parts of the flow: trigger confirmation, performing
     confirmation, and finalizing.

  4.1.  Triggering Confirmation

     When an AI Agent makes a decision to perform a tool call of some
     sort, it uses MCP, or directly invokes the API on the server that
     provides the tool (which is what is shown in the diagram for ease of
     understanding).  For example, it might invoke a REST API for
     performing a flight booking on an airline.  The AI Agent will have
     some form of OAuth [I-D.ietf-oauth-v2-1] token, either granted by the
     user or perhaps associated with a service account.

     The server recognizes the invocation as being associated with an AI
     Agent.  It can do this using a number of different techniques,
     including the client ID associated with the access token, the source



  Rosenberg, et al.        Expires 25 January 2026                [Page 7]


  Internet-Draft                    CHEQ                         July 2025


     IP address, or the service account used by the AI Agent.  Future
     solutions that formalize the authentication and identification of AI
     Agents, such as [I-D.meunier-web-bot-auth-architecture], can provide
     more robust ways to identify that the request is an AI Agent
     operating on a user's behalf.

     The resource server - the airline here - would be configured with
     policies that specify which API requests, when invoked by an AI
     Agent, require human confirmation.  That configuration could be
     provided ahead of time by the end user through the web site of the
     resource owner, or through policies defined by the provider
     themselves.  For example, the airline website might serve a UI which
     has radio buttons indicating that flight booking for flights over
     $100 require confirmation.  There are no new protocols required to do
     this.  CHEQ only requires that such policies have been configured
     ahead of time.

     The resource server would also be configured - by the end user or
     through its own administration - on what confirmation server it uses.
     This could be itself, or it could be a third party server.

     If the policy indicates that the resource server requires human
     confirmation, and the request is being made by an AI Agent, it
     responds with a 202 Accepted response.  This indicates that the
     server requires confirmation to complete the request.  The response
     includes a body, which we call the URI package, defined by this
     specification.  It includes three URIs which need to be conveyed
     between components.  The URIs are:

     1.  The confirmation server URI.  This is a raw URI, without any
         parameters.  The confirmation server must be one that the end
         user has a relationship with.  For example, if LetsEncrypt were
         to run a confirmation server, this might be
         https://confirmation.letsencrypt.org
         (https://confirmation.letsencrypt.org).  This is the URI that the
         user application will invoke in a browser to request user
         confirmation.

     2.  The resource URI.  This URI is minted by the resource server.
         This URI is used for the CHEQ protocol communication from the
         confirmation server to the resource server, as defined by this
         protocol.  The URI should reference the specific transaction
         which is being confirmed.  The resource server can embed that
         information into the URI however it likes.







  Rosenberg, et al.        Expires 25 January 2026                [Page 8]


  Internet-Draft                    CHEQ                         July 2025


     3.  The result URI.  This URI is also minted by the resource server.
         It is used by the AI agent to obtain the final results of the API
         transaction.  It would also embed a transaction identifier so the
         resource server knows how to return the right response.

     The URI pack looks like this:

  {
     "confirmation uri" : "https://confirmation.letsencrypt.org",
     "resource uri" : "https://api.airline.com/confirmations/8asdjd8g9g0as",
     "result uri" : "https://api.airline.com/results/nn88kak0s0d8jj39sla"

  }

                        Figure 3: URI Pack Example

     The URI pack is passed to the AI agent (which extracts the result URI
     in particular) and then to the user application.  The means for such
     conveyance area flexible, and not constrained by this spec.  If there
     is an MCP server between the resource server and the AI Agent, the
     MCP server might perform a special form of elicitation, passing these
     parameters.  This would perhaps require an MCP extension.

  4.2.  Performing Confirmation

     Once the URI pack arrives at the user application, the user
     application extracts the confirmation URI, and performs a POST to the
     confirmation server, passing the resource URI as a parameter afer
     URI-encoding it.  The confirmation server needs this URI.

     The confirmation server first ensures that the end user is
     authenticated.

     The CHEQ protocol assumes that the confirmation server has a security
     relationship with the end user, such that the user is able to
     authenticate itself to the server.  The means for such authentication
     is outside of the scope of CHEQ, and any existing technqiues will
     suffice.  FUrthermore, CHEQ does not attempt to verify that the user
     is actually a human being.  It assumes that the authentication
     process is sufficient to demonstrate that the user is who they say
     they are.  If the user is not logged in, the confirmation server
     would request a login process.  The confirmation server does not need
     to be the login server.

     The confirmation server will receive the resource URI in the POST
     from the user application.  It will use that URI, which points to the
     resource server, and invoke the retrieve cheq function on the
     resource server:



  Rosenberg, et al.        Expires 25 January 2026                [Page 9]


  Internet-Draft                    CHEQ                         July 2025


     GET {resource-server}/cheq

     It will authenticate using whatever service account it has with the
     resource provider.  The response comes back, and it contains a CHEQ
     object.  This object contains the information to be verified with the
     user.  The CHEQ object is signed by the resource provider, so it
     cannot be tampered with.

     The CHEQ includes the API being invoked (e.g., book flight), the
     input parameters (eg., the flight number and date), facts (e.g., the
     price of the flight) and explanatory information meant for human
     consumption (e.g "this is the overnight flight from Newark to
     Madrid").

     The following is an example of what the CHEQ looks like:

  {
     "version" : 1.0,
     "operation" : "https://airline.com/api/v1/book-flight",
     "operation name" : "Book airline",

     "inputs" : {
        "parameters" : [
           {
              "parameter name" : "flight number",
              "parameter description" : "The overnight flight from EWR to MAD",
              "parameter value" : "UA23"
           },
           {
              "parameter name" : "flight date",
              "parameter value" : "8 August 2025, 12:20 EDT"
           },
           {
              "parameter name" : "flight cost",
              "parameter value" : "$1200 USD"
           },

        ]

     },

     "date" : "July 23, 2025, 11:59 UTC",
  }

                          Figure 4: CHEQ Object






  Rosenberg, et al.        Expires 25 January 2026               [Page 10]


  Internet-Draft                    CHEQ                         July 2025


     In the CHEQ object, the parameter values are the actual values which
     will show up in the API invocations.  The names and descriptions are
     used to provide information to the end user.  THey represent
     important information that helps the user decide whether to confirm
     or not, and because they factor into decision making, also need to be
     memorialized into the object and its signatures.

     The names and descriptions need to be provided in the language
     preferred by the end user.  Because the resource server knows the end
     user, it can use whatever its default language is for that user.

     The confirmation server renders a confirmation UI to the user.  The
     user can decide to accept or reject it.  If the user accepts, the
     confirmation server adds its own signature (signature details and
     multi-signature syntax TBD).  Else, the user rejects it.

     Based on the user decision, the confirmation server does one of two
     things.  If the user accepted, the newly signed CHEQ is posted to the
     resource server:

     POST {resource URI}?accept {body contains signed CHEQ}

     Else, if the user rejected it:

     POST {resource URI}?reject

     The resource server then updates the state of the resource
     accordingly.

  4.3.  Finalizing

     The final step of the process is conveyance of the final result to
     the AI agent.

     The AI Agent will poll the resource server for updates.
     Alternatively, if MCP is used, the MCP server will poll for updates,
     and then provide an update to the AI Agent once the finalized result
     is obtained.

     Once the resource server has receive the acceptance (or rejection),
     it can respond to request from the AI Agent with the result, and the
     AI agent can proceed.









  Rosenberg, et al.        Expires 25 January 2026               [Page 11]


  Internet-Draft                    CHEQ                         July 2025


  5.  Using CHEQ for Data Privacy

     The CHEQ protocol has an important property that the confirmation
     process happens outside of the scope of the LLM.  This enables CHEQ
     to be used in cases where the user does not wish to provide sensitive
     information to the AI Agent.

     In these cases, the confirmation server function is subsumed into the
     resource server.

     Consider the following example.  Instead of a flight booking, the
     user is using an AI Agent to transfer funds between bank accounts.
     This requires highly sensitive information - most notably the origin
     and destination account numbers.  The user does not wish to expose
     this information to the AI Agent, and specificaly, to the underlying
     LLM.

     To address this, the banking service can implement an API for
     transferrig funds, which is meant specifically for usage with CHEQ.
     This API would not take the parameters normally required for a
     transfer - no account numbers, no dollar amounts.  Instead, the API
     is just "transfer funds".  This API can be turned into a tool by the
     MCP server, which the AI Agent can decide to invoke.  When it is
     invoked, the banking server immediately responds with the 202 and
     passes the URI package.  In this use case, the confirmation server is
     the same as the resource server.  When the user application connects
     to the resource server to perform the confirmation, the resulting UI
     can be used for the actual data collection.  Once the data is
     collected, the AI Agent gets the results - merely that the data was
     transferred.  In this application of the CHEQ protocol, only the URI
     pack is ever sent on the wire.  The CHEQ object never needs to be
     generated, because the resource and confirmation server are the same.
     Indeed, the CHEQ would have contained sensitive information (the
     account numbers).

     In this case, we have enabled AI agents to work with users on complex
     tasks which require data collection that can be hidden from the AI
     Agent, achieving data privacy.

     The decision on which APIs require private data, and require CHEQ to
     be used, is made by the resource service.










  Rosenberg, et al.        Expires 25 January 2026               [Page 12]


  Internet-Draft                    CHEQ                         July 2025


  6.  Usage with MCP and A2A

     CHEQ can easily be integrated into MCP, so that an MCP server sits
     between the AI Agent and the resource server in the diagram above.
     It requires an extension to the elicitation specifications, enabling
     the URI pack to be transferred from the resource server, through MCP,
     to the AI Agent.

     In a similar way, CHEQ can be integrated into A2A.  If Agent 1
     connects to Agent 2, and Agent 2 wishes to request user confirmation,
     Agent 2 can take the URI pack, pass it backwards through A2A to agent
     1, which passes it to its user.

  7.  Usage with Voice Interfaces

     Modern AI Agents can also make use of voice interfaces towards the
     user.  The CHEQ protocol works equally well in this case, with a
     slightly different flow.

     Consider the User Application in this case as a voice gateway,
     receiving the voice traffic from the user and integrating it into the
     AI Agent.  This function may be co-located with the AI Agent, or it
     could be a separate component that (for example) is doing speech to
     text and speech synthesis in front of a text-based AI Agent.

     In either case, when the user application receives the URI pack,
     instead of passing this onto the user's web browser, it would connect
     to the confirmation server and retrieve a "raw" version of the CHEQ,
     read it out over voice, gain user appoval via voice, and then post
     that to the confirmation server.  This does require the confirmation
     server to support a flow which is amenable to rendering as voice, not
     HTML.

  8.  Detailed Protocol Specification

  8.1.  URI Pack Syntax and Semantics

     Details to be filled in.

  8.2.  CHEQ Object Syntax and Semantics

     Details to be filled in

  8.3.  CHEQ Protocol Details

     Details to be filled in





  Rosenberg, et al.        Expires 25 January 2026               [Page 13]


  Internet-Draft                    CHEQ                         July 2025


  9.  Conclusions

     The CHEQ protocol provides a way for end users to confirm actions
     taken by AI Agents.  It does so outside of the LLM and AI Agent
     itself, eliminating any risk of the LLM hallucinating a tool call
     that the user does not desire.  The usage of out-of-band UI also
     provides a technique for data privacy, enabling AI agents to perform
     sensitive operations (like banking transfers) where the user does not
     wish to provide the sensitive information to the AI Agent.

  10.  Informative References

     [I-D.ietf-oauth-v2-1]
                Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
                Authorization Framework", Work in Progress, Internet-
                Draft, draft-ietf-oauth-v2-1-13, 28 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                v2-1-13>.

     [I-D.meunier-web-bot-auth-architecture]
                Meunier, T., "HTTP Message Signatures for automated
                traffic Architecture", Work in Progress, Internet-Draft,
                draft-meunier-web-bot-auth-architecture-02, 19 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-meunier-web-
                bot-auth-architecture-02>.

     [I-D.rosenberg-ai-protocols]
                Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
                and Requirements for AI Agent Protocols", Work in
                Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
                5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
                rosenberg-ai-protocols-00>.

  Authors' Addresses

     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Pat White
     Bitwave
     Email: pat.white@traego.com


     Cullen Jennings
     Cisco
     Email: fluffy@cisco.com



  Rosenberg, et al.        Expires 25 January 2026               [Page 14]


name: draft-leon-distributed-multi-signer
rev: 00
title: Distributed DNSSEC Multi-Signer Bootstrap
time: 2025-08-11T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-11T13:27:57Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578719+00:00
source: ietf
abstract:
  This document presents an architecture for a distributed DNSSEC
     multi-signer model that most closely resembles "model 2" in
     [RFC8901].

     It defines two multi-signer specific entities: the "multi-signer
     agent" (MSA) that is responsible for the multi-signer process and the
     "combiner", which is responsible for "combining" unsigned zone data
     from the zone owner with zone data under control of the MSA.  It
     introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
     designate the chosen DNS Providers (signing and/or serving the zone).
     Furthermore it describes a mechanism for the MSAs to establish secure
     communication with each other, either via “pure DNS” communication
     secured by DNS SIG(0) signatures on each message or via a RESTful API
     secured by TLS.  Finally, the document describes two models for
     multi-signer process synchronization: “leader/follower mode” and
     “peer mode” and the mechanism by which a set of MSAs decide which
     model to use for a given zone.

     The scope of the document is only the distributed aspect of DNSSEC
     multi-signer up to the point where secure communication and
     synchronization method between MSAs has been established.  The
     “multi-signer algorithms” that deal with the actual synchronization
     required for multi-signer operation are described in
     [I-D.draft-ietf-dnsop-dnssec-automation].

     TO BE REMOVED: This document is being collaborated on in Github at:
     https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer
     (https://github.com/johanix/draft-leon-dnsop-distributed-multi-
     signer).  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                                         L. Fernandez
  Internet-Draft                                              E. Bergström
  Intended status: Standards Track                             J. Stenstam
  Expires: 11 August 2025                  The Swedish Internet Foundation
                                                                S. Crocker
                                               Edgemoor Research Institute
                                                           7 February 2025


                 Distributed DNSSEC Multi-Signer Bootstrap
                   draft-leon-distributed-multi-signer-00

  Abstract

     This document presents an architecture for a distributed DNSSEC
     multi-signer model that most closely resembles "model 2" in
     [RFC8901].

     It defines two multi-signer specific entities: the "multi-signer
     agent" (MSA) that is responsible for the multi-signer process and the
     "combiner", which is responsible for "combining" unsigned zone data
     from the zone owner with zone data under control of the MSA.  It
     introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
     designate the chosen DNS Providers (signing and/or serving the zone).
     Furthermore it describes a mechanism for the MSAs to establish secure
     communication with each other, either via “pure DNS” communication
     secured by DNS SIG(0) signatures on each message or via a RESTful API
     secured by TLS.  Finally, the document describes two models for
     multi-signer process synchronization: “leader/follower mode” and
     “peer mode” and the mechanism by which a set of MSAs decide which
     model to use for a given zone.

     The scope of the document is only the distributed aspect of DNSSEC
     multi-signer up to the point where secure communication and
     synchronization method between MSAs has been established.  The
     “multi-signer algorithms” that deal with the actual synchronization
     required for multi-signer operation are described in
     [I-D.draft-ietf-dnsop-dnssec-automation].

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






  Fernandez, et al.        Expires 11 August 2025                 [Page 1]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  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 11 August 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Multi-Signer Use Cases  . . . . . . . . . . . . . . . . . . .   6
       4.1.  Primary Use Case  . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Secondary Use Case  . . . . . . . . . . . . . . . . . . .   7
       4.3.  Tertiary Use Case . . . . . . . . . . . . . . . . . . . .   7
     5.  The Distributed Multi-Signer Model  . . . . . . . . . . . . .   7
       5.1.  Multi-Signer Agent: Integrated Signer vs Separate
             Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.  Source of Truth . . . . . . . . . . . . . . . . . . . . .   9
         5.2.1.  The COMBINER  . . . . . . . . . . . . . . . . . . . .  10
       5.3.  The DNS Provider  . . . . . . . . . . . . . . . . . . . .  11
     6.  Identifying the Designated Signers  . . . . . . . . . . . . .  12



  Fernandez, et al.        Expires 11 August 2025                 [Page 2]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     7.  The HSYNC RRset . . . . . . . . . . . . . . . . . . . . . . .  12
       7.1.  Semantics of the HSYNC State Field  . . . . . . . . . . .  13
       7.2.  Semantics of the HSYNC NSMgmt Field . . . . . . . . . . .  13
         7.2.1.  Limitation of Scope for NS Management . . . . . . . .  13
       7.3.  Semantics of the HSYNC Sign Field . . . . . . . . . . . .  14
     8.  Communication Between MSAs  . . . . . . . . . . . . . . . . .  14
       8.1.  MSA Communication via DNS . . . . . . . . . . . . . . . .  15
       8.2.  MSA Communication via REST API  . . . . . . . . . . . . .  15
       8.3.  Locating Remote Multi-Signer Agents . . . . . . . . . . .  15
         8.3.1.  Locating a Remote DNS-Method Multi-Signer Agent . . .  16
         8.3.2.  Locating a Remote API-Method Multi-Signer Agent . . .  17
       8.4.  The Initial HELLO Phase . . . . . . . . . . . . . . . . .  18
         8.4.1.  DNS-based HELLO Phase . . . . . . . . . . . . . . . .  18
         8.4.2.  API-based HELLO Phase . . . . . . . . . . . . . . . .  19
         8.4.3.  Interpretation of the HELLO Responses . . . . . . . .  19
       8.5.  Multi-Signer EDNS(0) Option Format  . . . . . . . . . . .  19
         8.5.1.  Encoding Transport Capabilities in the Multi-Signer
                 EDNS(0) Option  . . . . . . . . . . . . . . . . . . .  21
         8.5.2.  Encoding Synchronization Capabilities in the
                 Multi-Signer EDNS(0) Option . . . . . . . . . . . . .  21
     9.  Sequence Diagram Example of Establishing Secure Comms - "The
             Hello Phase"  . . . . . . . . . . . . . . . . . . . . . .  22
     10. Synchronization of Changes Between MSAs . . . . . . . . . . .  23
       10.1.  Leader/Follower Mode . . . . . . . . . . . . . . . . . .  24
       10.2.  Peer Mode  . . . . . . . . . . . . . . . . . . . . . . .  24
       10.3.  Multi-Signer State Transitions . . . . . . . . . . . . .  24
     11. Responsibilities of an MSA  . . . . . . . . . . . . . . . . .  24
       11.1.  Enabling Remote MSAs to Locate This MSA  . . . . . . . .  24
       11.2.  Enabling Remote MSAs to Lookup Zone Data Added By This DNS
              Provider . . . . . . . . . . . . . . . . . . . . . . . .  25
     12. Migration from Single-Signer to Multi-Signer  . . . . . . . .  26
       12.1.  Adding a single HSYNC record to an already signed
              zone . . . . . . . . . . . . . . . . . . . . . . . . . .  26
       12.2.  Changing the HSYNC NSMGMT Field from AGENT To OWNER  . .  26
       12.3.  Migrating from a Multi-Signer Architecture Back to
              Single-Signer. . . . . . . . . . . . . . . . . . . . . .  27
       12.4.  Choice of the HSYNC Mnemonic . . . . . . . . . . . . . .  27
       12.5.  Separation of MSA and COMBINER . . . . . . . . . . . . .  27
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  28
     14. IANA Considerations.  . . . . . . . . . . . . . . . . . . . .  28
       14.1.  HSYNC RR Type  . . . . . . . . . . . . . . . . . . . . .  28
       14.2.  New Multi-Signer EDNS Option . . . . . . . . . . . . . .  29
       14.3.  A New Registry for EDNS Option Multi-Signer Operation
              Codes  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  29
       15.2.  Informative References . . . . . . . . . . . . . . . . .  30
     Appendix A.  Change History (to be removed before publication)  .  31



  Fernandez, et al.        Expires 11 August 2025                 [Page 3]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

  1.  Introduction

     The issue of how to eliminate so-called "single points of failure"
     from systems to make them more robust is a recurring theme in systems
     design and so also for DNS.  In the DNS case redundancy is addressed
     by having multiple name servers for the same zone.  However, when the
     zone is DNSSEC-signed there is traditionally an additional single
     point of failure: the so-called "signer" of the zone.

     In multi-signer ([RFC8901]) model 2, a process is described by which
     it is possible to use more than one signer (each with its own set of
     keys), by having the signers (or their agents) communicate and
     exchange data that should be signed by the other signer.  The most
     obvious example is that each signer's Key-Signing Key must sign a
     DNSKEY RRset that contains the Zone-Signing Keys for all signers.

     To synchronize data between signers two models are possible: either a
     "centralized" model where a single "controller" decides what changes
     are needed, or a "distributed" model where the signers themselves (or
     an agent of each signer) decide what changes are needed.

     The first model has been implemented previously, and while it works
     from a technical point of view, it is not a good solution from a risk
     management point of view.  The primary problem is that the signers
     have difficulty accepting that an external third party (the
     controller) has the ability to modify data (in a customer zone).

     This document is an attempt to address the synchronization problem by
     proposing a distributed model without a central controller.

     The communication between signers has two parts: first it is
     necessary to find out what data each signer has for a zone.  Once all
     data has been collected it is possible to compute what changes are
     needed to the zone data at each signer.  That triggers the second
     phase where the zone data for the individual signers is changed to
     get them in sync with each other.  All of this is done automatically.

     However, from a slightly different perspective, the multi-signer
     alternative is the more general case of DNSSEC signing, with the
     (very common) case of a single signer being a special case.









  Fernandez, et al.        Expires 11 August 2025                 [Page 4]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     From that point of view, this document proposes an architecture for a
     completely automated, distributed multi-signer model together with a
     seamless transition path from the current single-signer model to the
     multi-signer model.  From the zone owners point of view, the
     transition is done through the addition of a new RRtype, HSYNC, that
     is used to designate the chosen DNS Providers, their responsibilities
     and information to enable the DNS Providers to locate each other.

     Knowledge of DNS NOTIFY [RFC1996] and DNS Dynamic Updates [RFC2136]
     and [RFC3007] is assumed.  DNS SIG(0) transaction signatures are
     documented in [RFC2931].

  1.1.  Requirements Notation

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

     ...

  3.  Requirements

     The requirements for an architecture for distributed multi-signer are
     defined as follows:

     *  Assuming all zone transfers are correctly set up, a zone owner
        MUST be able to signal to the individual multi-signer providers
        information sufficient for the providers to identify each other
        and establish secure communication.

     *  The zone owner MUST be able to signal the intent to onboard an
        additional multi-signer provider.  This MUST automatically
        initiate the multi-signer “add signer” process, as described in
        [RFC8901].

     *  The zone owner MUST be able to signal the intent to offboard an
        existing multi-signer provider.  This MUST automatically initiate
        the multi-signer “remove signer” process, as described in
        [RFC8901].

     *  All signalling from zone owner to multi-signer providers SHOULD be
        carried out via data in the served zone, to ensure that all
        providers get the same configuration information at (almost) the
        same time.



  Fernandez, et al.        Expires 11 August 2025                 [Page 5]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     *  By engaging a set of multi-signer providers (one or more), the
        zone owner MUST give up control over the following records:

        -  All DNSSEC related records in the zone

        -  Any CDS and/or CSYNC RRsets

     *  It SHOULD be possible but NOT MANDATORY for the zone owner to also
        delegate the management of the NS RRset to the set of DNS
        Providers.

  4.  Multi-Signer Use Cases

  4.1.  Primary Use Case

     The primary use case for the proposed multi-signer architecture is
     the following scenario: A zone owner needs to remove the single point
     of failure that the DNSSEC signer constitutes.  For this reason it
     contracts with two or more “multi-signer capable” DNS providers.
     Each such DNS provider provides the following service:

     *  Receive the unsigned zone via zone transfer.

     *  Locate all active DNS Providers via the HSYNC RRset as published
        by the zone owner.  Establish secure communication with all remote
        DNS Providers (via their agents).

     *  Update the DNSKEY, CDS and CSYNC RRsets as needed, based on
        synchronization with the remote signers (or their agents).

     *  Update the NS RRset if allowed by the zone owner, based on
        synchronization with the remote DNS Providers (or their agents).

     *  Sign the zone, using own DNSKEYs, but with a published DNSKEY
        RRset that includes the DNSKEYs of other signers.

     *  Possibly distribute the signed zone to a set of downstream
        authoritative nameservers under own control.

     *  Possbly distribute the signed zone to non-signing downstream DNS
        Providers.










  Fernandez, et al.        Expires 11 August 2025                 [Page 6]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  4.2.  Secondary Use Case

     A slightly different use case is where a zone owner has a desire to
     replace one DNSSEC-signing DNS provider with another.  In the first
     step it onboards the new DNS provider by adding a HSYNC RR with HSYNC
     State=“ON” thereby identifying the new DNS provider and signalling
     its role.  This informs both the present DNS providers and the
     incoming DNS provider about the addition of the new DNS provider and
     the onboarding process is automatically initiated.

     Once the onboarding operation is completed the zone owner may trigger
     the pending removal of another DNS provider by changing the HSYNC
     State flag for the outgoing DNS Provider to “OFF”. This informs all
     the present DNS providers about the pending removal and the
     offboarding process is automatically initiated.

  4.3.  Tertiary Use Case

     A third use case is where a zone owner wants to migrate from a
     single-signer model to a multi-signer model, but as a first step only
     wants to transition the existing signer to be designated via a single
     HSYNC record.  Once that is done the zone owner can continue the
     transition to a full multi-signer model at a later time by adding
     more HSYNC records.

  5.  The Distributed Multi-Signer Model

     The primary difference between monolithic and distributed multi-
     signer is that the former has a central “controller” while the latter
     doesn’t.  But there is still an absolute need for synchronization
     between the different participants in the distributed multi-signer
     setup.

     There are three immediate aspects for the design of a distributed
     multi-signer architecture:

     *  The first is “transport”: how to communicate between the
        individual instances in a multi-signer system.

     *  The second is “synchronization”: who decides what changes are
        needed where.










  Fernandez, et al.        Expires 11 August 2025                 [Page 7]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     *  The third is source of truth for different types of zone data.
        The zone owner is the source of truth for all unsigned zone data,
        except DNSSEC data.  The signer is the source of truth for all
        DNSSEC data in the zone.  Traditionally, the source of truth for
        the NS RRset is the zone owner, but with multiple DNS Providers
        having the option of moving that responsibility to the DNS
        Providers would be an important improvement.

  5.1.  Multi-Signer Agent: Integrated Signer vs Separate Agent

     In a distributed setup there must be a service located with each
     multi-signer DNS Provider that manages communication with other DNS
     Providers.  This is referred to as the multi-signer agent, or MSA.
     As not every DNS Provider needs to be signing the zone, the term is
     not entirely perfect, but sufficient.

     It is possible to implement support for the synchronization and
     communication needs directly into each “signer” (i.e. typically an
     authoritative nameserver with the ability to do online DNSSEC
     signing).  In this case the signer implements the MSA functionality.

     However, it is also possible to separate the multi-signer
     functionality into a separate agent.  This agent sits next to the
     signer, and is under the same administrative control (the "DNS
     Provider"), but is a separate piece of software.  When using this
     design each signer has an MSA attached next to it.  Each MSA is
     configured as a “secondary nameserver” to a signer and receives the
     (signed) zone from this signer.

     The “separate MSA” design has the major advantage of leaving the
     signer almost entirely out of the multi-signer complexity.  The
     requirements are only that the “signer” treats the MSA as a normal
     secondary (sends NOTIFY messages and responds to zone transfer
     requests) and that the MSA has a mechanism that allows it to make
     changes to zones upstream of the “signer” to satisfy the multi-signer
     requirements for synchronization of certain RRsets in the apex of the
     zone.

     In this document the design using a separate MSA is used, while
     pointing out that it is possible to integrate this into a future
     “signer” that implements both DNSSEC signing and the MSA
     functionality.









  Fernandez, et al.        Expires 11 August 2025                 [Page 8]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  5.2.  Source of Truth

     A common design for DNSSEC signing (regardless of multi-signer) is to
     use a separate, bump-on-the-wire signer.  This is a signer that
     receives the unsigned zone via an incoming zone transfer, signs the
     zone, and publishes the signed zone via an outbound zone transfer.
     In such a design the source of truth has been split up between the
     “zone owner” (source of truth for all non-DNSSEC zone data), and the
     signer (source of truth for all DNSSEC data in the zone).

     In a distributed multi-signer architecture the source of truth is
     further split up into three participants:

     *  The zone owner is the source of truth for all unsigned zone data,
        except DNSSEC data and possibly the NS RRset.

     *  The signer is the source of truth for all data generated via
        DNSSEC signing: own DNSKEYs, NSEC/NSEC3 RRs, RRSIGs, etc.

     *  The MSA is the source of truth for the RRsets that must be kept in
        sync across all the signers for the zone.  This includes the
        DNSKEYs from other signers, CDS and CSYNC RRsets.  Possibly also
        the NS RRset.

     The NS RRset is an interesting special case.  Traditionally the NS
     RRset is maintained by the zone owner, but based on data from the DNS
     providers (as authoritative nameservers is a primary service for the
     DNS provider).  However, in a distributed multi-signer architecture
     the NS RRset should preferably be maintained by the MSA.  For this
     reason the proposed design makes control of the NS RRset explicit and
     the responsibility of the zone owner to choose whether to retain
     control or delegate to the MSAs.  Hence:

     *  The MSA is the source of truth for the NS RRset, subject to the
        policy of the zone owner, as described in the HSYNC RRset.

     Making the control of the NS RRset explicit is useful regardless of
     whether a zone uses multiple signers or single signer.

     To be able to keep the signer as simple as possible, the changes to
     the NS, DNSKEY, CDS and CSYNC RRsets must be introduced into the
     unsigned zone before the zone reaches the signer.  Likewise, to keep
     the zone owner as simple as possible (i.e. not involved in the
     details of the multi-signer automation) these changes must be
     introduced into the unsigned zone after the zone leaves the zone
     owner.





  Fernandez, et al.        Expires 11 August 2025                 [Page 9]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  5.2.1.  The COMBINER

     The consequence of these requirements is that the DNSKEY, CDS and
     CSYNC RRsets (and possibly the NS RRset) are maintained via a
     separate piece of software inserted between the zone owner and the
     signer.  This is referred to as the multi-signer COMBINER.

     The COMBINER has the following features:

     *  It supports inbound zone transfer of the unsigned zone from the
        zone owner.

     *  It receives updates for the NS, DNSKEY, CDS and CSYNC RRsets from
        the MSA.  Typically the mechanism used is DNS UPDATE with a TSIG
        signature, as this is easy to configure in a local context.
        However, other mechanisms, including APIs, are possible.

     *  It stores all data received from the MSA separate from the zone
        data received from the zone owner.

     *  Whenever it receives a new unsigned zone from the zone owner it
        COMBINES zone data from the zone owner (the majority of the zone)
        with specific zone data under control of the MSA: three specific
        RRsets, all in the apex of the zone: the DNSKEY,CDS and CSYNC
        RRsets.

     *  It is policy free.  I.e. the COMBINER is not making any judgement
        about what data to include in the zone from the four defined
        RRsets.  That judgement is the role of the MSA.

     *  It does not sign the zone.

     *  It provides outbound zone transfer of the combined zone to the
        signer.

     Example setup with two signers showing the logical flow of zone data
     between the zone owner, the COMBINER, the signer and the MSA:














  Fernandez, et al.        Expires 11 August 2025                [Page 10]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


                               +--------------+
                               |     owner    |
                  xfr          +-+---------+--+    xfr
               /----------------/           \--------------------\
              /                                                   \
       +-----+----+    DNS  +-----+  DNS/API  +-----+  DNS    +----+-----+
       | combiner +<--------+ msa +-----------+ msa +-------->+ combiner |
       +-----+----+  UPDATE +--+--+           +--+--+ UPDATE  +----+-----+
             |                 ^                 ^                 |
             v xfr             |                 |                 v xfr
       +-----+----+     xfr    |                 |   xfr      +----+-----+
       |  signer  +------------+                 +------------+  signer  |
       +-----+----+                                           +----+-----+
             |                                                     |
             v                                                     v
          +--+--+                                               +--+--+
          | NS  |--+                                            | NS  |+
          +-----+  |--+                                         +-----+|-+
             +-----+  |                                            +---+ |
                +-----+                                              +---+

  5.3.  The DNS Provider

     A "DNS Provider" is a term that is most commonly used to refer to an
     entity that provides authoritative DNS service to one or more zone
     owners.  In the context of this document it is used to refer to an
     entity that provides some subset of the following services:

     *  Signing a zone received from the zone owner.

     *  Serving the zone via a set of authoritative nameservers.

     *  Distributing the signed zone to other downstream DNS Providers.

     In addition to the above services a DNS Provider MUST also provide:

     *  An MSA for synchronization with other DNS Providers

     *  A COMBINER for the management of changes to the zone via the
        synchronization among MSAs (if it provides a signer)

     I.e. in the setup above there are two DNS Providers, both of which
     are "complete" in the sense that they provide all three of the above
     services.







  Fernandez, et al.        Expires 11 August 2025                [Page 11]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  6.  Identifying the Designated Signers

     It is the responsibility of the zone owner to choose a set of "DNS
     Providers", either internal or external to the zone owners
     organization.  These DNS Providers MUST be clearly and uniquely
     designated via publication in the HSYNC RRset, located at the apex of
     the zone and consisting of one HSYNC record for each signer.

     The HSYNC RRset MUST be added, by the zone owner, to the, typically
     unsigned, zone that the zone owner maintains so that this RRset is
     visible to the downstream DNS Providers and their multi-signer
     agents.

  7.  The HSYNC RRset

     The HSYNC RR has the zone name that publishes the HSYNC RRset as the
     owner name (i.e. the HSYNC RRset must be located at the apex of the
     zone).  The RDATA consists of four fields "State","NSMgmt", "Sign"
     and "Identity":

     zone.example.  IN HSYNC State NSMgmt Sign Identity.

     State: Unsigned 8-bit.  Defined values are 1=ON and 2=OFF.  The value
     0 is an error.  Values 3-127 are presently undefined.  Values 128-255
     are reserved for private use.  The presentation format allows either
     as integers (1 or 2) or as tokens (“ON” or “OFF”).

     NSMgmt: Unsigned 8-bit.  Defined values are 1=Zone owner and 2=MSA.
     The value 0 is an error.  Values 3-255 are presently undefined (and
     not expected to be defined).  The presentation format allows either
     as integers (1 or 2) or as tokens (“OWNER” or “AGENT”).

     Sign: Unsigned 8-bit.  Defined values are 1=YES and 2=NO.  The value
     0 is an error.  If Sign=YES for a particular HSYNC record, then the
     signer associated with that Identity is a designated signer for the
     zone.

     Identity: Domain name.  Used to uniquely identify the Multi-Signer
     Agent for the DNS Provider that the MSA represents.

     Example:

     zone.example.  IN HSYNC ON AGENT YES msa.provider.example.








  Fernandez, et al.        Expires 11 August 2025                [Page 12]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  7.1.  Semantics of the HSYNC State Field

     The HSYNC State field is used to signal to all MSAs what the status
     of each MSA is from the point-of-view of the zone owner.  The two
     possible values are "ON" and "OFF" where "ON" means that the MSA is a
     currently designated signer for the zone and "OFF" means that the MSA
     is previously designated signer for the zone that is in the process
     of being offboarded.

     The reason for the "OFF" state is that the offboarding process
     involves the remaining signers (hence the signalling) and it is
     important to know which signer is being offboarded so that the
     correct data may be removed in the correct order during the multi-
     signer "remove signer" process (see [RFC8901]).

     Once the offboarding process is complete the HSYNC RR for the
     offboarded MSA may be removed from the zone at the zone owners
     discretion.

  7.2.  Semantics of the HSYNC NSMgmt Field

     The NSMgmt field is used to signal to the MSAs who is responsible for
     the contents of the NS RRset for the zone.  The two possible values
     are "OWNER" and "AGENT".

     The value "OWNER" signals that the zone owner is responsible for the
     NS RRset and is responsible for updating the NS RRset (either with or
     without the unified data from all MSAs).  In this case the MSAs MUST
     NOT instruct the COMBINER to update the NS RRset.

     The value "AGENT" means that the MSAs representing DNS Providers that
     sign the zone are responsible for the contents of the NS RRset.  In
     this case the these MSAs MUST instruct the COMBINER to update the NS
     RRset with the unified NS RRset data from all MSAs.

  7.2.1.  Limitation of Scope for NS Management

     For the purpose of this document the NSMgmt Field only covers the NS
     RRset.  I.e. it does not include the address records of in-bailiwick
     authoritative nameservers.  The reasons are:

     *  Limiting the possibility of DNS Providers "polluting" the name
        space of the zone.

     *  Keeping the specification simpler, as the concept of "delegated"
        NS management is new.





  Fernandez, et al.        Expires 11 August 2025                [Page 13]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     It is possible to make an argument for delegating management of
     address records for in-bailiwick authoritative nameservers, but this
     document does not.

  7.3.  Semantics of the HSYNC Sign Field

     The Sign field is used to signal to all MSAs whether the zone owner
     requests that the DNS Provider that the MSA represents should sign
     the zone or not.  The two possible values are "YES" and "NO" where
     "YES" means that the MSA represents a currently designated signer for
     the zone and "NO" means that the MSA does not.

     When Sign=NO the MSA MUST still participate in the communication
     between MSAs for the zone, but MUST NOT instruct the COMBINER to
     update the NS RRset.

  8.  Communication Between MSAs

     For the communication between MSAs there are two choices that need to
     be made among the designated MSAs for a zone.  The first is what
     "transport" to use for the communication.  The second is what
     "synchronization" model to use when executing future multi-signer
     processes.

     The two defined transport alternatives are:

     *  DNS-based communication (mandatory to support)

     *  REST API-based communication

     Each has pros and cons and at this point in time it is not clear that
     one always is better than the other.  To simplify the choice of
     transport DNS-based communication is mandatory to support and the
     REST API-based communication may only be used if all MSAs support it.
     Supported transports are signaled in the Multi-Signer EDNS(0) Option
     (see section NNN below).

     The two defined synchronization alternatives are:

     *  Leader/Follower synchronization (mandatory to support)

     *  Peer-to-Peer synchronization

     Just as for transport, supported synchronization models are signaled
     in the Multi-Signer EDNS(0) Option (see section NNN below).






  Fernandez, et al.        Expires 11 August 2025                [Page 14]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     Regardless of the synchronization model and communication method
     used, the MSAs SHOULD exchange all needed information about the zone
     and the DNS Provider they represent to enable the multi-signer
     processes to execute correctly.  This includes notifications about
     changes to DNSKEYs, changes to the NS RRset, etc.  Depending on
     synchronization model it may also include instructions for changes to
     the zone.

  8.1.  MSA Communication via DNS

     This transport alternative is based on the observation that all the
     communication needs between MSAs can be expressed via DNS messages.
     Notifications are sent as DNS NOTIFY messages.  Requests for changes
     to a zone are sent as DNS UPDATE messages, etc.  The sole remaining
     communication requirement is for how to communicate information about
     the current state between MSAs in an ongoing multi-signer process.
     For this reason a dedicated EDNS(0) opcode specifically for multi-
     signer synchronization is proposed.

     This model is based on [I-D.draft-berra-dnsop-keystate] that solves a
     similar problem for delegation synchronization between child and
     parent, which has already been implemented and shown to work.

  8.2.  MSA Communication via REST API

     REST APIs are well-known and a natural fit for many distributed
     systems.  The challenge is mostly in the initial setup of secure
     communication.  The certificates need to be validated, preferably
     without a requirement on trusting a third party CA.  The API
     endpoints for each MSA need to be located.  Once secure communication
     has been established, using a REST API for MSA communication is
     straight-forward.

  8.3.  Locating Remote Multi-Signer Agents

     When an MSA receives a zone via zone transfer from the signer it will
     analyze the zone to see whether it contains an HSYNC RRset.  If there
     is no HSYNC RRset the zone MUST be ignored by the MSA from the point-
     of-view of multi-signer synchronization.

     If, however, the zone does contain an HSYNC RRset then the MSA must
     analyze this RRset to identify the other MSAs for the zone via their
     target names in each HSYNC record.  If any of the other MSAs listed
     in the HSYNC RRset is previously unknown to this MSA then secure
     communication with this other MSA MUST be established.






  Fernandez, et al.        Expires 11 August 2025                [Page 15]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     Secure communication can be achieved via various transports and it is
     up to the MSAs in the zone's HSYNC records to determine amongst
     themselves.  This document proposes two transports: "DNS" and "API".
     "DNS" is designated as as a baseline that MSAs MUST support to be
     compliant.

     The following two subsections describe the mechanism by which an MSA
     SHOULD locate a remote MSA and establish secure DNS-based and API-
     based communications, respectively.

  8.3.1.  Locating a Remote DNS-Method Multi-Signer Agent

     Locating a remote MSA using the DNS mechanism consists of the
     following steps:

     *  Lookup and DNSSEC-validate a URI record for the DNS protocol for
        the HSYNC identity.  This provides the domain name and port to
        which DNS messages should be sent.

     *  Lookup and DNSSEC-validate the SVCB record of the URI record
        target to get the IP addresses to use for communication with the
        remote MSA.  If the returned SVCB record includes a "port=NNN"
        hint then this MUST be ignored.  I.e. the port to use is defined
        by the URI record.

     *  Lookup and DNSSEC-validate the KEY record of the URI record target
        name.  This enables verification of the SIG(0) public key of the
        remote MSA once communication starts.

     Example: given the following HSYNC record for a remote MSA:

     zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

     The local MSA will look up the URI record for msa.provider.com:

     _dns._tcp.msa.provider.com.  IN URI 10 10
     “dns://ns.msa.provider.com:5399/” _dns._tcp.msa.provider.com.  IN
     RRSIG URI …

     which triggers a lookup for ns.msa.provider.com.  SVCB to get the
     IPv4 and IPv6 addresses as ipv4hints and ipv6hints in the response to
     the SVCB query:

     ns.msa.provider.com.  IN SVCB 1 ipv4hint=5.6.7.8 ipv6hint=2001::53
     ns.msa.provider.com.  IN RRSIG SVCB …

     and also a look up for the KEY record for ns.msa.provider.com, which
     may look like this:



  Fernandez, et al.        Expires 11 August 2025                [Page 16]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     ns.msa.provider.com.  IN KEY … ns.msa.provider.com.  IN RRSIG KEY …

     Once all the DNS lookups and DNSSEC-validation of the returned data
     has been done, the local MSA is able to initiate communication with
     the remote MSA and verify the identity of the responding party via
     the validated KEY record for the remote MSAs SIG(0) public key.

  8.3.2.  Locating a Remote API-Method Multi-Signer Agent

     Locating a remote MSA using the API mechanism consists of the
     following steps:

     *  Lookup and DNSSEC-validate the URI record for for the HTTPS
        protocol for the HSYNC identity.  This provides the base URL that
        will be used to construct the individual API endpoints for the
        REST API.  It also provides the port to use.

     *  Lookup and DNSSEC-validate the SVCB record for the URI record
        target.  This provides the IP-addresses to use for communication
        with the MSA.  If the returned SVCB record includes a "port=NNN"
        hint then this MUST be ignored.  I.e. the port to use is defined
        by the URI record.

     *  Lookup and DNSSEC-validate the TLSA record for the port and
        protocol specified in the URI record.  This will enable
        verification of the certificate of the remote MSA once
        communication starts.

     Example: given the following HSYNC record for a remote MSA:

     zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

     the local MSA will look up the URI record for msa.provider.com:

     _https._tcp.msa.provider.com.  IN URI 10 10
     “https://api.msa.provider.com:443/api/v2/”
     _https._tcp.msa.provider.com.  IN RRSIG URI …

     which triggers a lookup for api.msa.provider.com IPv4 and IPv6
     addresses as hints in an SVCB RR:

     api.msa.provider.com.  IN SVCB 1 ipv4hint=1.2.3.4
     ipv6hint=2001::bad:cafe:443 api.msa.provider.com.  IN RRSIG SVCB …

     Now we know the IP-address and the port as well as the base URL to
     use.  Finally the TLSA record for _443._tcp.api.msa.provider.com is
     looked up, with a response that may look like this:




  Fernandez, et al.        Expires 11 August 2025                [Page 17]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     _443._tcp.api.msa.provider.com.  IN TLSA 3 1 1 ….
     _443._tcp.api.msa.provider.com.  IN RRSIG TLSA …

     Once all the DNS lookups and DNSSEC-validation of the returned data
     has been done, the local MSA is able to initiate communication with
     the remote MSA and verify the identity of the responding party via
     the TLSA record for the remote MSAs certificate.

  8.3.2.1.  Fallback to DNS-based Communication

     If the API-based communication fails, either because needed DNS
     records are missing, the TLSA record fails to validate the remote
     MSAs certificate or the remote MSA simply doesn't respond, the local
     MSA MUST fall back to DNS-based communication.

  8.4.  The Initial HELLO Phase

     When two MSAs need to communicate with each other for the first time
     (because they are both deisgnated signers for the same zone), they
     need to establish secure communication.  This is done in a "HELLO"
     phase where the MSAs exchange information about their capabilities.

     If all the information needed for API-based transport for the remote
     party was available, the MSA SHOULD attempt an API-based HELLO.  If,
     however, this fails for some reason, it should fall back to DNS-based
     HELLO.

  8.4.1.  DNS-based HELLO Phase

     When using DNS-based communication the HELLO phase is done by sending
     a NOTIFY(SOA) for the zone that triggered the need for communication.
     The NOTIFY message MUST contain a Multi-Signer EDNS(0) Option (see
     section NNN below).

     In the Multi-Signer EDNS(0) Option the OPERATION field MUST have the
     value "HELLO" (1).  Furthermore, the MSA signals its transport and
     synchronization capabilities in the TRANSPORT and SYNCHRONIZATION
     fields.  This message is signed with the SIG(0) key for the local MSA
     for which the public key is published as a KEY record for the MSA.

     In the response to the NOTIFY, the remote MSA does the same and the
     two MSAs can now verify each other's identity and are also aware of
     the other MSAs transport and synchronization capabilities.








  Fernandez, et al.        Expires 11 August 2025                [Page 18]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  8.4.2.  API-based HELLO Phase

     When using API-based communication the HELLO phase is done by sending
     a REST API POST request to the remote MSA at the "/hello" endpoint.
     The request MUST contain a JSON encoded object with the following
     fields:

     *  "transport": The transport capabilities of the local MSA.

     *  "synchronization": The synchronization capabilities of the local
        MSA.

     The response MUST contain a JSON object with the following fields:

     *  "transport": The transport capabilities of the remote MSA.

     *  "synchronization": The synchronization capabilities of the remote
        MSA.

  8.4.3.  Interpretation of the HELLO Responses

     Once an MSA has received HELLO responses from all other MSAs that are
     designated signers for the zone, it knows the capabilities of the
     MSAs as a group.  It can then use this information to determine which
     transport to use:

     *  If all MSAs support API-based communication, the MSAs will use
        API-based communication for this zone.

     *  If one or more MSAs only support DNS-based communication, the MSAs
        will use DNS-based communication for this zone.

     Likewise, each MSA now knows the synchronization capabilities of the
     other MSAs and can determine which synchronization model to use:

     *  If all MSAs support the Peer-to-Peer synchronization model, the
        MSAs will use the Peer-to-Peer synchronization model for this
        zone.

     *  If one or more MSAs only support the Leader/Follower
        synchronization model, the MSAs will use the Leader/Follower
        synchronization model for this zone.

  8.5.  Multi-Signer EDNS(0) Option Format

     This document uses an Extended Mechanism for DNS (EDNS0) [RFC6891]
     option to include Multi-Signer synchronization information in DNS
     messages.



  Fernandez, et al.        Expires 11 August 2025                [Page 19]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     This option is structured the same way as the KeyState option
     described in [I-D.draft-berra-dnsop-keystate], which has been
     implemented and shown to work for a similar use case.  The
     requirements for multi-signer synchronization are sufficiently
     different that it is not possible to re-use the KeyState OPT also for
     this purpose and therefore a new EDNS(0) option is defined here.

     The Multi-Signer EDNS(0) option is structured as follows:

                                                   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                       |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     4:  |           OPERATION           |           TRANSPORT           |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     8:  |        SYNCHRONIZATION        |                               /
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     10: / OPERATION-BODY                                                /
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     Field definition details:

     OPTION-CODE: 2 octets / 16 bits (defined in [RFC6891]) contains the
     value TBD for Multi-Signer.

     OPTION-LENGTH: 2 octets / 16 bits (defined in [RFC6891]) contains the
     length of the payload (everything after OPTION-LENGTH) in octets and
     should be 4 plus the length of the OPERATION-BODY field (which may be
     zero octets long).

     OPERATION: 8 bits.  Signals the type of operation the message
     performs.  This document defines the two operations HELLO and
     HEARTBEAT.  For a complete distributed multi-signer specification a
     number of additional operations will need to be allocated to be able
     to describe the states in the different multi-signer processes.  This
     allocation must be done either in a revision to this document or in a
     subsequent document.

     TRANSPORT: 8 bits.  Encodes the transport capabilities of the MSA.
     With 8 bits it is possible to define up to 8 different transports of
     which this document defines two: DNS and API.







  Fernandez, et al.        Expires 11 August 2025                [Page 20]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     SYNCHRONIZATION: 8 bits.  Encodes the synchronization capabilities of
     the MSA.  With 8 bits it is possible to define up to 8 different
     synchronization models of which this document defines two: Leader/
     Follower and Peer-to-Peer.

     OPERATION-BODY: Variable-length.  Used to carry operation-specific
     parameters.

  8.5.1.  Encoding Transport Capabilities in the Multi-Signer EDNS(0)
          Option

     An MSA signals the union of its transport capabilities by setting the
     corresponding bits to 1.

     0: DNS transport supported (baseline, MUST be supported by all MSAs)

     1: API transport supported

     2: unused

     3: unused

     4: unused

     5: unused

     6: unused

     7: unused

  8.5.2.  Encoding Synchronization Capabilities in the Multi-Signer
          EDNS(0) Option

     An MSA signals its synchronization capabilities by setting the
     corresponding bits to 1.

     0: Leader/Follower synchronization supported (baseline, MUST be
     supported by all MSAs)

     1: Peer-to-Peer synchronization supported

     2: unused

     3: unused

     4: unused

     5: unused



  Fernandez, et al.        Expires 11 August 2025                [Page 21]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     6: unused

     7: unused

  9.  Sequence Diagram Example of Establishing Secure Comms - "The Hello
      Phase"

     The procedure of locating another MSA and establishing a secure
     communication, referred to as "The Hello Phase" is examplified in the
     sequence diagram below.

     The procedure is as follows:

     1.  The multisigner agents receive a zone via zone transfer.  By
         analyzing the HSYNC RRset each MSA become aware of the identities
         of the other MSAs for the zone.  I.e. each MSA knows which other
         MSAs it needs to communicate with.  Communication with each of
         these, previously unknown, remote MSAs is referred to as
         "NEEDED".

     2.  Each MSA starts aquiring the information needed to establish
         secure communications with any previously unknown MSAs.  Here we
         only illustrate the baseline case where DNS-based communications
         is to be used in the following phase.  Once all needed
         information has been collected the communication with this remote
         MSA is considered to be "KNOWN".

     3.  Once an MSA has received the required information (URI, SVCB and
         KEY records in the baseline case) it sends a NOTIFY message with
         a dedicated Multi-Signer OPT code with OPERATION="HELLO".  The
         sender uses this OPT field to signal its transport and
         synchronization capabilities.  Similarly, the responder signals
         its capabilities using the same field.

     4.  When an MSA either gets a NOERROR response to its NOTIFY
         OPT(hello) message or responds with a NOERROR, it transitions out
         of "The Hello Phase" with the exchanging party and they
         transition to the next phaste where they start sending NOTIFY
         OPT(heartbeat) signals instead.  The communication with the
         remote MSA is now considered to be in the "OPERATIONAL" state.

     In the case where one MSA is aware of the need to communicate with
     another MSA, but the other is not (eg. the zone transfer was dealyed
     for one of them), the slower one SHOULD respond with a RCODE=REFUSED
     to any NOTIFY OPT(hello) it receives.  Once it is ready, it will send
     its own NOTIFY OPT(hello) which should be responded to with a
     RCODE=NOERROR.




  Fernandez, et al.        Expires 11 August 2025                [Page 22]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  +----------+                 +----------+                        +----------+
  |  Owner   |                 |  MSA A   |                        |  MSA B   |
  +----------+                 +----------+                        +----------+
       |                            |                                    |
       |      AXFR(sign-me.se.)     |                                    |
       |--------------------------->|                                    |
       |      AXFR(sign-me.se.)     |                                    |
       |---------------------------------------------------------------->|
       |                            |                                    |
       |                            |                                    |
       |                            |  QUERY _dns._tcp.msa-b.se. URI?    |
       |                            |----------------------------------->|
       |                            |  QUERY ns.msa-b.se. SVCB?          |
       |                            |----------------------------------->|
       |                            |  QUERY ns.msa-b.se. KEY?           |
       |                            |----------------------------------->|
       |                            |                                    |
       |                            |                                    |
       |                            |  NOTIFY sign-me.se. OPT(hello)     |
       |                            |----------------------------------->|
       |                            |  NOERROR sign-me.se. OPT(hello)    |
       |                            |<-----------------------------------|
       |                            |                                    |
       |                            |                                    |
       |                            |  NOTIFY sign-me.se. OPT(heartbeat) |
       |                            |----------------------------------->|
       |                            |                                    |
       |                            |                                    |
       |                            |  NOTIFY sign-me.se. OPT(heartbeat) |
       |                            |<-----------------------------------|
       |                            |                                    |
       |                            |                                    |
       |                            |                                    |

  10.  Synchronization of Changes Between MSAs

     There are two defined models for synchronization.  The first (Leader/
     Follower) has the advantage of more clearly mapping to the original
     multi-signer model 2, with a single controller.  The second model has
     the advantage of less total communication between MSAs (including no
     elections) but the potential disadvantage of more fine grained
     communication during the execution of a multi-signer process.

     At this stage it is not clear that one model is superior to the
     other.






  Fernandez, et al.        Expires 11 August 2025                [Page 23]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  10.1.  Leader/Follower Mode

     In a leader/follower deployment, a designated multi-signer agent
     assumes the role of a leader, directing other agents, or followers,
     through the multi-signer process state transitions.  In this mode it
     is necessary to conduct “elections” where one of the MSAs is chosen
     as the Leader before initiating a new multi-signer process.  Once the
     Leader has been chosen, this model is mostly equivalent to the
     original multi-signer “model 2”, with a single controller.  The other
     MSAs (the followers) essentially become proxies between the
     controller (the Leader) and the DNS Provider each MSA represents.

  10.2.  Peer Mode

     In peer mode, the MSAs still need to locate each other, but instead
     of relying on trust in each other, each multi-signer agent operates
     independently as a peer.  I.e. each MSA executes each step in the
     multi-signer process on its own.  The communication is essentially
     reduced to a notification mechanism (“I am now in state N”), although
     authenticated to avoid having the contents of this communication
     become an attack vector for an adversary.

  10.3.  Multi-Signer State Transitions

     For the multi-signer process semantics to be fulfilled, a new state
     transition in a multi-signer process is only possible when all
     signing DNS Providers (or their MSAs) have reached the same state.

     I.e. regardless of whether each MSA traverse the finite state machine
     separately, or only the Leader does, and the Followers report back
     when they have suceeded in executing the associated Actions (as
     described in [I-D.draft-ietf-dnsop-dnssec-automation], they must not
     be further apart than one transition.

  11.  Responsibilities of an MSA

     Each MSA has certain responsibilites, depending on supported
     transports and synchronization methods.

  11.1.  Enabling Remote MSAs to Locate This MSA

     For a group of MSAs to be able to communicate securely and
     synchronize data for a zone, each MSA must ensure that the DNS
     records needed for secure communication with other MSAs are
     published:

     *  URI, SVCB and KEY records required for DNS-based communication
        secured by SIG(0).



  Fernandez, et al.        Expires 11 August 2025                [Page 24]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     *  URI, SVCB and TLSA records required for API-based communication
        secured by TLS (if supported).

     *  All of the above MUST be published in a DNSSEC-signed zone under
        the domain name that is the identity of the MSA.

  11.2.  Enabling Remote MSAs to Lookup Zone Data Added By This DNS
         Provider

     When using DNS transport between MSAs, four types of information is
     needed to be conveyed from one party to another:

     1.  Notifications (sent as DNS NOTIFY).

     2.  Retrieval of existing data (looked up via DNS QUERY).

     3.  Changes to existing data (sent as DNS UPDATE).

     4.  Multi-signer "state" information (sent via the Multi-Signer
         EDNS(0) OPT).

     The second case, i.e. looking up data for a zone that is particular
     to a specific DNS Provider is typically about the DNSKEY RRs added by
     that signer or the NS RRs representing the authoritative nameservers
     for that DNS Provider.  This is looked up under domain names
     constructed from the name of the served zone and the identity of the
     DNS Provider.

     For each zone that is managed, the MSA must ensure that the data
     needed for synchronization with other MSAs is published:

     *  The DNSKEY RRset for the zone consisting of the DNSKEYS that the
        local signer for this DNS Provider uses to sign the zone.

     *  The CDS RRset for the zone, representing the KSK that the local
        signer uses to sign the zone (when needed).

     *  The NS RRs for the zone, consisting of the NS records of the
        authoritative nameservers that this DNS Provider is responsible
        for.

     *  All of the above MUST be published in a DNSSEC-signed zone under
        the domain name that is the concatenation of the zone name and the
        identity of the MSA.  Example for the zone "zone.example" and the
        MSA "msa.provider":






  Fernandez, et al.        Expires 11 August 2025                [Page 25]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     zone.example.msa.provider.  IN DNSKEY ... zone.example.msa.provider.
     IN RRSIG DNSKEY ... zone.example.msa.provider.  IN NS ...
     zone.example.msa.provider.  IN RRSIG NS ...

  12.  Migration from Single-Signer to Multi-Signer

     The migration from a single-signer to a multi-signer architecture is
     done by adding the HSYNC RRset to the zone.  However, this may be
     done in several steps.

  12.1.  Adding a single HSYNC record to an already signed zone

     Adding a single HSYNC record to a zone that is already signed by the
     DNS provider "provider.com" with NSMGMT=OWNER is a no-op that does
     not change anything:

     zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

     The zone was already signed by the DNS provider "provider.com" and
     the provider added any needed DNSSEC records, including DNSKEYs.  The
     zone NS RRset was managed by the zone owner.  All of this is
     unchanged by the addition of the HSYNC RRset.

  12.2.  Changing the HSYNC NSMGMT Field from AGENT To OWNER

     In a multi-signer architecture each MSA publishes the data it
     contributes to the zone under the domain name {zone}.{identity}. I.e.
     the zone DNSKEYs that the MSA msa.provider. uses are published as

     zone.example.msa.provider.  DNSKEY ... zone.example.msa.provider.
     DNSKEY ...

     Likewise, the NS records for the zone are published as

     zone.example.ns.msa.provider.  NS ... zone.example.ns.msa.provider.
     NS ...

     To migrate from "owner maintained" NS RRset to "MSA maintained", the
     zone owner must verify that the NS RRset as published by the MSA is
     correct and in sync with the NS RRset as published by the zone owner
     itself.  After this verification the zone owner changes the HSYNC
     NSMGMT field in the existing HSYNC record from NSMGMT=OWNER to
     NSMGMT=AGENT.








  Fernandez, et al.        Expires 11 August 2025                [Page 26]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  12.3.  Migrating from a Multi-Signer Architecture Back to Single-Signer.

     If, for some reason, a zone owner wants to migrate back to a single-
     signer architecture, the process is essentially the reverse of the
     migration from single-signer to multi-signer:

     1.  The zone owner offboards all MSAs but one (the one that will be
         the single-signer)

     2.  The zone owner must verify that the NS RRset it publishes (in the
         unsigned zone) is correct and in sync with the NS RRset as
         published by the remaining MSA.

     3.  The zone owner changes the HSYNC NSMGMT field in the HSYNC record
         from NSMGMT=MSA to NSMGMT=OWNER.

     The zone is now essentially back to a single-signer architecture.
     The remaining HSYNC record may be removed from the zone.

     TO BE REMOVED BEFORE PUBLICATION: # Rationale

  12.4.  Choice of the HSYNC Mnemonic

     Initially the mnemonic MSIGNER was used for the HSYNC RRset.
     However, as work progressed it became clear that we want also non-
     signing DNS Providers to be able to participate.  So the RRset is a
     signalling mehanism from zone owner to DNS Providers, some of which
     may or may not be instructed to sign the zone.  Therefore we suggest
     the mnemonic HSYNC to indicate that this is a mechanism for
     "horizontal synchronization" inside a zone.

     But the mnemonic chosen is a very minor point and should a better
     suggestion come up it would be great.

  12.5.  Separation of MSA and COMBINER

     It is possible to integrate all three multi-signer components
     (SIGNER, MSA and COMBINER) into a single piece of software (or two
     pieces, depending on the preferred way of slicing the functionality).
     However, such a composite module would be a fairly complex piece of
     software.  This document aims to describe the functional separation
     of the different components rather than make a judgement on software
     design alternatives.  Hence possible implementation choices are left
     to the implementer.







  Fernandez, et al.        Expires 11 August 2025                [Page 27]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


  13.  Security Considerations

     Multi-signer is a complex system with a number of components and a
     significant amount of automation.  The authors believe that the only
     way to make a multi-signer architecture useful in practice is via
     automation.  However, automation is a double-edged sword.  It can
     both make the system more robust and more vulnerable.

     While all communication between MSAs is authenticated (either via
     SIG(0) signatures ore TLS), the signalling from the zone owner to the
     MSAs is via the HSYNC RRset in an unsigned zone.  This is a potential
     attack vector.  However, securing zone transfers from zone owner to
     DNS providers is a well-known issue with lots of existing solutions
     (TSIG, zone transfer via a secure channel, zone transfer-over-TLS,
     etc).  Employing some of these solutions is strongly recommended.

     From a vulnerability point-of-view this architecture introduces
     several new components into the zone signing and publication process.
     In particular the COMBINER and the MSAs are new components that need
     to be secure.  The COMBINER has the advantage of not having to
     announce its location to the outside world, as it only needs to
     communicate with internal components (the zone owner, the signer and
     the MSA).

     The MSAs are more vulnerable.  They need to be discoverable by other
     MSAs and hence they are also discoverable by an adversary.  On the
     other hand, the MSAs are not needed for a new zone to signed and
     published, they are only needed when there are changes that require
     the MSAs to synchronize, which is an infrequent event.  Furthermore,
     should an MSA be unable to fulfill its role during the execution of a
     multi-signer process, the multi-signer process will simply stop where
     it is.  Regardless of where the stop (or rather pause) occurs, the
     zone will be fully functional and once the MSA is able to resume its
     role, the multi-signer process will continue from where it left off.

  14.  IANA Considerations.

     *Note to the RFC Editor*: In this section, please replace occurrences
     of "(This document)" with a proper reference.

  14.1.  HSYNC RR Type

     IANA is requested to update the "Resource Record (RR) TYPEs" registry
     under the "Domain Name System (DNS) Parameters" registry group as
     follows:

     Type  HSYNC




  Fernandez, et al.        Expires 11 August 2025                [Page 28]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     Value  TBD

     Meaning  Zone owner designation of DNS providers enabling mutual
        discovery

     Reference  (This document)

  14.2.  New Multi-Signer EDNS Option

     This document defines a new EDNS(0) option, entitled "Multi-Signer",
     assigned a value of TBD "DNS EDNS0 Option Codes (OPT)" registry

     TO BE REMOVED UPON PUBLICATION: https://www.iana.org/assignments/dns-
     parameters/dns-parameters.xhtml#dns-parameters-11 (foo)

        +-------+--------------------+----------+----------------------+
        | Value | Name               | Status   | Reference            |
        +-------+--------------------+----------+----------------------+
        | TBD   | Multi-Signer       | Standard | ( This document )    |
        +-------+--------------------+----------+----------------------+

  14.3.  A New Registry for EDNS Option Multi-Signer Operation Codes

     The Multi-Signer option also defines an 8-bit operation field, for
     which IANA is requested to create and mainain a new registry entitled
     "Multi-Signer Operations", used by the Multi-Signer option.  Initial
     values for the "Multi-Signer Operations" registry are given below;
     future assignments in in the 3-127 range are to be made through
     Specification Required review [BCP26].

  +-----------+---------------------------------------------+-------------------+
  | OPERATION | Mnemonic                                    | Reference         |
  +-----------+---------------------------------------------+-------------------+
  | 0         | forbidden                                   | ( This document ) |
  +-----------+---------------------------------------------+-------------------+
  | 1         | HELLO                                       | ( This document ) |
  +-----------+---------------------------------------------+-------------------+
  | 2         | HEARTBEAT                                   | ( This document ) |
  +-----------+---------------------------------------------+-------------------+
  | 3-127     | Unassigned                                  | ( This document ) |
  +-----------+---------------------------------------------+-------------------+
  | 128-255   | Private Use                                 | ( This document ) |
  +-----------+---------------------------------------------+-------------------+

  15.  References

  15.1.  Normative References




  Fernandez, et al.        Expires 11 August 2025                [Page 29]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
                Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
                August 1996, <https://www.rfc-editor.org/info/rfc1996>.

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

     [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
                "Dynamic Updates in the Domain Name System (DNS UPDATE)",
                RFC 2136, DOI 10.17487/RFC2136, April 1997,
                <https://www.rfc-editor.org/info/rfc2136>.

     [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
                ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
                2000, <https://www.rfc-editor.org/info/rfc2931>.

     [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
                Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
                <https://www.rfc-editor.org/info/rfc3007>.

     [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/info/rfc6891>.

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

     [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
                Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
                DOI 10.17487/RFC8901, September 2020,
                <https://www.rfc-editor.org/info/rfc8901>.

  15.2.  Informative References

     [BCP26]    Best Current Practice 26,
                <https://www.rfc-editor.org/info/bcp26>.
                At the time of writing, this BCP comprises the following:

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





  Fernandez, et al.        Expires 11 August 2025                [Page 30]


  Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


     [I-D.draft-berra-dnsop-keystate]
                Bergström, E., Fernandez, L., and J. Stenstam, "Signalling
                Key State Via DNS EDNS(0) OPT", Work in Progress,
                Internet-Draft, draft-berra-dnsop-keystate-01, 7 February
                2025, <https://datatracker.ietf.org/doc/html/draft-berra-
                dnsop-keystate-01>.

     [I-D.draft-ietf-dnsop-dnssec-automation]
                Wisser, U., Huque, S., and J. Stenstam, "DNSSEC
                automation", Work in Progress, Internet-Draft, draft-ietf-
                dnsop-dnssec-automation-03, 19 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
                dnssec-automation-03>.

  Appendix A.  Change History (to be removed before publication)

     *  draft-leon-distributed-multi-signer-00

        Initial public draft.

  Authors' Addresses

     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


     Johan Stenstam
     The Swedish Internet Foundation
     Sweden
     Email: johan.stenstam@internetstiftelsen.se


     Steve Crocker
     Edgemoor Research Institute
     United States
     Email: steve@shinkuro.com







  Fernandez, et al.        Expires 11 August 2025                [Page 31]


name: draft-mp-agntcy-ads
rev: 01
title: Agent Directory Service
time: 2026-02-24T22:07:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T22:07:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578723+00:00
source: ietf
abstract:
  The Agent Directory Service (ADS) is a distributed directory service
     designed to store metadata for AI agent applications.  This metadata,
     stored as directory records, enables the discovery of agent
     applications with specific skills for solving various problems.  The
     implementation features distributed directories that interconnect
     through a content-routing protocol.

full_text:
  Independent Submission                                    L. Muscariello
  Internet-Draft                                                  R. Polic
  Intended status: Informational                                     Cisco
  Expires: 28 August 2026                                 24 February 2026


                          Agent Directory Service
                           draft-mp-agntcy-ads-01

  Abstract

     The Agent Directory Service (ADS) is a distributed directory service
     designed to store metadata for AI agent applications.  This metadata,
     stored as directory records, enables the discovery of agent
     applications with specific skills for solving various problems.  The
     implementation features distributed directories that interconnect
     through a content-routing protocol.

  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://spec.dir.agncty.org.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-mp-agntcy-
     ads/.

     Source for this draft and an issue tracker can be found at
     https://github.com/agntcy/dir.

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





  Muscariello & Polic      Expires 28 August 2026                 [Page 1]


  Internet-Draft                  agent-dir                  February 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.

  Table of Contents

     1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Core Capabilities . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Architectural Foundation  . . . . . . . . . . . . . . . .   5
     3.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Content-Addressed Storage . . . . . . . . . . . . . . . .   5
       3.2.  OCI Integration . . . . . . . . . . . . . . . . . . . . .   6
         3.2.1.  Standards Compliance  . . . . . . . . . . . . . . . .   6
       3.3.  Record Artifact Specification . . . . . . . . . . . . . .   6
         3.3.1.  Manifest Structure  . . . . . . . . . . . . . . . . .   6
         3.3.2.  Layer Structure . . . . . . . . . . . . . . . . . . .   7
         3.3.3.  Example Record Artifacts  . . . . . . . . . . . . . .   9
         3.3.4.  Record Reconstruction . . . . . . . . . . . . . . . .  10
       3.4.  Application Integration . . . . . . . . . . . . . . . . .  10
         3.4.1.  Open Agent Schema Framework (OASF)  . . . . . . . . .  10
         3.4.2.  Third-Party Applications  . . . . . . . . . . . . . .  11
         3.4.3.  Runtime Environments  . . . . . . . . . . . . . . . .  11
       3.5.  Artifact Organization . . . . . . . . . . . . . . . . . .  11
         3.5.1.  Multi-Registry Federation . . . . . . . . . . . . . .  12
     4.  MAS Data Discovery  . . . . . . . . . . . . . . . . . . . . .  12
       4.1.  Skill Taxonomy  . . . . . . . . . . . . . . . . . . . . .  13
         4.1.1.  The Challenge of Capability Search  . . . . . . . . .  13
         4.1.2.  Taxonomy-Driven Search Optimization . . . . . . . . .  13
       4.2.  Two-Level Mapping Architecture  . . . . . . . . . . . . .  14
       4.3.  Skill Taxonomy for Search Optimization  . . . . . . . . .  14
       4.4.  Additional Taxonomies . . . . . . . . . . . . . . . . . .  15
         4.4.1.  Domain Taxonomy . . . . . . . . . . . . . . . . . . .  15
         4.4.2.  Module Taxonomy . . . . . . . . . . . . . . . . . . .  16
         4.4.3.  Multi-Dimensional Search  . . . . . . . . . . . . . .  17
         4.4.4.  Skills-to-CID Mapping . . . . . . . . . . . . . . . .  18
         4.4.5.  CID-to-PeerID Mapping . . . . . . . . . . . . . . . .  18
       4.5.  DHT-Based Discovery Process . . . . . . . . . . . . . . .  18
         4.5.1.  Skill Registration  . . . . . . . . . . . . . . . . .  19
         4.5.2.  Discovery Query Resolution  . . . . . . . . . . . . .  19
         4.5.3.  Additional Tanomoxies . . . . . . . . . . . . . . . .  20



  Muscariello & Polic      Expires 28 August 2026                 [Page 2]


  Internet-Draft                  agent-dir                  February 2026


       4.6.  Content Distribution via OCI Protocol . . . . . . . . . .  20
         4.6.1.  Peer-to-Peer Synchronization  . . . . . . . . . . . .  20
         4.6.2.  Distribution Strategies . . . . . . . . . . . . . . .  20
       4.7.  Agent Directory Record Examples . . . . . . . . . . . . .  23
       4.8.  Security Model  . . . . . . . . . . . . . . . . . . . . .  25
         4.8.1.  Cryptographic Integrity . . . . . . . . . . . . . . .  25
         4.8.2.  Content Provenance and Digital Signatures . . . . . .  26
         4.8.3.  Trust Boundaries and Isolation  . . . . . . . . . . .  27
         4.8.4.  Threat Mitigation . . . . . . . . . . . . . . . . . .  27
         4.8.5.  Access Control  . . . . . . . . . . . . . . . . . . .  28
         4.8.6.  Trust Boundaries  . . . . . . . . . . . . . . . . . .  28
       4.9.  Performance Optimizations . . . . . . . . . . . . . . . .  28
         4.9.1.  Bandwidth Optimization  . . . . . . . . . . . . . . .  28
         4.9.2.  Scalability Architecture  . . . . . . . . . . . . . .  28
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  30
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

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

  2.  Introduction

     Multi-Agent Systems (MAS) represent a new paradigm in distributed
     computing where software components leverage Large Language Models
     (LLMs) to perform specialized tasks and solve complex problems
     through collaborative intelligence.  These systems combine LLMs with
     contextual knowledge and tool-calling capabilities, often abstracted
     through Model Context Protocol (MCP) servers, enabling dynamic
     workflows that adapt based on stored state and environmental
     conditions.

     The diversity and complexity of MAS architectures present unique
     challenges for discovery and composition.  As the ecosystem of AI
     agents expands, developers need efficient mechanisms to:

     *  *Discover compatible agents* with specific skills and capabilities

     *  *Evaluate performance characteristics* including cost, latency,
        and resource requirements




  Muscariello & Polic      Expires 28 August 2026                 [Page 3]


  Internet-Draft                  agent-dir                  February 2026


     *  *Compose multi-agent workflows* by linking agents with
        complementary capabilities

     *  *Verify claims* about agent performance and reliability

     *  *Track versioning and dependencies* between agent components

     The Agent Directory Service (ADS) [AGNTCY-ADS] addresses these
     challenges by providing a distributed directory infrastructure
     specifically designed for the agentic AI ecosystem.  Rather than
     attempting to formally define MAS architectures, which would
     constrain the creative composition patterns emerging in this rapidly
     evolving field—ADS focuses on providing flexible metadata storage and
     discovery mechanisms.  A comparison among registries which can be
     centralized or distributed is reported here [AI-Registry-Evolution].

  2.1.  Core Capabilities

     ADS enables several key capabilities for the agentic AI ecosystem:

     *Capability-Based Discovery*: Agents publish structured metadata
     describing their functional abilities, costs, and performance
     characteristics.  The system organizes this information using
     hierarchical skill taxonomies, enabling efficient matching of
     capabilities to requirements.

     *Verifiable Claims*: While agent capabilities are often subjectively
     evaluated, ADS provides cryptographic mechanisms for data integrity
     and provenance tracking.  This allows users to make informed
     decisions about agent selection while enabling reputation systems to
     emerge organically.

     *Semantic Linkage*: Components can be securely linked to create
     various relationships like version histories for evolutionary
     development, collaborative partnerships where complementary skills
     solve complex problems, and dependency chains for composite agent
     workflows.

     *Distributed Architecture*: Built on proven distributed systems
     principles, ADS uses content-addressing for global uniqueness and
     implements distributed hash tables [DHT] for scalable content
     discovery across decentralized networks.









  Muscariello & Polic      Expires 28 August 2026                 [Page 4]


  Internet-Draft                  agent-dir                  February 2026


  2.2.  Architectural Foundation

     The system leverages the Open Agentic Schema Framework (OASF) to
     model agent information in a structured, extensible format.  OASF
     enables rich queries such as "What agents can solve problem A?" or
     "What combination of skills and costs optimizes for task B?"  This
     schema-driven approach supports both objective metrics (token
     consumption, GPU requirements) and subjective evaluations (user
     ratings, task completion quality).

     Agent records are organized using modular extensions—reusable
     components like MCP server definitions, prompt-based agents, and
     evaluation metrics.  This modular approach facilitates composition
     and reuse across different MAS architectures while maintaining
     flexibility for innovative use cases.

     The underlying storage layer integrates with OCI (Open Container
     Initiative) [OCI.Image] standards, enabling interoperability with
     existing container ecosystems and leveraging mature tooling for
     content distribution and verification.

     This document details the technical architecture of ADS, covering the
     record storage layer, security model, distributed data discovery
     mechanisms, and data distribution protocols between storage nodes.

  3.  Storage Architecture

     ADS implements a decentralized storage architecture built on OCI
     (Open Container Initiative) registries as the foundational object
     storage layer.  This design choice enables the system to leverage
     mature, standardized container registry infrastructure while
     achieving the speed, scalability, and security requirements of a
     distributed agent directory.

  3.1.  Content-Addressed Storage

     The storage architecture centers on globally unique Content
     Identifiers (CID) that provide several critical properties for a
     distributed agent directory:

     *Immutability*: Content identifiers are cryptographically derived
     from the data they represent, ensuring that any modification results
     in a different identifier.  This property is essential for
     maintaining data integrity in agent records and enabling verifiable
     claims about agent capabilities.






  Muscariello & Polic      Expires 28 August 2026                 [Page 5]


  Internet-Draft                  agent-dir                  February 2026


     *Deduplication*: Identical content automatically receives the same
     identifier across all nodes in the network, eliminating storage
     redundancy and reducing bandwidth requirements when the same agent
     components are referenced by multiple systems.

     *Verifiability*: Any node can independently verify that received
     content matches its identifier, providing built-in protection against
     data corruption or tampering during transmission.

     *Location Independence*: Content can be retrieved from any node that
     possesses it, as the identifier serves as a universal pointer that
     abstracts away physical storage locations.

  3.2.  OCI Integration

     ADS leverages OCI (Open Container Initiative) specifications for
     storing and distributing agent records as OCI artifacts, offering
     several advantages:

  3.2.1.  Standards Compliance

     By building on OCI specifications, ADS inherits compatibility with
     the extensive ecosystem of container registry tools, security
     scanners, and management platforms.  This includes:

     *  *Authentication and authorization* mechanisms already deployed in
        enterprise environments

     *  *Content signing and verification* through tools like Notary and
        cosign

     *  *Vulnerability scanning* capabilities that can be extended to
        agent security assessments

     *  *Content delivery networks* optimized for OCI artifact
        distribution

  3.3.  Record Artifact Specification

     ADS stores agent records as Record Artifacts following the OCI Image
     Manifest Specification [OCI.Manifest] and adhering to the OCI
     artifacts guidance [OCI.Artifact].  A Record Artifact is an AGNTCY
     OASF Record packaged as an OCI artifact.

  3.3.1.  Manifest Structure

     The manifest structure MUST include the following properties:




  Muscariello & Polic      Expires 28 August 2026                 [Page 6]


  Internet-Draft                  agent-dir                  February 2026


     *  mediaType string

        This REQUIRED property MUST be application/
        vnd.oci.image.manifest.v1+json.

     *  artifactType string

        This REQUIRED property MUST be application/
        vnd.agntcy.dir.record.v1+json.  Future versions of the Record
        Artifact Specification MAY define additional artifact types.

     *  config descriptor

        This REQUIRED property MUST reference an empty configuration with
        media type application/vnd.oci.empty.v1+json, indicating that no
        additional configuration data is needed for Record Artifacts.

     *  layers array of objects

        This REQUIRED property MUST contain one or more layer descriptors
        representing OASF Record components.

     *  subject descriptor

        This OPTIONAL property MAY reference another Record Artifact to
        create linkage between records for version histories.

  3.3.2.  Layer Structure

     Each layer descriptor MUST include the following properties:

     *  mediaType string

        This REQUIRED property specifies the layer content type.
        Implementations MUST support the following media types:

        -  application/vnd.agntcy.oasf.types.{version}.Record+json: The
           first layer (index 0) MUST use this media type and contains
           base record data.  This layer MUST use the data field for
           inline storage (base64-encoded) since the content is small,
           frequently accessed, and unique to each record.  Object
           annotations, schema_version and created_at are stored as part
           of layer annotations.

        -  application/vnd.agntcy.oasf.types.{version}.Skill+json:
           Contains skill definition data.  Object annotations, id and
           name are stored as part of layer annotations.




  Muscariello & Polic      Expires 28 August 2026                 [Page 7]


  Internet-Draft                  agent-dir                  February 2026


        -  application/vnd.agntcy.oasf.types.{version}.Domain+json:
           Contains domain definition data.  Object annotations, id and
           name are stored as part of layer annotations.

        -  application/vnd.agntcy.oasf.types.{version}.Locator+json:
           Contains locator definition data referencing the location where
           the agent can be accessed or deployed.  Object annotations,
           type and url are stored as part of layer annotations and URL
           fields.

        -  application/vnd.agntcy.oasf.types.{version}.Module+json:
           Contains module definition data.  Object annotations, id and
           name are stored as part of layer annotations.

        Media types MUST map to application/
        vnd.{schema_uri}.{version}.{type}+{encoding} format, where -
        {schema_uri} corresponds to the OASF protobuf schema namespace -
        {version} corresponds to a specific OASF type version (e.g.,
        v1alpha2) - {type} is the OASF type name (e.g. Record) -
        {encoding} MUST be json

     *  urls array of strings

        This OPTIONAL property MAY contain URLs pointing to external
        resources, particularly useful for Locator layers to specify
        deployment targets.

     *  annotations string-string map

        This OPTIONAL property contains arbitrary attributes.
        Implementations SHOULD use the predefined annotation keys:

        -  agntcy.oasf.record/schema_version: Schema version (for Record
           layers)

        -  agntcy.oasf.record/created_at: Creation timestamp (for Record
           layers)

        -  agntcy.oasf.locator/type: Locator type (for Locator layers)

        -  agntcy.oasf.skill/{id,name}: Skill id/name (for Skill layers)

        -  agntcy.oasf.domain/{id,name}: Domain id/name (for Domain
           layers)

        -  agntcy.oasf.module/{id,name}: Module id/name (for Module
           layers)




  Muscariello & Polic      Expires 28 August 2026                 [Page 8]


  Internet-Draft                  agent-dir                  February 2026


  3.3.3.  Example Record Artifacts

     {
       "schemaVersion": 2,
       "mediaType": "application/vnd.oci.image.manifest.v1+json",
       "artifactType": "application/vnd.agntcy.dir.record.v1+json",
       "config": {
         "mediaType": "application/vnd.oci.empty.v1+json",
         "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
         "size": 2
       },
       "layers": [
         {
           "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Record+json",
           "data": "<BASE64_ENCODED_RECORD_DATA>",
           "digest": "sha256:d5815835051dd97d800a03f641ed8162877920e734d3d705b698912602b8c763",
           "size": 216,
           "annotations": {
             "agntcy.oasf.record/schema_version": "0.7.0",
             "agntcy.oasf.record/created_at": "2026-01-06T00:00:00Z"
           }
         },
         {
           "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Skill+json",
           "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
           "size": 2,
           "annotations": {
             "agntcy.oasf.skill/id": "10201",
             "agntcy.oasf.skill/name": "Natural Language Processing/Sentiment Analysis"
           }
         },
         {
           "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Locator+json",
           "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
           "size": 2,
           "urls": [
             "https://ghcr.io/agntcy/agent:latest",
             "ipfs://bafybeibwzif37xyzabcdefg"
           ],
           "annotations": {
             "agntcy.oasf.locator/type": "docker-image"
           }
         }
       ],
       "subject": {
         "mediaType": "application/vnd.oci.image.manifest.v1+json",
         "artifactType": "application/vnd.agntcy.dir.record.v1+json",
         "digest": "sha256:7e346bc58473bc1d8a98776fa2a89a3e2a446b27f0e8a33ad49c3d4f28b6471d",



  Muscariello & Polic      Expires 28 August 2026                 [Page 9]


  Internet-Draft                  agent-dir                  February 2026


         "size": 702
       }
     }

  3.3.4.  Record Reconstruction

     Applications consuming Record Artifacts MUST implement the following
     reconstruction algorithm:

     1.  *Pull Manifest*: Retrieve the OCI image manifest from the
         registry using standard OCI Distribution API operations

     2.  *Extract Base Record*: Parse the first layer (index 0) with media
         type application/vnd.agntcy.oasf.types.{version}.Record+json and
         base64-decode the data field to obtain the base record JSON data

     3.  *Retrieve Component Layers*: For each subsequent layer (Skill,
         Domain, Locator, Module):

         *  Fetch the blob content from the registry using the layer's
            digest

         *  Verify the blob's SHA-256 digest matches the descriptor's
            digest field

         *  Parse the JSON content according to the layer's mediaType

         *  Merge the component data into the appropriate field of the
            base record

         *  Merge descriptor annotations into the corresponding component
            metadata

     4.  *Validate Schema*: Validate the reconstructed record against the
         OASF schema version specified in the agntcy.oasf.record/
         schema_version annotation

  3.4.  Application Integration

  3.4.1.  Open Agent Schema Framework (OASF)

     The Open Agent Schema Framework (OASF) [AGNTCY-OASF] complements
     Record Artifact Specification by defining the actual data models for
     agent-related information referenced in the OCI artifacts.







  Muscariello & Polic      Expires 28 August 2026                [Page 10]


  Internet-Draft                  agent-dir                  February 2026


  3.4.2.  Third-Party Applications

     Third-party applications can build on top of the Record Artifact
     Specification to create tools and services for managing,
     distributing, and utilizing agent records.  This can be accomplished
     by leveraging existing OCI ecosystem components such as registries,
     clients, and tooling, or by developing custom solutions that link to
     Record Artifacts.

  3.4.3.  Runtime Environments

     Runtime environments that deploy and manage agents can leverage
     Record Artifacts to obtain the necessary information for launching
     and managing agent instances based on the definitions contained
     within the artifacts.  Implementations can provide management of
     process lifecycles, monitoring, and other capabilities based on the
     metadata defined in the records, or by linking records with runtime-
     specific artifacts.

  3.5.  Artifact Organization

     Agent records are stored as OCI artifacts with a structured
     organization.  Records MUST be addressed by digest for immutable
     retrieval.  Tags are mutable aliases and can be used as human-
     readable pointers, but implementations MUST NOT assume a tag resolves
     to more than one manifest at a time.  The examples below show digest-
     pinned references:

     null_repo/records/
     ├── skills/
     │   ├── natural_language_processing/
     │   │   ├── sentiment-analysis:bert-v1@sha256:abc123...
     │   │   ├── sentiment-analysis:roberta-v1@sha256:def456...
     │   │   ├── sentiment-analysis:distilbert-v1@sha256:ghi789...
     │   │   ├── text-classification:bert-v2@sha256:abc123...
     │   │   └── emotion-detection:bert-v1@sha256:abc123...
     │   ├── images_computer_vision/
     │   │   ├── object-detection:yolo-v2.1@sha256:jkl012...
     │   │   ├── object-detection:rcnn-v2.1@sha256:mno345...
     │   │   └── scene-understanding:yolo-v1@sha256:jkl012...
     │   └── analytical_skills/
     │       └── mathematical:v1.5.0@sha256:pqr678...
     ├── evaluations/
     │   ├── performance-metrics:latest@sha256:stu901...
     │   └── benchmark-results:v1.0.0@sha256:vwx234...
     └── compositions/
         ├── security-analyst:v3.0.0@sha256:yza567...
         └── research-assistant:v2.2.0@sha256:bcd890...



  Muscariello & Polic      Expires 28 August 2026                [Page 11]


  Internet-Draft                  agent-dir                  February 2026


     This naming scheme demonstrates that the same content identifier can
     belong to multiple skills, reflecting the reality that many AI agents
     are multi-capable.  For example, the BERT-based agent
     (sha256:abc123...) appears under multiple skill categories:
     natural_language_processing/sentiment-analysis,
     natural_language_processing/text-classification, and
     natural_language_processing/emotion-detection, representing different
     capabilities of the same underlying agent implementation.  Similarly,
     the YOLO vision model (sha256:jkl012...) provides both object-
     detection and scene-understanding capabilities under
     images_computer_vision.

     This cross-referencing approach allows agents to be discovered
     through any of their supported capabilities while maintaining unique
     addressability through content identifiers.  Each skill category can
     have its own versioning and metadata, enabling fine-grained
     capability management even when multiple skills share the same
     underlying implementation.

     Each artifact contains structured metadata following OASF schemas,
     enabling rich queries and capability matching across all variants
     within a given category.

  3.5.1.  Multi-Registry Federation

     The architecture supports federation across multiple registry
     instances, enabling:

     *  *Organizational boundaries*: Different organizations can maintain
        their own registries while participating in the global directory

     *  *Geographic distribution*: Content can be replicated to registries
        closer to consumers, reducing latency

     *  *Specialization*: Registries can focus on specific domains (e.g.,
        medical AI agents, financial analysis tools)

     *  *Redundancy*: Critical agent records can be replicated across
        multiple registries for availability

  4.  MAS Data Discovery

     ADS implements a two-level mapping system that enables efficient
     discovery of Multi-Agent System components through a distributed hash
     table [DHT] architecture.  This approach separates capability-based
     discovery from content location, providing both scalability and
     flexibility in agent retrieval.




  Muscariello & Polic      Expires 28 August 2026                [Page 12]


  Internet-Draft                  agent-dir                  February 2026


  4.1.  Skill Taxonomy

     Effective agent discovery in multi-agent systems requires
     sophisticated organization of capabilities and skills.  ADS employs a
     hierarchical skill taxonomy that serves as the foundation for
     efficient search and discovery operations across the distributed
     network.

  4.1.1.  The Challenge of Capability Search

     Traditional keyword-based search approaches face significant
     limitations when applied to agent discovery:

     *Vocabulary Fragmentation*: Different publishers may describe similar
     capabilities using varying terminology.  For example, "sentiment
     analysis," "opinion mining," and "emotional classification" may all
     refer to similar agent capabilities, leading to search results that
     miss relevant agents due to terminology mismatches.

     *Scale Complexity*: As the number of agents in the ecosystem grows,
     exhaustive search across all records becomes computationally
     prohibitive.  Without structured organization, every query
     potentially requires examining every agent record, leading to poor
     performance characteristics.

     *Semantic Relationships*: Many agent capabilities have natural
     hierarchical relationships that flat keyword systems cannot capture.
     An agent capable of "named entity recognition" is inherently relevant
     to searches for broader "text analysis" capabilities, but keyword
     matching alone cannot establish these connections.

  4.1.2.  Taxonomy-Driven Search Optimization

     ADS addresses these challenges through a structured hierarchical
     taxonomy that provides several critical optimization benefits:

     *Search Space Partitioning*: The taxonomy enables efficient
     partitioning of the search space.  When processing a query for
     "computer vision" capabilities, the system can immediately focus on
     the relevant taxonomy branch, eliminating the need to examine agents
     in unrelated categories like natural language processing or
     mathematical reasoning.

     *Index Structure Optimization*: The hierarchical organization allows
     the distributed hash table to create specialized indices for
     different taxonomy branches.  Rather than maintaining a single
     massive index, the DHT can distribute indexing responsibility across
     nodes, with each node specializing in specific capability domains.



  Muscariello & Polic      Expires 28 August 2026                [Page 13]


  Internet-Draft                  agent-dir                  February 2026


     *Query Semantic Expansion*: The taxonomy enables intelligent query
     expansion where searches automatically include semantically related
     subcategories.  A search for "text analysis" can transparently
     include results from "sentiment analysis," "entity extraction," and
     "text classification" without requiring users to explicitly enumerate
     all relevant subcategories.

     *Standardized Vocabulary*: By providing a canonical taxonomy, ADS
     reduces terminology fragmentation.  Publishers are encouraged to tag
     their agents using standardized skill categories, improving search
     precision and recall across the ecosystem.

  4.2.  Two-Level Mapping Architecture

     The discovery system operates through two distinct mapping layers:

  4.3.  Skill Taxonomy for Search Optimization

     ADS employs a hierarchical skill taxonomy to optimize search
     performance and enable efficient capability-based discovery.
     Taxonomies provide several critical advantages for agent discovery
     systems:

     *Search Space Reduction*: Rather than performing exhaustive searches
     across all agent records, taxonomies allow the system to quickly
     narrow the search space to relevant categories.  When a user queries
     for "natural language processing" capabilities, the system can
     immediately identify the subset of agents tagged with NLP skills
     without examining agents focused on computer vision or mathematical
     reasoning.

     *Hierarchical Organization*: Skills are organized in a tree-like
     structure *that reflects natural relationships between capabilities.
     For example:

     Natural Language Processing
     ├── Text Analysis
     │   ├── Sentiment Analysis
     │   ├── Named Entity Recognition
     │   └── Text Classification
     ├── Language Generation
     │   ├── Text Summarization
     │   ├── Content Creation
     │   └── Translation
     └── Conversational AI
         ├── Dialogue Management
         ├── Intent Recognition
         └── Response Generation



  Muscariello & Polic      Expires 28 August 2026                [Page 14]


  Internet-Draft                  agent-dir                  February 2026


     This hierarchy enables both specific queries ("sentiment analysis
     agents") and broader capability searches ("all natural language
     processing agents") while maintaining efficient indexing structures.

     *Query Expansion and Refinement*: Taxonomies support automatic query
     expansion *where searches for parent categories can include relevant
     child categories.  A *query for "text analysis" can automatically
     include agents tagged with *"sentiment analysis," "named entity
     recognition," and "text classification" *without requiring users to
     know all specific subcategories.

     *Semantic Consistency*: Standardized taxonomies reduce ambiguity and
     improve *search precision by providing consistent terminology across
     the ecosystem.  This *prevents fragmentation where similar
     capabilities are described using different *terms by different
     publishers.

     *Scalable Indexing*: The hierarchical structure enables efficient
     distributed *indexing where different DHT nodes can specialize in
     specific taxonomy *branches, distributing both storage load and query
     processing across the *network.

  4.4.  Additional Taxonomies

     While skills form the primary taxonomy for capability-based
     discovery, ADS supports multiple parallel taxonomies to enable rich,
     multi-dimensional agent classification and search.

  4.4.1.  Domain Taxonomy

     The domain taxonomy organizes agents by their application domains,
     representing the broader problem spaces or industries where agents
     are designed to operate:


















  Muscariello & Polic      Expires 28 August 2026                [Page 15]


  Internet-Draft                  agent-dir                  February 2026


     Application Domains
     ├── Networking
     │   ├── Network Configuration
     │   ├── Traffic Analysis
     │   └── Protocol Implementation
     ├── Security
     │   ├── Threat Detection
     │   ├── Vulnerability Assessment
     │   └── Access Control
     ├── Software Development
     │   ├── Code Generation
     │   ├── Testing Automation
     │   └── Documentation
     ├── Finance and Business
     │   ├── Risk Analysis
     │   ├── Market Research
     │   └── Process Automation
     └── Healthcare
         ├── Medical Imaging
         ├── Clinical Decision Support
         └── Drug Discovery

     Domain classification enables users to discover agents that are
     specifically tuned for their operational context, even if those
     agents share similar underlying skills with agents from other
     domains.

  4.4.2.  Module Taxonomy

     The module taxonomy categorizes agents by the OASF modules they
     implement, facilitating the discovery of agents compatible with
     specific system architectures.  Modules are organized into the OASF
     module categories (Core and Integration), and each module captures a
     structured integration surface or capability extension:

     The Agent Spec module aligns with the Open Agent Spec specification
     [Oracle-AgentSpec].

     Modules
     ├── Core
     │   ├── Language Model (`language_model`)
     │   ├── Evaluation (`evaluation`)
     │   └── Observability (`observability`)
     └── Integration
       ├── MCP (Model Context Protocol, `mcp`)
       ├── A2A (Agent-to-Agent Communication, `a2a`)
       ├── Agent Spec (`agentspec`)
       └── ACP (`acp`, deprecated)



  Muscariello & Polic      Expires 28 August 2026                [Page 16]


  Internet-Draft                  agent-dir                  February 2026


     Module identifiers use the OASF module name values.  The acp module
     is deprecated in OASF; use a2a when possible.

  4.4.3.  Multi-Dimensional Search

     The parallel taxonomy system enables sophisticated multi-dimensional
     queries that combine criteria across different classification axes.
     *All searches must include at least one skill criterion as the
     mandatory foundation*, with domain and module taxonomies providing
     additional filtering dimensions:

     *  *Skill + Domain*: "Find natural language processing agents
        specialized for healthcare applications"

     *  *Skill + Module*: "Discover computer vision agents that support
        MCP integration"

     *  *Skill + Module + Domain*: "Locate natural language processing
        agents with observability modules for manufacturing applications"

     *Skills as Search Foundation*: The skills taxonomy serves as the
     primary index structure in the DHT, making skill-based criteria
     mandatory for efficient query resolution.  This design ensures that:

     *  *Query Performance*: All searches leverage the optimized skills-
        to-CID mapping as the starting point, providing consistent
        performance characteristics

     *  *Result Relevance*: Domain and module filters are applied to
        skill-based result sets, ensuring functional capability remains
        the core selection criterion

     *  *Index Efficiency*: The DHT can optimize storage and lookup
        patterns around the skills taxonomy while supporting supplementary
        filtering through domains and modules

     Domain-only or module-only queries are not supported, as they would
     bypass the primary indexing structure and provide results that may
     not have the functional capabilities required by the requesting
     system.

     This multi-taxonomic approach provides the flexibility to support
     diverse use cases while maintaining efficient indexing and search
     performance across all dimensions.







  Muscariello & Polic      Expires 28 August 2026                [Page 17]


  Internet-Draft                  agent-dir                  February 2026


  4.4.4.  Skills-to-CID Mapping

     The first level maps agent capabilities and skills to their
     corresponding Content Identifiers (CID):

  Skills Index:
  "natural_language_processing" → ["sha256:abc123...", "sha256:def456...", "sha256:ghi789..."]
  "images_computer_vision"      → ["sha256:jkl012...", "sha256:mno345..."]
  "analytical_skills"           → ["sha256:pqr678...", "sha256:abc123..."]
  "multi_modal"                 → ["sha256:stu901...", "sha256:vwx234..."]

     This mapping enables queries such as "find all agents capable of
     natural language processing" to quickly resolve to a set of content
     identifiers without needing to search through individual agent
     records.

  4.4.5.  CID-to-PeerID Mapping

     The second level maps Content Identifiers to the Peer IDs of nodes
     that store the corresponding agent records:

  Content Location Index:
  "sha256:abc123..." → ["12D3KooWBhvxmvKvTYGJvXjnGBp7Ybr9WyoXkZvFnRtC4aBcDeFg",
                        "12D3KooWXyZrUvHzPqKvTYGJvXjnGBp7Ybr9WyoXkZvFnRtC5gHi"]
  "sha256:jkl012..." → ["12D3KooWZaBcDeFgXyZrUvHzPqKvTYGJvXjnGBp7Ybr9WyoXkZvF",
                        "12D3KooWGHiJkLmNoPqRsTuVwXyZ123456789AbCdEfGhIjKlMnO"]

     This separation allows the system to: - *Optimize for capability
     queries* without requiring knowledge of data locations

     *  *Enable dynamic content replication* as peer availability changes

     *  *Support multiple storage strategies* for the same content across
        different peers

  4.5.  DHT-Based Discovery Process

     The Distributed Hash Table stores and maintains both mapping layers
     across the network:

     ADS uses [Kad-DHT] [DHT] for server and content discovery by using
     the libp2p implementation that constitutes the IPFS core DHT
     [libp2p-kad-dht].








  Muscariello & Polic      Expires 28 August 2026                [Page 18]


  Internet-Draft                  agent-dir                  February 2026


                                  +----------------+
                                  |    DHT Node    |
                                  | Content Index  |
                                  +----------------+
                                         ^
                                         |
                        +----------------+-----------------+
                        |                |                |
                +-------v------+  +------v-------+  +-----v--------+
                | Server Node A |  | Server Node B|  | Server Node C|
                |   Content X  |  |   Content Y  |  |   Content Z  |
                +-------+------+  +------+-------+  +------+-------+
                        |               |                  |
                        |        Content Exchange          |
                        +---------------+------------------+
                                       |
                               Content Replication

     Flow:
     1. Servers register content with DHT
     2. DHT maintains content-to-server mappings
     3. Servers query DHT to locate content
     4. DHT returns list of servers hosting content
     5. Servers download content from peers

  4.5.1.  Skill Registration

     When agents are published to the network:

     1.  *Capability Extraction*: The system parses OASF records to
         extract skills, domains, and modules

     2.  *DHT Updates*: Skills-to-CID mappings are distributed across DHT
         nodes using consistent hashing

     3.  *Location Registration*: Peer nodes register themselves as
         providers for specific CIDs

  4.5.2.  Discovery Query Resolution

     Agent discovery follows a three-phase process:

     1.  *Capability Resolution*: Query "agents with skill X" resolves to
         a list of relevant CIDs via DHT lookup

     2.  *Location Resolution*: For each discovered CID, query DHT to find
         peer nodes storing the content




  Muscariello & Polic      Expires 28 August 2026                [Page 19]


  Internet-Draft                  agent-dir                  February 2026


     3.  *Result Aggregation*: Combine capability matches with location
         information to produce actionable discovery results

  Discovery Flow:
  Query: "natural_language_processing" AND "finance_and_banking"
     ↓
  Phase 1: Skills → CIDs
     DHT["natural_language_processing"] → ["sha256:abc123...", "sha256:def456..."]
     DHT["finance_and_banking"] → ["sha256:abc123...", "sha256:yza567..."]
     Intersection → ["sha256:abc123..."]
     ↓
  Phase 2: CIDs → Peer IDs
     DHT["sha256:abc123..."] → ["12D3KooW...", "12D3KooX..."]
     ↓
  Result: Agent sha256:abc123... available from peers 12D3KooW... and 12D3KooX...

  4.5.3.  Additional Tanomoxies

  4.6.  Content Distribution via OCI Protocol

     Once discovery identifies the relevant CIDs and their hosting peers,
     the actual agent records are retrieved using the OCI distribution
     protocol:

  4.6.1.  Peer-to-Peer Synchronization

     The discovered list of CIDs enables efficient content synchronization
     [OCI.Distribution] between peers:

     1.  *Content Negotiation*: Requesting peer queries hosting peers for
         available agent records

     2.  *OCI Pull Operations*: Standard OCI registry pull commands
         retrieve agent artifacts and metadata

     3.  *Incremental Sync*: Only missing or updated content is
         transferred, reducing bandwidth requirements

     4.  *Verification*: Content integrity is verified through
         cryptographic hash validation during transfer

  4.6.2.  Distribution Strategies

     The system supports multiple distribution patterns, each with
     distinct trade-offs and operational considerations:

     *On-Demand Retrieval*: Records are pulled from remote peers only when
     specifically requested, minimizing local storage requirements.



  Muscariello & Polic      Expires 28 August 2026                [Page 20]


  Internet-Draft                  agent-dir                  February 2026


     _Trade-offs_: While this approach minimizes storage costs and ensures
     fresh content, it introduces several challenges:

     *  *Query Latency*: Each request requires network round-trips to
        locate and retrieve content, increasing response times

     *  *Network Cost*: Spurious or exploratory requests generate
        unnecessary network traffic and computational overhead

     *  *DoS Vulnerability*: The system becomes susceptible to denial-of-
        service attacks where malicious actors can trigger expensive
        content retrieval operations by flooding the network with requests
        for non-existent or rarely-accessed agents

     *  *Scalability Limits*: Performance degrades as the network grows
        due to increased query coordination overhead

     *Proactive Caching*: Popular or frequently accessed agents are
     automatically replicated to improve query response times.

     _Trade-offs_: This strategy offers significant scalability benefits
     but requires sophisticated management:

     *  *Performance Gains*: Dramatic reduction in query latency for
        popular content, enabling sub-second response times

     *  *Scalability*: Can handle high query volumes efficiently once
        popular content is cached locally

     *  *Popularity Measurement*: Requires implementing metrics collection
        and analysis to identify which agents warrant caching.  This
        includes tracking query frequencies, download patterns, and usage
        statistics across the network

     *  *Storage Requirements*: Needs sufficient local storage capacity to
        maintain cached copies of popular records

     *  *Cache Management*: Must implement cache eviction policies,
        freshness validation, and synchronization mechanisms

     *  *Administrator Oversight*: Proactive caching policies must be
        configured and monitored by agent directory node administrators to
        balance storage costs with performance benefits

     *Strategic Replication*: Critical agents can be replicated across
     multiple peers to ensure high availability and reduce single points
     of failure.




  Muscariello & Polic      Expires 28 August 2026                [Page 21]


  Internet-Draft                  agent-dir                  February 2026


     _Trade-offs_: This approach addresses availability concerns but
     introduces subjective complexity:

     *  *High Availability*: Ensures critical agents remain accessible
        even during peer failures or network partitions

     *  *Reduced Single Points of Failure*: Distributes risk across
        multiple storage locations

     *  *Subjective Criticality*: The definition of "critical" or "useful"
        agents varies significantly between users, organizations, and use
        cases.  What constitutes strategic value for financial services
        may be irrelevant for manufacturing applications

     *  *Administrative Burden*: Requires agent directory node
        administrators to make strategic decisions about which agents
        warrant replication, considering factors like:

        -  Organizational priorities and business requirements

        -  Compliance and regulatory considerations

        -  Cost-benefit analysis of storage versus availability

        -  Community consensus on agent importance

     *  *Resource Allocation*: Strategic replication consumes storage
        resources that could otherwise be used for proactive caching of
        popular content

     *Administrative Management*: Both Proactive Caching and Strategic
     Replication require active management by agent directory node
     administrators.  Administrators must:

     *  Configure caching policies based on local network characteristics
        and storage capacity

     *  Monitor popularity metrics and adjust caching strategies
        accordingly

     *  Define strategic replication criteria aligned with organizational
        objectives

     *  Balance resource allocation between different distribution
        strategies

     *  Implement governance policies for content lifecycle management




  Muscariello & Polic      Expires 28 August 2026                [Page 22]


  Internet-Draft                  agent-dir                  February 2026


     This architecture provides a scalable foundation for MAS data
     discovery that can efficiently handle large networks of distributed
     agents while maintaining low latency for capability-based queries.

  4.7.  Agent Directory Record Examples

     The following examples illustrate the structure of OASF-compliant
     agent records stored in the directory:

  {
    "content_id": "sha256:abc123...",
    "record": {
      "name": "BERT Sentiment Analyzer",
      "version": "1.0.0",
      "schema_version": "0.2.0",
      "description": "Multi-capability NLP agent providing sentiment analysis, text classification, and emotion detection",
      "skills": ["natural_language_processing"],
      "domains": ["finance_and_banking", "legal_and_compliance"],
      "modules": ["mcp", "observability"],
      "capabilities": {
        "threads": true,
        "interrupt_support": false,
        "callbacks": true,
        "streaming": ["text", "json"]
      }
    },
    "performance_metrics": {
      "tokens_per_second": 1000,
      "gpu_memory_mb": 4096,
      "latency_p99_ms": 150,
      "accuracy_score": 0.94
    },
    "evaluation_data": {
      "overall_rating": 4.2,
      "cost_per_million_tokens": 2.50
    },
    "registries": [
      "registry.example.com",
      "hub.agents.org"
    ],
    "last_updated": "2025-08-07T10:30:00Z"
  }









  Muscariello & Polic      Expires 28 August 2026                [Page 23]


  Internet-Draft                  agent-dir                  February 2026


  {
    "content_id": "sha256:jkl012...",
    "record": {
      "name": "YOLO Vision Agent",
      "version": "2.1.0",
      "schema_version": "0.2.0",
      "description": "Computer vision agent for object detection and scene understanding",
      "skills": ["images_computer_vision"],
      "domains": ["transportation_logistics_mobility", "manufacturing_and_industrial_operations"],
      "modules": ["agentspec", "observability"],
      "capabilities": {
        "threads": false,
        "interrupt_support": true,
        "callbacks": false,
        "streaming": ["image", "json"]
      }
    },
    "performance_metrics": {
      "inference_fps": 30,
      "gpu_memory_mb": 8192,
      "detection_accuracy_map": 0.89,
      "processing_latency_ms": 33
    },
    "evaluation_data": {
      "overall_rating": 4.7,
      "cost_per_image": 0.05
    },
    "registries": [
      "vision.agents.com",
      "registry.example.com"
    ],
    "last_updated": "2025-08-07T14:20:00Z"
  }


















  Muscariello & Polic      Expires 28 August 2026                [Page 24]


  Internet-Draft                  agent-dir                  February 2026


  {
    "content_id": "sha256:pqr678...",
    "record": {
      "name": "Mathematical Reasoning Agent",
      "version": "1.5.0",
      "schema_version": "0.2.0",
      "description": "Agent specialized in mathematical problem solving and analytical reasoning",
      "skills": ["analytical_skills", "natural_language_processing"],
      "domains": ["education", "finance_and_banking"],
      "modules": ["a2a", "evaluation"],
      "capabilities": {
        "threads": true,
        "interrupt_support": true,
        "callbacks": true,
        "streaming": ["text", "latex"]
      }
    },
    "performance_metrics": {
      "problems_per_minute": 12,
      "cpu_cores": 4,
      "memory_mb": 2048,
      "accuracy_on_gsm8k": 0.87
    },
    "evaluation_data": {
      "overall_rating": 4.5,
      "cost_per_problem": 0.10
    },
    "registries": [
      "math.agents.edu",
      "registry.example.com"
    ],
    "last_updated": "2025-08-07T16:45:00Z"
  }

     These examples demonstrate how the DHT indexing system extracts
     skills and domains from agent records to populate the Skills-to-CID
     mappings, enabling efficient capability-based discovery across the
     distributed network.

  4.8.  Security Model

     The OCI-based architecture provides multiple layers of security that
     address the unique challenges of distributed agent directories:

  4.8.1.  Cryptographic Integrity

     ADS leverages the OCI layer's built-in cryptographic mechanisms to
     ensure data integrity:



  Muscariello & Polic      Expires 28 August 2026                [Page 25]


  Internet-Draft                  agent-dir                  February 2026


     *Automatic Hash Computation*: The OCI registry layer automatically
     computes SHA-256 hash digests for all stored artifacts.  These
     content identifiers are generated transparently during the push
     operation, ensuring that every agent record has a cryptographically
     verifiable fingerprint without additional overhead.

     *Tamper Detection*: Content addressing ensures immediate tamper
     detection through cryptographic hash verification.  Any modification
     to an agent record—whether malicious or accidental—results in a
     different hash digest, making unauthorized changes immediately
     detectable during retrieval operations.

     *End-to-End Verification*: Clients can independently verify that
     received content matches its advertised identifier, providing built-
     in protection against data corruption during transmission or storage
     without trusting intermediate network components.

  4.8.2.  Content Provenance and Digital Signatures

     ADS integrates with Sigstore, a security framework for OCI storage,
     to provide comprehensive content provenance and authenticity
     guarantees:

     *Sigstore Integration*: The system leverages Sigstore's security
     framework to provide verifiable proof of when and by whom agent
     records were signed.  This creates an immutable audit trail that
     cannot be retroactively modified, enabling forensic analysis of agent
     deployment history.

     *Keyless Signing*: Sigstore's keyless signing approach eliminates the
     complexity and security risks associated with long-lived
     cryptographic keys:

     *  *Identity-Based Authentication*: Uses OpenID Connect (OIDC)
        [OpenID.Auth] tokens from trusted identity providers (GitHub,
        Google, Microsoft) to authenticate publishers at signing time

     *  *Short-Lived Certificates*: Issues ephemeral signing certificates
        valid only for minutes, reducing the window of potential key
        compromise

     *  *Automatic Key Rotation*: Eliminates the need for manual key
        management, distribution, and rotation procedures

     *  *Scalable Trust*: Publishers don't need to maintain or distribute
        public keys, making the system accessible to individual developers
        and large organizations alike




  Muscariello & Polic      Expires 28 August 2026                [Page 26]


  Internet-Draft                  agent-dir                  February 2026


     *Transparency and Verification*: All signatures are stored directly
     in OCI storage alongside the agent artifacts and public keys,
     providing:

     *  *Public Auditability*: Anyone can verify the signing history of
        agent records stored in accessible registries

     *  *Non-Repudiation*: Publishers cannot deny having signed records
        that are cryptographically linked to their identity

     *  *Supply Chain Security*: Enables detection of compromised or
        unauthorized agent publications

  4.8.3.  Trust Boundaries and Isolation

     *Organizational Isolation*: Separate registries maintain security
     boundaries between different organizations, allowing each entity to
     control their own agent ecosystem while still participating in the
     broader federated network.

     *Content Verification*: Nodes can validate artifact integrity and
     signature authenticity without trusting transport layers or
     intermediate storage systems.  This zero-trust approach ensures
     security even when using untrusted storage infrastructure.

     *Reputation Systems*: The cryptographic foundation enables the
     development of reputation systems based on verifiable evidence rather
     than subjective claims.  Publishers with consistent signing practices
     and high-quality agents can build measurable trust over time.

  4.8.4.  Threat Mitigation

     The security model addresses several key threats to distributed agent
     directories:

     *Supply Chain Attacks*: Sigstore integration and transparency logs
     make it difficult for attackers to inject malicious agents without
     detection, as all publications are cryptographically signed and
     publicly auditable.

     *Data Integrity Attacks*: Automatic hash verification prevents
     tampering with agent records during storage or transmission, ensuring
     users receive authentic content.

     *Identity Spoofing*: OIDC-based keyless signing prevents attackers
     from impersonating legitimate publishers without compromising their
     identity provider credentials.




  Muscariello & Polic      Expires 28 August 2026                [Page 27]


  Internet-Draft                  agent-dir                  February 2026


     *Availability Attacks*: The distributed nature of the system,
     combined with content replication across multiple registries,
     provides resilience against denial-of-service attacks targeting
     individual nodes.

  4.8.5.  Access Control

     *  *Registry-level permissions* control who can publish and retrieve
        agent records

     *  *Fine-grained policies* can restrict access to specific agent
        categories or capability types

     *  *Audit trails* leverage existing registry logging capabilities to
        track access patterns

  4.8.6.  Trust Boundaries

     *  *Organizational isolation* through separate registries maintains
        security boundaries

     *  *Content verification* allows nodes to validate artifact integrity
        without trusting transport layers

     *  *Reputation systems* can build on cryptographic proofs of past
        agent performance

  4.9.  Performance Optimizations

     The architecture incorporates several optimizations for the specific
     requirements of agent discovery:

  4.9.1.  Bandwidth Optimization

     *  *Incremental updates* use OCI layer semantics to transmit only
        changed portions of agent records

     *  *Content compression* reduces storage and transmission costs for
        large agent definitions

     *  *Selective replication* based on query patterns minimizes
        unnecessary data transfer

  4.9.2.  Scalability Architecture

     The system scales horizontally through several mechanisms:





  Muscariello & Polic      Expires 28 August 2026                [Page 28]


  Internet-Draft                  agent-dir                  February 2026


     *  *Registry sharding* distributes storage load across multiple OCI
        registry instances

     *  *Index partitioning* in the DHT allows query load to scale with
        the number of participating nodes

     *  *Lazy loading* defers retrieval of detailed agent specifications
        until actually needed

     This architecture provides a robust foundation for a decentralized
     agent directory that can scale to support the growing ecosystem of AI
     agents while maintaining the security and reliability requirements of
     production systems.

  5.  IANA Considerations

     This document has no IANA actions.

  6.  References

  6.1.  Normative References

     [AGNTCY-OASF]
                Community, A., "Open Agent Schema Framework (OASF)", n.d.,
                <https://github.com/agntcy/oasf>.

     [OCI.Artifact]
                Initiative, O. C., "OCI Artifacts Guidance Specification",
                n.d., <https://github.com/opencontainers/image-
                spec/blob/v1.1.1/artifacts-guidance.md>.

     [OCI.Distribution]
                Initiative, O. C., "OCI Distribution Specification", n.d.,
                <https://github.com/opencontainers/distribution-spec>.

     [OCI.Image]
                Initiative, O. C., "OCI Image Format Specification", n.d.,
                <https://github.com/opencontainers/image-spec>.

     [OCI.Manifest]
                Initiative, O. C., "OCI Image Manifest Specification",
                n.d., <https://github.com/opencontainers/image-
                spec/blob/v1.1.1/manifest.md>.

     [OpenID.Auth]
                Foundation, O., "OpenID Authentication 2.0 - Final", n.d.,
                <https://openid.net/specs/openid-authentication-2_0.txt>.




  Muscariello & Polic      Expires 28 August 2026                [Page 29]


  Internet-Draft                  agent-dir                  February 2026


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

     [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
                Keranen, A., and P. Hallam-Baker, "Naming Things with
                Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6920>.

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

  6.2.  Informative References

     [AGNTCY-ADS]
                Muscariello, L., Pandey, V., and R. Polic, "The AGNTCY
                Agent Directory Service: Architecture and Implementation",
                2025, <https://arxiv.org/abs/2509.18787>.

     [AI-Registry-Evolution]
                Singh, A., Ehtesham, A., Lambe, M., Grogan, J. J., Singh,
                A., Kumar, S., Muscariello, L., Pandey, V., Sauvage De
                Saint Marc, G., Chari, P., and R. Raskar, "Evolution of AI
                Agent Registry Solutions: Centralized, Enterprise, and
                Distributed Approaches", 2025,
                <https://arxiv.org/abs/2508.03095>.

     [DHT]      Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer
                information system based on the xor metric", IPTPS '01 ,
                2001.

     [libp2p-kad-dht]
                Community, libp2p., "go-libp2p-kad-dht: A Kademlia DHT
                implementation on go-libp2p", n.d.,
                <https://github.com/libp2p/go-libp2p-kad-dht>.

     [Oracle-AgentSpec]
                Oracle, "Open Agent Spec Documentation", n.d.,
                <https://oracle.github.io/agent-spec/index.html>.

     [Sigstore] Foundation, C. N. C., "Sigstore: A New Standard for
                Signing, Verifying and Protecting Software", n.d.,
                <https://www.sigstore.dev>.

  Authors' Addresses




  Muscariello & Polic      Expires 28 August 2026                [Page 30]


  Internet-Draft                  agent-dir                  February 2026


     Luca Muscariello
     Cisco
     Email: lumuscar@cisco.com


     Ramiz Polic
     Cisco
     Email: rpolic@cisco.com











































  Muscariello & Polic      Expires 28 August 2026                [Page 31]


name: draft-steckbeck-ua-conn-sec
rev: 00
title: User Agent Connection Security
time: 2025-08-17T09:07:18Z
group_uri: /api/v1/group/group/1027/
expires: 2023-09-13T21:29:23Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/75/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578733+00:00
source: ietf
abstract:
  The user agent to server transaction has many attack surfaces which
     have been defended by various recommendations such as Content
     Security Policy. An attack vector that is currently exploited is the
     open connection policy to first, second- and third-party resources.
     A breach of the origin website or other connected resource could
     require the client to load resources from a malicious network. This
     document provides a framework which allows authors to publish
     authorized connectable second- and third-party resources that a user
     agent should or must follow depending on configuration of that user
     agent.

full_text:
  ﻿

  Network Working Group                                       D. Steckbeck
  Internet-Draft                                                      
  Intended Status: Standards Track
  Category: Experimental                                        March 2023



                      User Agent Connection Security
                    draft-steckbeck-ua-conn-sec-00.txt

  Abstract

     The user agent to server transaction has many attack surfaces which
     have been defended by various recommendations such as Content 
     Security Policy. An attack vector that is currently exploited is the 
     open connection policy to first, second- and third-party resources.
     A breach of the origin website or other connected resource could 
     require the client to load resources from a malicious network. This 
     document provides a framework which allows authors to publish 
     authorized connectable second- and third-party resources that a user 
     agent should or must follow depending on configuration of that user 
     agent.

  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), its areas, and its working groups.  Note that 
     other groups may also distribute working documents as 
     Internet-Drafts.

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

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

     This Internet-Draft will expire on September 13 2023.

  Copyright Notice

     Copyright (c) 2023 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
        1.1  Terminology
        1.2  Applicability
     2  Conventions used in this document
        2.1  DNS Entries published
           2.1.1  Single site and domain example
           2.1.2  Multiple sites and domain example
           2.1.3  Wildcards
     3  Security Considerations
     4  IANA Considerations
     5  References
        5.1  Normative References
     6  Acknowledgments


  1  Introduction

     The traditional website model for distributing information has been 
     one of open resource connections. Website authors are in control as
     to how the published resource connections draw upon other resources.

     This model leaves end-users and administrators who require higher
     connection security to either trust the site author implicitly or 
     profile a website and provide connection security through other 
     means.

     Establishing a trust model where all connections are approved by both
     parties, is an additional step in providing a model where users and
     administrators can be assured the website they are using is making
     author-verified connections to second- and third-parties.

     This document covers an implementation for website authors to
     indicate a validation method of second- and third-party resources 
     and a strict or compatible model for browser owners to enforce 
     depending on their security requirements.

  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.

     The term "researcher" corresponds to the terms "finder" and
     "reporter" in [ISO.29147.2018] and [CERT.CVD].  The term
     "organization" corresponds to the term "vendor" in [ISO.29147.2018]
     and [CERT.CVD].

  1.2 Applicability

     This document covers a method of actions user-agents and website
     authors should implement to enhance security. 

  2  Conventions used in this document

     First-party connections are those created to the same host listed
     in the URL.

     Second-party connections are those created to other hosts using the
     same top level domain.

     Third-party connections are those to a host with a different host
     listed in the URL.

  2.1 DNS Entries published

     The DNS entry is a TXT record which was proposed in [RFC1464]. The
     format of the record begins with uacs=1; and an optional host= 
     identifier, if the domain serves multiple hostnames which require
     user-agent connection security. 

     Every semi-colon separated entry after it must be a [RFC1123]
     and [RFC4343] formatted host identifier.

     Length

  2.1.1 Single site and domain example

     An example record for a single website hosted from a domain:

     uacs=1;host.example1.com;*.example2.com;zzz.example-cloud-network.net

  2.1.2 Multiple sites and domain example

     If a domain serves multiple websites requiring user-agent connection
     security, these records MUST be broken up into separate TXT records
     with an identifying host tag:

     uacs=1;host=website1.example.com;host.example1.com;*.example2.com
     uacs=1;host=website2.example.com;host.example1.com;*.example2.com

     Hostname entries are separated by semicolons and no spaces. Where
     characters have case representations, all characters should be in
     lower case versions.

  2.1.3 Wildcards

     Wildcards are allowed to reduce record sizes and client processing
     time, for example a website hosted at example1.com can include
     resources from *.example2.com in order to accommodate changes
     example2.com may publish to their service.

     The wildcard MUST be interpreted as meaning 0 or more characters. 

     Caution should be used when using wildcards with services that
     publish random hostnames for customers since site authors may not
     intend for data from other customers to be referenced. For example,
     a content distribution network may create content access URIs such
     as 123456.example.net for every customer. A wildcard against this
     network would grant resource load opportunities for any non-related
     customers of that service.

     Only one uacs= and one host= are allowed per TXT record.

  2.2 User-Agent Requests

     User-Agents SHOULD include the TXT record request at the time of the
     DNS request to resolve the host name, should subsequently send the
     request to retrieve the uacs= TXT record prior to processing any
     further connection requests other than the initial resource request.

  2.3 Caching

     User-Agents SHOULD follow their normal caching rules for the TXT
     records request.

  2.4 User-Agent Enforcement Modes

     Compatible, Compliant, Strict

  2.4.1 Compatible mode

     Compatible mode is included as a transition option. This mode
     indicates the user-agent SHOULD NOT enforce any uacs entries.

  2.4.2 Compliant mode

     Compliant mode indicates the user-agent MUST process and follow the
     rules identified by a website author.

  2.4.3 Strict mode

     Strict mode indicates the user-agent should not connect to any
     resources beyond the domain.

  2.5 Record Size

     Published records SHOULD be limited to fit within the 512 octet
     limit. If not, it could exceed the DNS protocol limit. For further
     details on the technical details, please see [RFC7208] section 3.4
     entitled Record Size and [RFC2181] section 11 entitled Name Syntax.
     It is RECOMMENDED to follow these directions.

  3  Security Considerations

  3.1 Sensible initial defaults

     The initial compatible user agent mode was chosen as a lead in order
     to provide a path for adoption due to this RFC requiring changes
     from both website operators and developers of user-agents.

  3.2 DNS TXT versus a text file

     The DNS TXT entry was chosen after working through a model with a
     plain text file, similar to security.txt or a robots.txt file. After
     consideration, one of the defensive tactics for UACS is to protect a
     client against a server compromise attack in which a text file could
     be replaced by an attacker. Having the approved connections list
     separate provides an additional layer of defense.

  3.3 Misconfigurations

     It is possible to configure the connection host entries too
     inclusively thereby allowing connections to unintended hosts and
     degrading the security posture this RFC is proposing.

  3.4 Profiling

     A profile-building model of security is prone to functional deferred
     deprecation upon website updates. For organizations managing security
     profiles, not every security administrator is willing to trust every
     website vendor implicitly, and not every website vendor openly 
     discloses every third-party resource connection. 

     Attacks that leverage injectionable payloads from second- and
     third-party connections require an open connection to an
     attacker-controlled resource. Limiting attacks with connection
     restrictions such as this RFC reduces the available options an
     attacker may use and improves the security posture of the user agent.

  4  IANA Considerations

     This draft does not require any IANA action.

  5  References

  5.1  Normative References

     [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 
               and Support",  RFC 1123, October 1989

     [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
               Arbitrary String Attributes", RFC 1464,
               DOI 10.17487/RFC1464, May 1993,
               <https://www.rfc-editor.org/rfc/rfc1464>.

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

     [RFC2181] Elz, R., "Clarifications to the DNS Specification",  
               RFC 2181, July 1997

     [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
               Insensitivity Clarification",  RFC 4343, January 2006

     [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
                Authorizing Use of Domains in Email, Version 1", RFC 7208,
                DOI 10.17487/RFC7208, April 2014,
                <https://www.rfc-editor.org/info/rfc7208>.

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

  6  Acknowledgments

     The author would like to thank Steven Hart, Michael J. Cataletto,
     Yulia Slesavara and the many other team members who contributed
     suggestions and edits to help complete this document.
   
     This document was prepared using 2-Word-v2.0.template.dot.

  Authors' Addresses

     David Steckbeck
     Email: dsteckbeck@gatech.edu


name: draft-ietf-lamps-e2e-mail-guidance
rev: 17
title: Guidance on End-to-End E-mail Security
time: 2025-08-23T03:12:49Z
group_uri: /api/v1/group/group/2164/
expires: 2025-07-12T19:18:18Z
ad: /api/v1/person/person/105815/
shepherd: /api/v1/person/email/housley@vigilsec.com/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578748+00:00
source: ietf
abstract:
  End-to-end cryptographic protections for e-mail messages can provide
     useful security.  However, the standards for providing cryptographic
     protection are extremely flexible.  That flexibility can trap users
     and cause surprising failures.  This document offers guidance for
     mail user agent implementers to help mitigate those risks, and to
     make end-to-end e-mail simple and secure for the end user.  It
     provides a useful set of vocabulary as well as recommendations to
     avoid common failures.  It also identifies a number of currently
     unsolved usability and interoperability problems.

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:
  lamps                                                 D. K. Gillmor, Ed.
  Internet-Draft                                                      ACLU
  Intended status: Informational                         B. Hoeneisen, Ed.
  Expires: 12 July 2025                                        pEp Project
                                                          A. Melnikov, Ed.
                                                                 Isode Ltd
                                                            8 January 2025


                   Guidance on End-to-End E-mail Security
                   draft-ietf-lamps-e2e-mail-guidance-17

  Abstract

     End-to-end cryptographic protections for e-mail messages can provide
     useful security.  However, the standards for providing cryptographic
     protection are extremely flexible.  That flexibility can trap users
     and cause surprising failures.  This document offers guidance for
     mail user agent implementers to help mitigate those risks, and to
     make end-to-end e-mail simple and secure for the end user.  It
     provides a useful set of vocabulary as well as recommendations to
     avoid common failures.  It also identifies a number of currently
     unsolved usability and interoperability problems.

  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://dkg.gitlab.io/e2e-mail-guidance/.  Status information for
     this document may be found at https://datatracker.ietf.org/doc/draft-
     ietf-lamps-e2e-mail-guidance/.

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

     Source for this draft and an issue tracker can be found at
     https://gitlab.com/dkg/e2e-mail-guidance.

  Status of This Memo

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






  Gillmor, et al.           Expires 12 July 2025                  [Page 1]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 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 12 July 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  . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
         1.1.1.  Structural Header Fields  . . . . . . . . . . . . . .   7
         1.1.2.  User-Facing Header Fields . . . . . . . . . . . . . .   8
     2.  Usability . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       2.1.  Simplicity  . . . . . . . . . . . . . . . . . . . . . . .   9
       2.2.  E-mail Users Want a Familiar Experience . . . . . . . . .  10
       2.3.  Warning About Failure vs. Announcing Success  . . . . . .  11
     3.  Types of Protection . . . . . . . . . . . . . . . . . . . . .  11
       3.1.  Simplified Mental Model . . . . . . . . . . . . . . . . .  12
       3.2.  One Cryptographic Status Per Message  . . . . . . . . . .  13
     4.  Cryptographic MIME Message Structure  . . . . . . . . . . . .  14
       4.1.  Cryptographic Layers  . . . . . . . . . . . . . . . . . .  14
         4.1.1.  S/MIME Cryptographic Layers . . . . . . . . . . . . .  14
         4.1.2.  PGP/MIME Cryptographic Layers . . . . . . . . . . . .  15
       4.2.  Cryptographic Envelope  . . . . . . . . . . . . . . . . .  16
       4.3.  Cryptographic Payload . . . . . . . . . . . . . . . . . .  17
       4.4.  Types of Cryptographic Envelope . . . . . . . . . . . . .  17
         4.4.1.  Simple Cryptographic Envelopes  . . . . . . . . . . .  17
         4.4.2.  Multilayer Cryptographic Envelopes  . . . . . . . . .  17



  Gillmor, et al.           Expires 12 July 2025                  [Page 2]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


       4.5.  Errant Cryptographic Layers . . . . . . . . . . . . . . .  17
         4.5.1.  Mailing List Wrapping . . . . . . . . . . . . . . . .  18
         4.5.2.  A Baroque Example . . . . . . . . . . . . . . . . . .  18
       4.6.  Cryptographic Summary . . . . . . . . . . . . . . . . . .  19
     5.  Message Composition . . . . . . . . . . . . . . . . . . . . .  19
       5.1.  Message Composition Algorithm . . . . . . . . . . . . . .  19
       5.2.  Encryption Outside, Signature Inside  . . . . . . . . . .  20
       5.3.  Avoid Offering Encrypted-only Messages  . . . . . . . . .  21
       5.4.  Composing a Reply Message . . . . . . . . . . . . . . . .  22
     6.  Message Interpretation  . . . . . . . . . . . . . . . . . . .  23
       6.1.  Rendering Well-formed Messages  . . . . . . . . . . . . .  23
       6.2.  Errant Cryptographic Layers . . . . . . . . . . . . . . .  23
         6.2.1.  Errant Signing Layer  . . . . . . . . . . . . . . . .  23
         6.2.2.  Errant Encryption Layer . . . . . . . . . . . . . . .  25
         6.2.3.  Avoiding Non-MIME Cryptographic Mechanisms  . . . . .  26
       6.3.  Forwarded Messages with Cryptographic Protection  . . . .  27
       6.4.  Signature failures  . . . . . . . . . . . . . . . . . . .  27
       6.5.  Weak Encryption . . . . . . . . . . . . . . . . . . . . .  29
     7.  Reasoning about Message Parts . . . . . . . . . . . . . . . .  30
       7.1.  Main Body Part  . . . . . . . . . . . . . . . . . . . . .  30
       7.2.  Attachments . . . . . . . . . . . . . . . . . . . . . . .  31
       7.3.  MIME Part Examples  . . . . . . . . . . . . . . . . . . .  32
     8.  Certificate Management  . . . . . . . . . . . . . . . . . . .  33
       8.1.  Peer Certificates . . . . . . . . . . . . . . . . . . . .  33
         8.1.1.  Peer Certificate Selection  . . . . . . . . . . . . .  33
       8.2.  Local Certificates  . . . . . . . . . . . . . . . . . . .  34
         8.2.1.  Getting Certificates for the User . . . . . . . . . .  34
         8.2.2.  Local Certificate Maintenance . . . . . . . . . . . .  36
         8.2.3.  Shipping Certificates in Outbound Messages  . . . . .  37
     9.  Common Pitfalls and Guidelines  . . . . . . . . . . . . . . .  38
       9.1.  Reading Sent Messages . . . . . . . . . . . . . . . . . .  39
       9.2.  Reading Encrypted Messages after Certificate
             Expiration  . . . . . . . . . . . . . . . . . . . . . . .  40
       9.3.  Unprotected Message Header Fields . . . . . . . . . . . .  40
       9.4.  Composing an Encrypted Message with Bcc . . . . . . . . .  41
         9.4.1.  Simple Encryption with Bcc  . . . . . . . . . . . . .  41
       9.5.  Draft Messages  . . . . . . . . . . . . . . . . . . . . .  42
       9.6.  Composing a Message to Heterogeneous Recipients . . . . .  43
       9.7.  Message Transport Protocol Proxy: A Dangerous
             Implementation Choice . . . . . . . . . . . . . . . . . .  45
         9.7.1.  Dangers of a Submission Proxy for Message
                 Composition . . . . . . . . . . . . . . . . . . . . .  45
         9.7.2.  Dangers of an IMAP Proxy for Message Rendering  . . .  47
         9.7.3.  Who Controls the Proxy? . . . . . . . . . . . . . . .  48
       9.8.  Intervening MUAs Do Not Handle End-to-End Cryptographic
             Protections . . . . . . . . . . . . . . . . . . . . . . .  48
       9.9.  External Subresources in MIME Parts Break Cryptographic
             Protections . . . . . . . . . . . . . . . . . . . . . . .  49



  Gillmor, et al.           Expires 12 July 2025                  [Page 3]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  51
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  51
     12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  51
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  51
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  51
       13.2.  Informative References . . . . . . . . . . . . . . . . .  52
     Appendix A.  Future Work  . . . . . . . . . . . . . . . . . . . .  56
       A.1.  Webmail Threat Model  . . . . . . . . . . . . . . . . . .  56
       A.2.  Test Vectors  . . . . . . . . . . . . . . . . . . . . . .  56
       A.3.  Further Guidance on Peer Certificates . . . . . . . . . .  57
         A.3.1.  Certificate Discovery from Incoming Messages  . . . .  57
         A.3.2.  Certificate Directories . . . . . . . . . . . . . . .  57
         A.3.3.  Checking for Certificate Revocation . . . . . . . . .  57
         A.3.4.  Further Peer Certificate Selection  . . . . . . . . .  57
         A.3.5.  Human-readable Names in Peer Certificates, Header
                 Fields, and Addressbooks  . . . . . . . . . . . . . .  58
       A.4.  Further Guidance on Local Certificates and Secret Keys  .  58
         A.4.1.  Cross-MUA sharing of Local Certificates and Secret
                 Keys  . . . . . . . . . . . . . . . . . . . . . . . .  59
         A.4.2.  Use of Smartcards or Other Portable Secret Key
                 Mechanisms  . . . . . . . . . . . . . . . . . . . . .  59
         A.4.3.  Active Local Certificate Maintenance  . . . . . . . .  59
       A.5.  Certification Authorities . . . . . . . . . . . . . . . .  59
       A.6.  Indexing and Search of Encrypted Messages . . . . . . . .  60
       A.7.  Cached Signature Validation . . . . . . . . . . . . . . .  60
       A.8.  Aggregate Cryptographic Status  . . . . . . . . . . . . .  60
       A.9.  Expectations of Cryptographic Protection  . . . . . . . .  61
       A.10. Secure Deletion . . . . . . . . . . . . . . . . . . . . .  61
       A.11. Interaction with Opportunistic Encryption . . . . . . . .  62
       A.12. Split Attachments . . . . . . . . . . . . . . . . . . . .  62
       A.13. Proxy Extensions  . . . . . . . . . . . . . . . . . . . .  62
       A.14. Mailing Lists . . . . . . . . . . . . . . . . . . . . . .  63
     Appendix B.  Document History . . . . . . . . . . . . . . . . . .  64
       B.1.  Substantive changes from draft-ietf-...-16 to
              draft-ietf-...-17  . . . . . . . . . . . . . . . . . . .  64
       B.2.  Substantive changes from draft-ietf-...-15 to
              draft-ietf-...-16  . . . . . . . . . . . . . . . . . . .  64
       B.3.  Substantive changes from draft-ietf-...-14 to
              draft-ietf-...-15  . . . . . . . . . . . . . . . . . . .  64
       B.4.  Substantive changes from draft-ietf-...-13 to
              draft-ietf-...-14  . . . . . . . . . . . . . . . . . . .  64
       B.5.  Substantive changes from draft-ietf-...-12 to
              draft-ietf-...-13  . . . . . . . . . . . . . . . . . . .  65
       B.6.  Substantive changes from draft-ietf-...-11 to
              draft-ietf-...-12  . . . . . . . . . . . . . . . . . . .  65
       B.7.  Substantive changes from draft-ietf-...-10 to
              draft-ietf-...-11  . . . . . . . . . . . . . . . . . . .  65




  Gillmor, et al.           Expires 12 July 2025                  [Page 4]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


       B.8.  Substantive changes from draft-ietf-...-09 to
              draft-ietf-...-10  . . . . . . . . . . . . . . . . . . .  65
       B.9.  Substantive changes from draft-ietf-...-08 to
              draft-ietf-...-09  . . . . . . . . . . . . . . . . . . .  65
       B.10. Substantive changes from draft-ietf-...-07 to
              draft-ietf-...-08  . . . . . . . . . . . . . . . . . . .  65
       B.11. Substantive changes from draft-ietf-...-06 to
              draft-ietf-...-07  . . . . . . . . . . . . . . . . . . .  66
       B.12. Substantive changes from draft-ietf-...-05 to
              draft-ietf-...-06  . . . . . . . . . . . . . . . . . . .  66
       B.13. Substantive changes from draft-ietf-...-04 to
              draft-ietf-...-05  . . . . . . . . . . . . . . . . . . .  66
       B.14. Substantive changes from draft-ietf-...-03 to
              draft-ietf-...-04  . . . . . . . . . . . . . . . . . . .  66
       B.15. Substantive changes from draft-ietf-...-02 to
              draft-ietf-...-03  . . . . . . . . . . . . . . . . . . .  67
       B.16. Substantive changes from draft-ietf-...-01 to
              draft-ietf-...-02  . . . . . . . . . . . . . . . . . . .  67
       B.17. Substantive changes from draft-ietf-...-00 to
              draft-ietf-...-01  . . . . . . . . . . . . . . . . . . .  67
       B.18. Substantive changes from draft-dkg-...-01 to
              draft-ietf-...-00  . . . . . . . . . . . . . . . . . . .  67
       B.19. Substantive changes from draft-dkg-...-00 to
              draft-dkg-...-01 . . . . . . . . . . . . . . . . . . . .  67
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  67

  1.  Introduction

     E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME
     ([RFC3156]) cryptographic standards can provide integrity,
     authentication and confidentiality to MIME ([RFC4289]) e-mail
     messages.

     However, there are many ways that a receiving mail user agent can
     misinterpret or accidentally break these security guarantees.  For
     example, [EFAIL]'s "Direct Exfiltration" attack leaks cleartext due
     to an attack that splices existing ciphertext into a new message,
     which is then handled optimistically (and wrongly) by many mail user
     agents.

     A mail user agent that interprets a message with end-to-end
     cryptographic protections needs to do so defensively, staying alert
     to different ways that these protections can be bypassed by mangling
     (either malicious or accidental) or a failed user experience.







  Gillmor, et al.           Expires 12 July 2025                  [Page 5]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A mail user agent that generates a message with end-to-end
     cryptographic protections should be aware of these defensive
     interpretation strategies, and should compose any new outbound
     message conservatively if they want the protections to remain intact.

     This document offers guidance to the implementer of a mail user agent
     that provides these cryptographic protections, whether for sending or
     receiving mail.  An implementation that follows this guidance will
     provide its users with stronger and easier-to-understand security
     properties, and will also offer more reliable interoperability for
     messages exchanged with other implementations.

     In Appendix A, this document also identifies a number of
     interoperability and usability concerns for end-to-end cryptographic
     e-mail which have no current broadly accepted technical standard for
     resolution.  One major area not covered in this document is the
     acquisition and long-term maintenance of cryptographic identity
     information and metadata across multiple mail user agents controlled
     by the same user.

     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.

  1.1.  Terminology

     For the purposes of this document, we define the following concepts:

     *  _MUA_ is short for Mail User Agent; an e-mail client.

     *  _Protection_ of message data refers to cryptographic encryption
        and/or signatures, providing confidentiality, authenticity, and/or
        integrity.

     *  _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic
        Payload_, _Cryptographic Summary_, and _Errant Cryptographic
        Layer_ are defined in Section 4

     *  A _well-formed_ e-mail message with cryptographic protection has
        both a _Cryptographic Envelope_ and a _Cryptographic Payload_.

     *  _Structural Header Fields_ are documented in Section 1.1.1.

     *  _User-Facing Header Fields_ are documented in Section 1.1.2.





  Gillmor, et al.           Expires 12 July 2025                  [Page 6]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  _Main Body Part_ is the part (or parts) that are typically
        rendered to the user as the message itself (not "as an
        attachment").  See Section 7.1.

     This document contains extensive discussion about end-to-end
     cryptographic protections in e-mail, while acknowledging that many
     MUAs have no capabilities for end-to-end cryptographic protections at
     all.  We divide MUAs into three distinct profiles:

     *  A _Non-cryptographic_ MUA has no capabilities for end-to-end
        cryptographic protections.

     *  A _Conformant_ MUA follows the guidance in this document when
        dealing with end-to-end cryptographic protections.

     *  A _Legacy_ MUA has capabilities for end-to-end cryptographic
        protections, but does not adhere to the the guidance in this
        document.

     At the time of the writing of this document, most MUAs with
     cryptographic protections are legacy MUAs.

  1.1.1.  Structural Header Fields

     A message header field named MIME-Version, or whose name begins with
     Content- is referred to in this document as a "structural" header
     field.  This is a less-ambiguous name for what [RFC2045] calls "MIME
     Header Fields".

     These header fields indicate something about the specific MIME part
     they are attached to, and cannot be transferred or copied to other
     parts without endangering the readability of the message.

     This includes:

     *  MIME-Version

     *  Content-Type

     *  Content-Transfer-Encoding

     *  Content-Disposition









  Gillmor, et al.           Expires 12 July 2025                  [Page 7]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  1.1.2.  User-Facing Header Fields

     Of all the header fields that an e-mail message may contain, only a
     handful are typically presented directly to the user.  This document
     refers to them as "user-facing" header fields.  Typically, user-
     facing header fields are:

     *  Subject

     *  From

     *  To

     *  Cc

     *  Date

     *  Reply-To

     *  Followup-To

     *  Sender

     *  Resent-From

     *  Resent-To

     *  Resent-Cc

     *  Resent-Date

     *  Resent-Sender

     The above list are the header fields most often presented directly to
     the user who views a message, though an MUA may also decide to treat
     any other header field as "user-facing".  Of course, many of these
     header fields are entirely absent from any given message, and an
     absent header field is not presented to the user at all.

     Note that the resending header fields (those beginning with Resent-)
     are typically only added by an intervening MUA (see Section 3.6.6 of
     [RFC5322] and Section 9.8 of this document).  As such, though they
     may in some cases be presented to the user, they will typically not
     bear any end-to-end cryptographic protection (even if the original
     header fields of a message are protected, see Section 9.3), because
     they are unknown to the original sender.





  Gillmor, et al.           Expires 12 July 2025                  [Page 8]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Other header fields may affect the visible rendering of the message
     (e.g., References and In-Reply-To may affect the placement of a
     message in a threaded discussion; or the List-* and Archived-At
     header fields added by mailing lists may cause additional buttons to
     be displayed during rendering), but they are not directly displayed
     to the user and so are not considered "user-facing".

  2.  Usability

     Any MUA that enables its user to transition from unprotected messages
     to messages with end-to-end cryptographic protection needs to
     consider how the user understands this transition.  That said, the
     primary goal of the user of an MUA is communication -- so interface
     elements that interfere with communication should be avoided where
     possible.

     Furthermore, it is a near certainty that the user will continue to
     encounter unprotected messages, and may need to send unprotected
     messages (for example, if a given recipient cannot handle
     cryptographic protections).  This means that the MUA needs to provide
     the user with some guidance, so that they understand what protections
     any given message or conversation has.  But the user should not be
     overwhelmed with choices or presented with unactionable information.

  2.1.  Simplicity

     The end user (the operator of the MUA) is unlikely to understand
     complex end-to-end cryptographic protections on any e-mail message,
     so keep it simple.

     For clarity to the user, any cryptographic protections should apply
     to the message as a whole, not just to some subparts.

     This is true for message composition: the standard message
     composition user interface of an MUA should offer minimal controls
     which indicate which types of protection to apply to the new message
     as a whole.

     This is also true for message interpretation: the standard message
     rendering user interface of an MUA should offer a minimal, clear
     indicator about the end-to-end cryptographic status of the message as
     a whole.

     See Section 3 for more detail about mental models and cryptographic
     status.






  Gillmor, et al.           Expires 12 July 2025                  [Page 9]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     (It is of course possible that a message forwarded as a MIME
     attachment could have its own cryptographic status while still being
     a message subpart; but that status should be distinct from the status
     of the enclosing message.)

  2.2.  E-mail Users Want a Familiar Experience

     A person communicating over the Internet today often has many options
     for reaching their desired correspondent, including web-based
     bulletin boards, contact forms, and instant messaging services.

     E-mail offers a few distinctions from these other systems, most
     notably features like:

     *  Ubiquity: Most correspondents will have an e-mail address, while
        not everyone is present on the various non-e-mail messaging
        services, particularly those that have reliable end-to-end
        cryptographic protections,

     *  Federation: interaction between users on distinct domains who have
        not agreed on a common communications provider is still possible,
        and

     *  User Control: the user can interact with the e-mail system using
        an MUA of their choosing, including automation and other control
        over their preferred and/or customized workflow.

     Other systems (like some popular instant messaging applications, such
     as WhatsApp and Signal Private Messenger) offer built-in end-to-end
     cryptographic protections by default, which are simpler for the user
     to understand.  ("All the messages I see on Signal are confidential
     and integrity-protected" is a clean user story)

     A user of e-mail is likely using e-mail instead of other systems
     because of the distinctions outlined above.  When adding end-to-end
     cryptographic protection to an e-mail endpoint, care should be taken
     not to negate any of the distinct features of e-mail as a whole.  If
     these features are violated to provide end-to-end crypto, the user
     may just as well choose one of the other systems that don't have the
     drawbacks that e-mail has.  Implementers should try to provide end-
     to-end protections that retain the familiar experience of e-mail
     itself.









  Gillmor, et al.           Expires 12 July 2025                 [Page 10]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Furthermore, an e-mail user is likely to regularly interact with
     other e-mail correspondents who _cannot_ handle or produce end-to-end
     cryptographic protections.  Care should be taken that enabling
     cryptography in an MUA does not inadvertently limit the ability of
     the user to interact with correspondents who use legacy or non-
     cryptographic MUAs.

  2.3.  Warning About Failure vs. Announcing Success

     Moving the web from http to https offers useful historical
     similarities to adding end-to-end encryption to e-mail.

     In particular, the indicators of what is "secure" vs. "insecure" for
     web browsers have changed over time.  For example, years ago the
     default experience was http, and https sites were flagged with
     "secure" indicators like a lock icon.  Starting in 2018, some
     browsers reversed that process by downplaying https, and instead
     visibly marking http as "not secure" (see [chrome-indicators]).

     By analogy, when the user of an MUA first enables end-to-end
     cryptographic protection, it's likely that they will want to see
     which messages _have_ protection (that is, the security indicators
     amenable to a conformant MUA as of 2024 are most likely to be
     comparable to those of a pre-2018 web browser).  But a user whose
     private e-mail communications with a given correspondent, or within a
     given domain are known to be entirely end-to-end protected might
     instead want to know which messages do _not_ have the expected
     protections.

     Note also that some messages may be expected to be confidential, but
     other messages are expected to be public -- the types of protection
     (see Section 3) that apply to each particular message will be
     different.  And the types of protection that are _expected_ to be
     present in any context might differ (for example, by sender, by
     thread, or by date).

     It is out of scope for this document to define expectations about
     protections for any given message, but an implementer who cares about
     usable experience should be deliberate and judicious about the
     expectations their interface assumes that the user has in a given
     context.  See also Appendix A.9 for future work.

  3.  Types of Protection

     A given message might be:

     *  signed,




  Gillmor, et al.           Expires 12 July 2025                 [Page 11]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  encrypted,

     *  both signed and encrypted, or

     *  none of the above.

     Given that many e-mail messages offer no cryptographic protections,
     the user needs to be able to detect which protections are present for
     any given message.

  3.1.  Simplified Mental Model

     To the extent that an e-mail message actually does have end-to-end
     cryptographic protections, those protections need to be visible and
     comprehensible to the end users: both the sending user and the
     receiving user.  If either user is unaware of the protections, then
     they do not effectively extend all the way to the "end".

     However, most users do not have (or want to have) a sophisticated
     mental model of what kinds of protections can be associated with a
     given message.  Even the four states above approach the limits of
     complexity for an interface for normal users.

     While Section 5.3 recommends avoiding deliberate creation of
     encrypted-only messages, some messages may end up in the encrypted-
     only state due to signature failure or certificate revocation.

     A simple model for the receiving user could be that a message is in
     one of three normal states, which align with the only reasonable
     choices for message composition:

     *  Unprotected

     *  Verified (has a valid signature from the apparent sender of the
        message)

     *  Confidential (meaning, encrypted, with a valid signature from the
        apparent sender of the message)

     However, one error state exists for received mail that does not
     correspond to a reasonable choice for message composition:

     *  Encrypted But Unverified (meaning, encrypted without a valid
        signature from the apparent sender of the message)

     Note that this last state is not "Confidential" (a secret shared
     exclusively between the participants in the communication) because
     the recipient does not know for sure who sent it.



  Gillmor, et al.           Expires 12 July 2025                 [Page 12]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     In an ecosystem where encrypted-only messages are never deliberately
     sent (see Section 5.3), representing an Encrypted But Unverified
     message as a type of user-visible error is not unreasonable.
     However, this is not the state of the global e-mail ecosystem when
     this document was written, since some legacy MUAs permit sending
     encrypted-but-unsigned mail (see Appendix A.9 for possible future
     guidance).

     Alternately, an MUA may prefer to represent the state of a Encrypted
     but Unverified message to the user as though it was Unprotected,
     since no verification is possible.  However the MUA represents the
     message to the user, though, it MUST NOT leak cleartext of an
     encrypted message (even an Encrypted but Unverified message) in
     subsequent replies (see Section 5.4) or similar replications of the
     message.

     Note that a cleartext message with an invalid signature SHOULD NOT be
     represented to the user as anything other than Unprotected (see
     Section 6.4), unless the MUA is providing the user with debugging
     information.

     At the time this document was written, the global e-mail ecosystem
     contains a heterogeneous mix of legacy and non-cryptographic MUAs.
     In such an ecosystem, a conformant MUA may prefer instead to
     represent "Verified" and "Encrypted" as orthogonal states of any
     given received message.  While this model does not precisely match
     the choice a user makes when composing a message, it may align more
     with the reality of the range of messages they receive.

  3.2.  One Cryptographic Status Per Message

     Some MUAs may attempt to generate multiple copies of a given e-mail
     message, with different copies offering different types of protection
     (for example, opportunistically encrypting on a per-recipient basis).
     A message resulting from this approach will have a cryptographic
     state that few users will understand.  Even if the sender understands
     the different statuses of the different copies, the recipients of the
     messages may not understand (each recipient might not even know about
     the other copies).  See for example the discussion in Section 9.6 for
     how this can go wrong.

     For comprehensibility, a conformant MUA SHOULD NOT create multiple
     copies of a given message that differ in the types of end-to-end
     cryptographic protections afforded.

     For opportunistic cryptographic protections that are not surfaced to
     the user (that is, that are not end-to-end), other mechanisms like
     transport encryption ([RFC3207]) or domain-based signing ([RFC6376])



  Gillmor, et al.           Expires 12 July 2025                 [Page 13]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     may be preferable due to ease of implementation and deployment.
     These opportunistic transport protections are orthogonal to the end-
     to-end protections described in this document.

     To the extent that opportunistic message protections are made visible
     to the user for a given copy of a message, a conformant MUA will
     distinguish that status from the message's end-to-end cryptographic
     status.  But the potential confusion caused by rendering this
     complex, hybrid state may not be worth the value of additional
     knowledge gained by the user.  The benefits of opportunistic
     protections accrue (or don't) even without visibility to the user
     (see [RFC7435]).

     The user needs a single clear, simple, and correct indication about
     the end-to-end cryptographic status of any given message.  See
     Section 4.6 for more details.

  4.  Cryptographic MIME Message Structure

     Implementations use the structure of an e-mail message to establish
     (when sending) and understand (when receiving) the cryptographic
     status of the message.  This section establishes some conventions
     about how to think about message structure.

  4.1.  Cryptographic Layers

     "Cryptographic Layer" refers to a MIME substructure that supplies
     some cryptographic protections to an internal MIME subtree.  The
     internal subtree is known as the "protected part" though of course it
     may itself be a multipart object.

     In the diagrams below, "↧" (DOWNWARDS ARROW FROM BAR, U+21A7)
     indicates "decrypts to", and "⇩" (DOWNWARDS WHITE ARROW, U+21E9)
     indicates "unwraps to".

  4.1.1.  S/MIME Cryptographic Layers

     For S/MIME [RFC8551], there are four forms of Cryptographic Layers:
     multipart/signed, PKCS #7 signed-data, PKCS #7 enveloped-data, PKCS
     #7 authEnveloped-data.

  4.1.1.1.  S/MIME Multipart Signed Cryptographic Layer

     └┬╴multipart/signed; protocol="application/pkcs7-signature"
      ├─╴[protected part]
      └─╴application/pkcs7-signature

     This MIME layer offers authentication and integrity.



  Gillmor, et al.           Expires 12 July 2025                 [Page 14]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  4.1.1.2.  S/MIME PKCS #7 signed-data Cryptographic Layer

     └─╴application/pkcs7-mime; smime-type="signed-data"
      ⇩ (unwraps to)
      └─╴[protected part]

     This MIME layer offers authentication and integrity.

  4.1.1.3.  S/MIME PKCS #7 enveloped-data Cryptographic Layer

     └─╴application/pkcs7-mime; smime-type="enveloped-data"
      ↧ (decrypts to)
      └─╴[protected part]

     This MIME layer offers confidentiality.

  4.1.1.4.  S/MIME PKCS #7 authEnveloped-data Cryptographic Layer

     └─╴application/pkcs7-mime; smime-type="authEnveloped-data"
      ↧ (decrypts to)
      └─╴[protected part]

     This MIME layer offers confidentiality and integrity.

     Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
     (Section 4.1.1.4) have identical message structure and very similar
     confidentiality semantics.  The only difference between the two is
     ciphertext malleability.

     The examples in this document only include enveloped-data, but the
     implications for that layer apply to authEnveloped-data as well.

  4.1.1.5.  PKCS #7 Compression is NOT a Cryptographic Layer

     The Cryptographic Message Syntax (CMS) provides a MIME compression
     layer (smime-type="compressed-data"), as defined in [RFC3274].  While
     the compression layer is technically a part of CMS, it is not
     considered a Cryptographic Layer for the purposes of this document.

  4.1.2.  PGP/MIME Cryptographic Layers

     For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers,
     signing and encryption.

  4.1.2.1.  PGP/MIME Signing Cryptographic Layer (multipart/signed)






  Gillmor, et al.           Expires 12 July 2025                 [Page 15]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     └┬╴multipart/signed; protocol="application/pgp-signature"
      ├─╴[protected part]
      └─╴application/pgp-signature

     This MIME layer offers authenticity and integrity.

  4.1.2.2.  PGP/MIME Encryption Cryptographic Layer (multipart/encrypted)

     └┬╴multipart/encrypted
      ├─╴application/pgp-encrypted
      └─╴application/octet-stream
       ↧ (decrypts to)
       └─╴[protected part]

     This MIME layer can offer any of:

     *  confidentiality (via a Symmetrically Encrypted Data Packet, see
        Section 5.7 of [RFC9580]; an MUA MUST NOT generate this form due
        to ciphertext malleability)

     *  confidentiality and integrity (via a Symmetrically Encrypted
        Integrity Protected Data Packet (SEIPD), see Section 5.13 of
        [RFC9580]), or

     *  confidentiality, integrity, and authenticity all together (by
        including an OpenPGP Signature Packet within the SEIPD).

  4.2.  Cryptographic Envelope

     The Cryptographic Envelope is the largest contiguous set of
     Cryptographic Layers of an e-mail message starting with the outermost
     MIME type (that is, with the Content-Type of the message itself).

     If the Content-Type of the message itself is not a Cryptographic
     Layer, then the message has no cryptographic envelope.

     "Contiguous" in the definition above indicates that if a
     Cryptographic Layer is the protected part of another Cryptographic
     Layer, the layers together comprise a single Cryptographic Envelope.

     Note that if a non-Cryptographic Layer intervenes, all Cryptographic
     Layers within the non-Cryptographic Layer _are not_ part of the
     Cryptographic Envelope.  They are Errant Cryptographic Layers (see
     Section 4.5).

     Note also that the ordering of the Cryptographic Layers implies
     different cryptographic properties.  A signed-then-encrypted message
     is different than an encrypted-then-signed message.  See Section 5.2.



  Gillmor, et al.           Expires 12 July 2025                 [Page 16]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  4.3.  Cryptographic Payload

     The Cryptographic Payload of a message is the first non-Cryptographic
     Layer -- the "protected part" -- within the Cryptographic Envelope.

  4.4.  Types of Cryptographic Envelope

  4.4.1.  Simple Cryptographic Envelopes

     As described above, if the "protected part" identified in the section
     above is not itself a Cryptographic Layer, that part _is_ the
     Cryptographic Payload.

     If the application wants to generate a message that is both encrypted
     and signed, it MAY use the simple MIME structure from Section 4.1.2.2
     by ensuring that the [RFC9580] Encrypted Message within the
     application/octet-stream part contains an [RFC9580] Signed Message
     (the final option described in Section 4.1.2.2).

  4.4.2.  Multilayer Cryptographic Envelopes

     It is possible to construct a Cryptographic Envelope consisting of
     multiple layers with either S/MIME or PGP/MIME , for example using
     the following structure:

     A └─╴application/pkcs7-mime; smime-type="enveloped-data"
     B  ↧ (decrypts to)
     C  └─╴application/pkcs7-mime; smime-type="signed-data"
     D   ⇩ (unwraps to)
     E   └─╴[protected part]

     When handling such a message, the properties of the Cryptographic
     Envelope are derived from the series A, C.

     As noted in Section 4.4.1, PGP/MIME applications also have a simpler
     MIME construction available with the same cryptographic properties.

  4.5.  Errant Cryptographic Layers

     Due to confusion, malice, or well-intentioned tampering, a message
     may contain a Cryptographic Layer that is not part of the
     Cryptographic Envelope.  Such a layer is an Errant Cryptographic
     Layer.

     An Errant Cryptographic Layer MUST NOT contribute to the message's
     overall cryptographic state.





  Gillmor, et al.           Expires 12 July 2025                 [Page 17]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Guidance for dealing with Errant Cryptographic Layers can be found in
     Section 6.2.

  4.5.1.  Mailing List Wrapping

     Some mailing list software will re-wrap a well-formed signed message
     before re-sending to add a footer, resulting in the following
     structure seen by recipients of the e-mail:

     H └┬╴multipart/mixed
     I  ├┬╴multipart/signed
     J  │├─╴text/plain
     K  │└─╴application/pgp-signature
     L  └─╴text/plain

     In this message, L is the footer added by the mailing list.  I is now
     an Errant Cryptographic Layer.

     Note that this message has no Cryptographic Envelope at all.

     It is NOT RECOMMENDED to produce e-mail messages with this structure,
     because a legacy MUA may present the data in part L as though it were
     part of J, though they have different cryptographic properties.  In
     particular, if the user believes that the entire message is signed,
     but cannot distinguish L from J then the author of L can effectively
     tamper with content of the signed message, breaking the user's
     expectation of integrity and authenticity.

  4.5.2.  A Baroque Example

     Consider a message with the following overcomplicated structure:

     M └┬╴multipart/encrypted
     N  ├─╴application/pgp-encrypted
     O  └─╴application/octet-stream
     P   ↧ (decrypts to)
     Q   └┬╴multipart/signed
     R    ├┬╴multipart/mixed
     S    │├┬╴multipart/signed
     T    ││├─╴text/plain
     U    ││└─╴application/pgp-signature
     V    │└─╴text/plain
     W    └─╴application/pgp-signature








  Gillmor, et al.           Expires 12 July 2025                 [Page 18]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     The 3 Cryptographic Layers in such a message are rooted in parts M,
     Q, and S.  But the Cryptographic Envelope of the message consists
     only of the properties derived from the series M, Q.  The
     Cryptographic Payload of the message is part R.  Part S is an Errant
     Cryptographic Layer.

     Note that this message has both a Cryptographic Envelope _and_ an
     Errant Cryptographic Layer.

     It is NOT RECOMMENDED to generate messages with such complicated
     structures.  Even if a receiving MUA can parse this structure
     properly, it is nearly impossible to render in a way that the user
     can reason about the cryptographic properties of part T compared to
     part V.

  4.6.  Cryptographic Summary

     The cryptographic status of an e-mail message with end-to-end
     cryptographic protections is known as the Cryptographic Summary.  A
     reasonable, simple Cryptographic Summary is derived from the
     aggregate properties of the layers in the Cryptographic Envelope.
     This is a conceptual tool and a feature that an MUA can use to guide
     behavior and user experience, but it is not necessarily always
     directly exposed in any given user interface.  See Section 6.1 for
     guidance and considerations about rendering the Cryptographic Summary
     to the user.

  5.  Message Composition

     This section describes the ideal composition of an e-mail message
     with end-to-end cryptographic protection.  A message composed with
     this form is most likely to achieve its end-to-end security goals.

  5.1.  Message Composition Algorithm

     This section describes the steps that an MUA should use to compose a
     cryptographically-protected message, such that it has a proper
     Cryptographic Envelope and Payload.

     The message composition algorithm takes three parameters:

     *  origbody: the traditional unprotected message body as a well-
        formed MIME tree (possibly just a single MIME leaf part).  As a
        well-formed MIME tree, origbody already has structural header
        fields present (see Section 1.1.1).






  Gillmor, et al.           Expires 12 July 2025                 [Page 19]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  origheaders: the intended non-structural header fields for the
        message, represented here as a list of (h,v) pairs, where h is a
        header field name and v is the associated value.

     *  crypto: The series of cryptographic protections to apply (for
        example, "sign with the secret key corresponding to X.509
        certificate X, then encrypt to X.509 certificates X and Y").  This
        is a routine that accepts a MIME tree as input (the Cryptographic
        Payload), wraps the input in the appropriate Cryptographic
        Envelope, and returns the resultant MIME tree as output.

     The algorithm returns a MIME object that is ready to be injected into
     the mail system:

     1.  Apply crypto to origbody, yielding MIME tree output

     2.  For each header name and value (h,v) in origheaders:

         a.  Add header h to output with value v

     3.  Return output

     This is the traditional algorithm.  It only protects the structural
     Header Fields of the message body, and leaves non-structural
     (including user-facing) Header Fields unprotected.

     Therefore, a conformant MUA MUST implement Header Protection as
     described in [I-D.ietf-lamps-header-protection] (see Section 9.3).

  5.2.  Encryption Outside, Signature Inside

     An e-mail message that is both signed and encrypted is signed
     _inside_ the encryption, and not the other way around.  For example,
     when crafting an encrypted and signed message using a simple
     Cryptographic Envelope of a single layer (Section 4.4.1) with PGP/
     MIME, the OpenPGP Encrypted Message object should contain an OpenPGP
     Signed Message.  Likewise, when using a multilayer Cryptographic
     Envelope (Section 4.4.2), the outer layer should be an encryption
     layer and the inner layer should be a signing layer.

     Putting the signature inside the encryption has two advantages:

     *  The details of the signature remain confidential, visible only to
        the parties capable of decryption.

     *  Any mail transport agent that modifies the message is unlikely to
        be able to accidentally break the signature.




  Gillmor, et al.           Expires 12 July 2025                 [Page 20]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A conformant MUA MUST NOT generate an encrypted and signed message
     where the only signature is outside the encryption.

  5.3.  Avoid Offering Encrypted-only Messages

     When generating an e-mail, there are four options for applying end-
     to-end cryptographic protections:

     *  Unprotected: In some cases, offering any end-to-end cryptographic
        protection is harmful: it may confuse the recipient and offer no
        benefit.

     *  Signed-only: In other cases, signing a message is useful
        (authenticity and integrity are desirable) but encryption is
        either impossible (for example, if the sender does not know how to
        encrypt to all recipients) or meaningless (for example, an e-mail
        message to a mailing list that is intended to be published to a
        public archive).

     *  Signed-and-Encryped: In other cases, full end-to-end
        confidentiality, authenticity, and integrity are desirable.

     *  Encrypted-only: There is no common use case for generating an
        e-mail message with end-to-end confidentiality but without
        authenticity or integrity.

        -  Additionally, some encryption schemes are malleable.  This
           allows an attacker to tamper with the plaintext by modifying
           the ciphertext (i.e., without decrypting it).  One way to
           prevent this is to authenticate the ciphertext, e.g., using
           signatures, MACs, or AEAD schemes.  See the CBC/CFB gadget
           attack in [EFAIL].

     A conformant MUA should keep its message composition interface
     simple.  When presenting the user with a choice of cryptographic
     protection, it MUST offer no more than three choices:

     *  No end-to-end cryptographic protection

     *  Verified (signed only)

     *  Confidential (signed and encrypted)

     Note that these choices correspond to the simplified mental model in
     Section 3.1.






  Gillmor, et al.           Expires 12 July 2025                 [Page 21]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A common anti-pattern among legacy MUAs is offering two boolean
     choices: one to toggle signing, another to toggle encryption.  This
     creates usability hurdles:

     *  A user who wants to send a signed and encrypted message will have
        to click two buttons instead of one.

     *  A user who clicks "Encrypt" but neglects to click "Signed" may not
        understand that they are creating a message which cannot be
        authenticated by the receiver.

  5.4.  Composing a Reply Message

     When replying to a message, most MUAs compose an initial draft of the
     reply that contains quoted text from the original message.  A
     responsible MUA will take precautions to avoid leaking the cleartext
     of an encrypted message in such a reply.

     If the original message was end-to-end encrypted, the replying MUA
     MUST either:

     *  compose the reply with end-to-end encryption, or

     *  avoid including quoted text from the original message.

     In general, MUAs SHOULD prefer the first option: to compose an
     encrypted reply.  This is what users expect.

     However, in some circumstances, the replying MUA cannot compose an
     encrypted reply.  For example, the MUA might not have a valid,
     unexpired, encryption-capable certificate for all recipients.  This
     can also happen during composition when a user adds a new recipient
     into the reply, or manually toggles the cryptographic protections to
     remove encryption.

     In this circumstance, the composing MUA SHOULD strip the quoted text
     from the original message, unless the user indicates that they are
     deliberately including previously confidential content in a non-
     confidential message.

     Note additional nuance about replies to malformed messages that
     contain encryption in Section 6.2.2.1.









  Gillmor, et al.           Expires 12 July 2025                 [Page 22]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  6.  Message Interpretation

     Despite the best efforts of well-intentioned senders to create e-mail
     messages with well-formed end-to-end cryptographic protection,
     receiving MUAs will inevitably encounter some messages with malformed
     end-to-end cryptographic protection.

     This section offers guidance on dealing with both well-formed and
     malformed messages containing Cryptographic Layers.

  6.1.  Rendering Well-formed Messages

     A message is well-formed when it has a Cryptographic Envelope, a
     Cryptographic Payload, and no Errant Cryptographic Layers.  Rendering
     a well-formed message is straightforward.

     The receiving MUA evaluates and assembles the cryptographic
     properties of the Cryptographic Envelope into a Cryptographic Summary
     and displays that status to the user in a secure, strictly-controlled
     part of the UI.  In particular, the part of the UI used to render the
     Cryptographic Summary of the message MUST NOT be spoofable,
     modifiable, or otherwise controllable by the received message itself.
     By analogy, consider the "lock" icon in the address bar of the web
     browser: regardless of the content of the webpage, the lock icon will
     only be displayed when the transport to the web server is adequately
     secured.

     Aside from this Cryptographic Summary, the message itself MUST be
     rendered as though the Cryptographic Payload is the body of the
     message.  The Cryptographic Layers themselves SHOULD NOT be rendered
     as distinct objects unless the MUA is providing the user with
     debugging information.

  6.2.  Errant Cryptographic Layers

     If an incoming message has any Errant Cryptographic Layers, a
     conformant interpreting MUA MUST ignore those layers when rendering
     the Cryptographic Summary of the message to the user.

  6.2.1.  Errant Signing Layer

     When rendering a message with an Errant Cryptographic Layer that
     provides authenticity and integrity (via signatures), the message
     should be rendered by replacing the Cryptographic layer with the part
     it encloses.

     For example, a message with this structure:




  Gillmor, et al.           Expires 12 July 2025                 [Page 23]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A └┬╴multipart/mixed
     B  ├╴text/plain
     C  ├┬╴multipart/signed
     D  │├─╴image/jpeg
     E  │└─╴application/pgp-signature
     F  └─╴text/plain

     Should be rendered identically to this:

     A └┬╴multipart/mixed
     B  ├─╴text/plain
     D  ├─╴image/jpeg
     F  └─╴text/plain

     In such a situation, a conformant MUA MUST NOT indicate in the
     Cryptographic Summary that the message is signed.  It MUST indicate
     that the message is Unprotected.

  6.2.1.1.  Exception: Mailing List Footers

     The use case described in Section 4.5.1 is common enough in some
     contexts that a conformant MUA MAY decide to handle it as a special
     exception.

     If the MUA determines that the message comes from a mailing list (for
     example, it has a List-ID header), and it has a structure that
     appends a footer to a signing-only Cryptographic Layer with a valid
     signature, such as:

     H └┬╴multipart/mixed
     I  ├┬╴multipart/signed
     J  │├─╴[protected part, may be arbitrary MIME subtree]
     K  │└─╴application/{pgp,pkcs7}-signature
     L  └─╴[footer, typically text/plain]

     or:

     H └┬╴multipart/mixed
     I  ├─╴application/pkcs7-mime; smime-type="signed-data"
        │⇩ (unwraps to)
     J  │└─╴[protected part, may be an arbitrary MIME subtree]
     L  └─╴[footer, typically text/plain]

     Then, the MUA MAY indicate to the user that this is a Verified
     message that has been wrapped by the mailing list.






  Gillmor, et al.           Expires 12 July 2025                 [Page 24]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     In this case, the MUA MUST distinguish the footer (part L) from the
     protected part (part J) when rendering any information about the
     signature.

     One way to do this is to offer the user two different views of the
     message: the "mailing list" view, which hides any positive
     Cryptographic Summary but shows the footer:

     Cryptographic Protections: Unprotected
     H └┬╴multipart/mixed
     J  ├─╴[protected part, may be arbitrary MIME subtree]
     L  └─╴[footer, typically text/plain]

     or the "sender's view", which shows the Cryptographic Summary as
     Verified, but hides the footer:

     Cryptographic Protections: Verified [details from part I]
     J └─╴[protected part, may be arbitrary MIME subtree]

  6.2.2.  Errant Encryption Layer

     An MUA may encounter a message with an Errant Cryptographic Layer
     that offers confidentiality (encryption), and the MUA is capable of
     decrypting it.

     The user wants to be able to see the contents of any message that
     they receive, so a conformant MUA in this situation SHOULD decrypt
     the part.

     In this case, though, a conformant MUA MUST NOT indicate in the
     message's Cryptographic Summary that the message itself was
     encrypted.  Such an indication could be taken to mean that other
     (non-encrypted) parts of the message arrived with cryptographic
     confidentiality.

     Furthermore, when decrypting an Errant Cryptographic Layer, the MUA
     MUST treat the decrypted cleartext as a distinct MIME subtree, and
     not attempt to merge or splice it together with any other part of the
     message.  This offers protection against the direct exfiltration
     (also known as EFAIL-DE) attacks described in [EFAIL] and so-called
     multipart/oracle attacks described in [ORACLE].

  6.2.2.1.  Replying to a Message with an Errant Encryption Layer

     Note that there is an asymmetry here between rendering and replying
     to a message with an Errant Encryption Layer.





  Gillmor, et al.           Expires 12 July 2025                 [Page 25]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     When rendering, the MUA does not indicate that the message was
     encrypted, even if some subpart of it was decrypted for rendering.

     When composing a reply to a message that has any encryption layer,
     even an errant one, the reply message SHOULD be marked for
     encryption, unless quoted and attributed text is not included in the
     reply, as noted in Section 5.4.

     When composing a reply to a message with an errant cryptographic
     layer, a conformant MUA MUST NOT decrypt any errant cryptographic
     layers when generating quoted or attributed text.  This will
     typically mean either leaving the ciphertext itself in the generated
     reply message, or simply not generating any quoted or attributed text
     at all.  This offers protection against the reply-based attacks
     described in [REPLY].

     In all circumstances, if the reply message cannot be encrypted (or if
     the user elects to not encrypt the reply), the composed reply MUST
     NOT include any material from the decrypted subpart.

  6.2.3.  Avoiding Non-MIME Cryptographic Mechanisms

     In some cases, there may be a cryptographic signature or encryption
     that does not coincide with a MIME boundary.  For example so-called
     "PGP Inline" messages typically contain base64-encoded ("ASCII-
     armored", see Section 6 of [RFC9580]) ciphertext, or within the
     content of a MIME part.

  6.2.3.1.  Do Not Validate Non-MIME Signatures

     When encountering cryptographic signatures in these positions, a
     conformant MUA MUST NOT attempt to validate any signature.  It is
     challenging to communicate to the user exactly which part of such a
     message is covered by the signature, so it is better to leave the
     message marked as Unprotected.  See [SPOOFING] for examples of
     spoofed message signatures that rely on permissive legacy clients
     that are willing to validate signatures in poorly-structured
     messages.

  6.2.3.2.  Skip or Isolate Non-MIME Decryption When Rendering

     When encountering what appears to be encrypted data not at a MIME
     boundary, a conformant MUA MAY decline to decrypt the data at all.

     During message rendering, if a conformant MUA attempts decryption of
     such a non-MIME encrypted section of an e-mail, it MUST synthesize a
     separate MIME part to contain only the decrypted data, and not
     attempt to merge or splice that part together with any other part of



  Gillmor, et al.           Expires 12 July 2025                 [Page 26]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     the message.  Keeping such a section distinct and isolated from any
     other part of the message offers protection against the direct
     exfiltration attacks (also known as EFAIL-DE) described in [EFAIL].

  6.2.3.3.  Do Not Decrypt Non-MIME Decryption when Replying

     When composing a reply to a message with such a non-MIME encrypted
     section, a conformant MUA MUST NOT decrypt any non-MIME encrypted
     section when generating quoted or attributed text, similar to the
     guidance in Section 6.2.2.1.

     This offers protection against the reply-based attacks described in
     [REPLY].

  6.3.  Forwarded Messages with Cryptographic Protection

     An incoming e-mail message may include an attached forwarded message,
     typically as a MIME subpart with Content-Type: message/rfc822
     ([RFC5322]) or Content-Type: message/global ([RFC5355]).

     Regardless of the cryptographic protections and structure of the
     incoming message, the internal forwarded message may have its own
     Cryptographic Envelope.

     The Cryptographic Layers that are part of the Cryptographic Envelope
     of the forwarded message are not Errant Cryptographic Layers of the
     surrounding message -- they are simply layers that apply to the
     forwarded message itself.

     A conformant rendering MUA MUST NOT conflate the cryptographic
     protections of the forwarded message with the cryptographic
     protections of the incoming message.

     A conformant rendering MUA MAY render a Cryptographic Summary of the
     protections afforded to the forwarded message by its own
     Cryptographic Envelope, as long as that rendering is unambiguously
     tied to the forwarded message itself, and cannot be spoofed either by
     the enclosing message or by the forwarded message.

  6.4.  Signature failures

     A cryptographic signature may fail in multiple ways.  A conformant
     receiving MUA that discovers a failed signature treats the message as
     though the signature did not exist.  This is similar to the standard
     guidance for about failed DKIM signatures (see Section 6.1 of
     [RFC6376]).





  Gillmor, et al.           Expires 12 July 2025                 [Page 27]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A conformant MUA MUST NOT render a message with a failed signature as
     more dangerous or more dubious than a comparable message without any
     signature at all.  In both cases, the Cryptographic Summary should be
     Unprotected.

     A conformant MUA that encounters an encrypted-and-signed message
     where the signature is invalid SHOULD treat the message the same way
     that it would treat a message that is encryption-only, unless the MUA
     is providing the user with debugging information.

     Some different ways that a signature may be invalid on a given
     message:

     *  the signature is not cryptographically valid (the math fails).

     *  the signature relies on suspect cryptographic primitives (e.g.,
        over a deprecated digest algorithm, or was made by a weak key,
        e.g., 1024-bit RSA); note that this requires the rendering MUA to
        have an explicit policy about what cryptographic primitives are
        acceptable.

     *  the signature is made by a certificate which the receiving MUA
        does not have access to.

     *  the certificate used to verify the signature was revoked.

     *  the certificate used to verify the signature was expired at the
        time that the signature was made.

     *  the certificate used to verify the signature does not correspond
        to the author of the message. (for X.509, there is no
        subjectAltName of type rfc822Name whose value matches an e-mail
        address found in From: or Sender:)

     *  the certificate used to verify the signature was not issued by an
        authority that the MUA user is willing to rely on for certifying
        the sender's e-mail address, and the user has no other reasonable
        indication that the certificate belongs to the sender's e-mail
        address.

     *  the signature indicates that it was made at a time much before or
        much after from the date of the message itself.

     *  The signature covers a message that depends on an external
        subresource that might change (see Section 9.9).

     A valid signature must pass all these tests, but of course invalid
     signatures may be invalid in more than one of the ways listed above.



  Gillmor, et al.           Expires 12 July 2025                 [Page 28]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  6.5.  Weak Encryption

     Sometimes, an MUA might encounter a message with a well-formed
     Cryptographic Envelope that uses a form of encryption with
     substantial known flaws.  For example, a PGP/MIME message might use a
     Symmetrically Encrypted Data packet, which is known to have malleable
     ciphertext (see Section 5.7 of [RFC9580]). ِAs another example, an S/
     MIME message may use an enveloped-data MIME part with a
     contentEncryptionAlgorithm of rc2-cbc with rc2ParameterVersion of
     160, meaning a 40-bit key (see Section 5.2 of [RFC3370]), which is
     widely considered breakable via brute force with moderate hardware
     investment in 2024.  As cryptanalysis and hardware capacities
     advance, an implementation may widen the scope of what encryption
     mechanisms are considered weak.

     A receiving MUA MUST warn the user that such a message has a known
     weakness.  The receiving MUA MAY decline to decrypt such a message at
     all.  If it decides to decrypt a message with a weak encryption
     layer, it MUST NOT indicate in the message's Cryptographic Summary
     that the message was encrypted, as the confidentiality of the message
     is suspect.  This is similar to the approach taken in Section 6.2.2
     for messages with an Errant Encryption Layer.

     Like the Errant Encryption Layer situation, there is an asymmetry
     between rendering and replying to a message with weak encryption.
     The guidance in Section 6.2.2.1 should be followed when replying to a
     message with weak encryption as well.

     A receiving MUA MAY also treat historically archived messages with
     weak encryption differently from modern messages.  For example, if an
     encryption algorithm was known to be weak in 2005, then a message
     that appears to have been encrypted with that algorithm in 1995 might
     decrypted with a warning, as an archival service.  But a message that
     appears to have been encrypted with that same weak algorithm in 2015
     might be quarantined as a likely attack.

     There are several possible ways to distinguish a historical message
     from a modern one, including:

     *  The message timestamp (e.g., the Date header field)

     *  The time the message was first observed on the network (e.g.,
        delivery of a new message via IMAP from a mailbox that had
        recently checked)

     *  The timestamp in any signature observed in the message





  Gillmor, et al.           Expires 12 July 2025                 [Page 29]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  The message structure (a message composed using protocol elements
        that were invented after the encryption algorithm was known weak
        is likely to be an attack than a legitimate archival message)

  7.  Reasoning about Message Parts

     When generating or rendering messages, it is useful to know what
     parts of the message are likely to be displayed, and how.  This
     section introduces some common terms that can be applied to parts
     within the Cryptographic Payload.

  7.1.  Main Body Part

     When an e-mail message is composed or rendered to the user there is
     typically one main view that presents a (mostly textual) part of the
     message.

     While the message itself may be constructed of several distinct MIME
     parts in a tree, the part that is rendered to the user is the "Main
     Body Part".

     When rendering a message, one of the primary jobs of the receiving
     MUA is identifying which part (or parts) is the Main Body Part.
     Typically, this is found by traversing the MIME tree of the message
     looking for a leaf node that has a primary content type of text
     (e.g., text/plain or text/html) and is not Content-Disposition:
     attachment.

     MIME tree traversal follows the first child of every multipart node,
     with the exception of multipart/alternative.  When traversing a
     multipart/alternative node, all children should be scanned, with
     preference given to the last child node with a MIME type that the MUA
     is capable of rendering directly.

     An MUA MAY offer the user a mechanism to prefer a particular MIME
     type within multipart/alternative instead of the last renderable
     child.  For example, a user may explicitly prefer a text/plain
     alternative part over text/html.  Note that due to uncertainty about
     the capabilities and configuration of the receiving MUA, a conformant
     composing MUA should consider that multiple parts might be rendered
     as the Main Body Part when the message is ultimately viewed.  In
     particular, the composing MUA should ensure that any part likely to
     be viewed as the Main Body Part has the same semantic content as any
     other such part.

     When composing a message, an originating MUA operating on behalf of
     an active user can identify which part (or parts) are the "main"
     parts: these are the parts the MUA generates from the user's editor.



  Gillmor, et al.           Expires 12 July 2025                 [Page 30]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Tooling that automatically generates e-mail messages should also have
     a reasonable estimate of which part (or parts) are the "main" parts,
     as they can be programmatically identified by the message author.

     For a filtering program that attempts to transform an outbound
     message without any special knowledge about which parts are Main Body
     Parts, it can identify the likely parts by following the same routine
     as a receiving MUA.

  7.2.  Attachments

     A message may contain one or more separated MIME parts that are
     intended for download or extraction.  Such a part is commonly called
     an "attachment", and is commonly identified by having Content-
     Disposition: attachment.

     An MUA MAY identify a subpart as an attachment, or permit extraction
     of a subpart even when the subpart does not have Content-Disposition:
     attachment.

     When generating a message with end-to-end cryptographic protection,
     any attachment MUST be included within the Cryptographic Payload.  If
     an attachment is found outside the Cryptographic Payload, then the
     message is not well-formed (see Section 6.1), and will not be handled
     by other MUAs as intended.

     Some MUAs have tried to compose messages where each attachment is
     placed in its own cryptographic envelope.  Such a message is
     problematic for several reasons:

     *  The attachments can be stripped, replaced, or reordered without
        breaking any cryptographic integrity mechanism.

     *  The resulting message may have a mix of cryptographic statuses
        (e.g., if a signature on one part fails but another succeeds, or
        if one part is encrypted and another is not).  This mix of
        statuses is difficult to represent to the user in a comprehensible
        way.

     *  The divisions between the different attachments are visible to
        operators of any mail transport agent (MTA) that handles the
        message, potentially resulting in a metadata leak.  For example,
        the MTA operator may learn the number of attachments, and the size
        of each attachment.

     These messages are unlikely to be usefully interoperable without
     additional standardization work (see Appendix A.12).




  Gillmor, et al.           Expires 12 July 2025                 [Page 31]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  7.3.  MIME Part Examples

     Consider a common message with the following MIME structure:

     M └─╴application/pkcs7-mime
        ↧ (decrypts to)
     N  └─╴application/pkcs7-mime
         ⇩ (unwraps to)
     O   └┬╴multipart/mixed
     P    ├┬╴multipart/alternative
     Q    │├─╴text/plain
     R    │└─╴text/html
     S    └─╴image/png

     Parts M and N comprise the Cryptographic Envelope.

     Parts Q and R are both Main Body Parts.

     If part S is Content-Disposition: attachment, then it is an
     attachment.  If part S has no Content-Disposition header, it is
     potentially ambiguous whether it is an attachment or not.  If the
     sender prefers a specific behavior, it should explicitly set the
     Content-Disposition header on part S to either inline or attachment
     as guidance to the receiving MUA.

     Consider also this alternate structure:

     M └─╴application/pkcs7-mime
        ↧ (decrypts to)
     N  └─╴application/pkcs7-mime
         ⇩ (unwraps to)
     O   └┬╴multipart/alternative
     P    ├─╴text/plain
     Q    └┬╴multipart/related
     R     ├─╴text/html
     S     └─╴image/png

     In this case, parts M and N still comprise the Cryptographic
     Envelope.

     Parts P and R (the first two leaf nodes within each subtree of part
     O) are the Main Body Parts.

     Part S is more likely not to be an attachment, as the subtree layout
     suggests that it is only relevant for the HTML version of the
     message.  For example, it might be rendered as an image within the
     HTML alternative.




  Gillmor, et al.           Expires 12 July 2025                 [Page 32]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  8.  Certificate Management

     A cryptographically-capable MUA typically maintains knowledge about
     certificates for the user's own account(s), as well as certificates
     for the peers that it communicates with.

  8.1.  Peer Certificates

     Most certificates that a cryptographically-capable MUA will use will
     be certificates belonging to the parties that the user communicates
     with through the MUA.  This section discusses how to manage the
     certificates that belong to such a peer.

     The MUA will need to be able to discover X.509 certificates for each
     peer, cache them, and select among them when composing an encrypted
     message.

     Detailed guidance about how to do this is beyond the scope of this
     document, but future revisions may bring it into scope (see
     Appendix A.3).

  8.1.1.  Peer Certificate Selection

     When composing an encrypted message, the MUA needs to select an
     encryption-capable certificate for each recipient.

     To select such a certificate for a given destination e-mail address,
     the MUA should look through all of its known certificates and verify
     that _all_ of the conditions below are met:

     *  The certificate must be valid, not expired or revoked.

     *  It must have a subjectAltName of type rfc822Name whose contents
        match the destination e-mail address.  In particular, the local-
        part of the two addresses should be an exact bytewise match, and
        the domain parts of the two addresses should be matched by
        ensuring label equivalence across the full domain name, as
        described in Section 2.3.2.4 of [RFC5890].

     *  The algorithm OID in the certificate's SPKI is known to the MUA
        and capable of encryption.  Examples include:

        -  rsaEncryption (OID 1.2.840.113549.1.1.1), with keyUsage (OID
           2.5.29.15) extension present and the "key encipherment" bit
           (value 32) set.

        -  curveX25519 (OID 1.3.101.110) with keyUsage extension present
           and the "key agreement" bit (value 8) set.



  Gillmor, et al.           Expires 12 July 2025                 [Page 33]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  If extendedKeyUsage (OID 2.5.29.37) is present, it contains at
        least one of the following OIDs: e-mail protection (OID
        1.3.6.1.5.5.7.3.4), anyExtendedKeyUsage (OID 2.5.29.37.0).

     A conformant MUA may include more considerations when selecting a
     peer certificate as well, see Appendix A.3.4 for examples.

  8.2.  Local Certificates

     The MUA also needs to know about one or more certificates associated
     with the user's e-mail account.  It is typically expected to have
     access to the secret key material associated with the public keys in
     those certificates.

     While some basic guidance is offered here, it is beyond the scope of
     this document to describe all possible relevant guidance for local
     certificate and key material handling.  See Appendix A.4 for
     suggestions of guidance that a future version might bring into scope.

  8.2.1.  Getting Certificates for the User

     If a conformant MUA does not have any certificate or secret key for
     the user, it should help the user to generate, acquire, or import
     them with a minimum of difficulty.

  8.2.1.1.  User Certificates for S/MIME

     For S/MIME, the user SHOULD have both a signing-capable certificate
     and an encryption-capable certificate (and the corresponding secret
     keys).  Using the same cryptographic key material for multiple
     algorithms (i.e., for both encryption and signing) has been the
     source of vulnerabilities in other (non-e-mail) contexts (e.g.,
     [DROWN] and [IKE]).  The simplest way to avoid any comparable risk is
     to use distinct key material for each cryptographic algorithm.  A
     conformant MUA that generates S/MIME certificates for the user MUST
     generate distinct S/MIME certificates: one for encryption and another
     for signing, to avoid possible cross-protocol key misuse.

     The simplest option for an S/MIME-capable MUA is for the MUA to
     permit the user to import a PKCS #12 ([RFC7292]) object that is
     expected to contain secret key material, end entity certificates for
     the user, and intermediate certification authority certificates that
     permit chaining from the end entity certs to widely-accepted trust
     anchors.  A conformant MUA that imports such a PKCS #12 bundle SHOULD
     warn the user if the bundle contains an S/MIME certificate and
     corresponding secret key where the same secret key is used for both
     encryption and signing.




  Gillmor, et al.           Expires 12 July 2025                 [Page 34]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     An S/MIME-capable MUA that has access to user certificates and their
     corresponding secret key material should also offer the ability to
     export those objects into a well-formed PKCS #12 object that could be
     imported into another MUA operated by the same user.

     Manual handling of PKCS #12 objects is challenging for most users.
     Producing the initial PKCS #12 object typically can only be done with
     the aid of a certification authority via non-standardized, labor-
     intensive, and error-prone procedures that most users do not
     understand.  Furthermore, manual export and import incurs ongoing
     labor (for example, before certificate expiration) by the user which
     most users are unprepared to do (see Section 8.2.2).

     A better approach is for the MUA to integrate some form of automated
     certificate issuance procedure, for example, by using the ACME
     protocol for end user S/MIME certificates ([RFC8823]).

     Another possible approach is integration with a cryptographic
     hardware token or smartcard that can provide certificates and permit
     the use of isolated secret key material, for example [PKCS11], though
     this approach delegates the complexity of acquiring and managing
     certificates to management of the hardware token itself (see
     Appendix A.4.2).

     See also [I-D.woodhouse-cert-best-practice] for more recommendations
     about managing user certificates.

  8.2.1.2.  User Certificates for PGP/MIME

     As distinct from S/MIME, OpenPGP ([RFC9580]) has a different set of
     common practices.  For one thing, a single OpenPGP certificate can
     contain both a signing-capable key and a distinct encryption-capable
     key, so only one certificate is needed for an e-mail user of OpenPGP,
     as long as the certificate has distinct key material for the
     different purposes.

     Furthermore, a single OpenPGP certificate MAY be only self-signed, so
     the MUA can generate such a certificate entirely on its own.

     An OpenPGP-capable MUA should have the ability to import and export
     OpenPGP Tranferable Secret Keys (see Section 10.2 of [RFC9580]), to
     enable manual transfer of user certificates and secret key material
     between multiple MUAs controlled by the user.

     Since an OpenPGP certificate MAY be certified by third parties
     (whether formal certification authorities or merely other well-
     connected peers) the MUA SHOULD offer affordances to help the user
     acquire and merge third party certifications on their certificate.



  Gillmor, et al.           Expires 12 July 2025                 [Page 35]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     When doing this, the MUA should prioritize third-party certifications
     from entities that the user's peers are likely to know about and be
     willing to rely on.

     Since an OpenPGP certificate can grow arbitrarily large with third-
     party certifications, the MUA should assist the user in pruning it to
     ensure that it remains a reasonable size when transmitting it to
     other parties.

  8.2.1.3.  Generate Secret Key Material Locally

     Regardless of protocol used (S/MIME or PGP), when producing
     certificates for the end user, the MUA SHOULD ensure that it has
     generated secret key material locally, and MUST NOT accept secret key
     material from an untrusted external party as the basis for the user's
     certificate.  For example, a user who trusts their system
     administrator not to compromise their MUA may accept secret key
     material generated by the sysadmin, but probably should not accept
     secret key material generated by an unaffiliated online web service.

     An MUA that accepts secret key material from a third party cannot
     prevent that third party from retaining this material.  A third party
     with this level of access could decrypt messages intended to be
     confidential for the user, or could forge messages that would appear
     to come from the user.

  8.2.2.  Local Certificate Maintenance

     In the context of a single e-mail account managed by an MUA, where
     that e-mail account is expected to be able to use end-to-end
     cryptographic protections, the MUA SHOULD warn the user (or
     proactively fix the problem) when/if:

     *  For S/MIME, the user's own certificate set for the account does
        not include a valid, unexpired encryption-capable X.509
        certificate, and a valid, unexpired signature-capable X.509
        certificate.

     *  For PGP/MIME, the user's own certificate does not include a valid,
        unexpired signing-capable key/subkey and a valid, unexpired
        encryption-capable key/subkey.

     *  Any of the user's own certificates for the account:

        -  is due to expire in the next month (or at some other reasonable
           cadence).





  Gillmor, et al.           Expires 12 July 2025                 [Page 36]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


        -  not match the e-mail address associated with the account in
           question.

     *  Any of the user's own S/MIME certificates for the account:

        -  does not have a keyUsage extension.

        -  does not contain an extendedKeyUsage extension.

        -  would be considered invalid by the MUA for any other reason if
           it were a peer certificate.

     An MUA that takes active steps to fix any of these problems before
     they arise is even more usable than just warning, but guidance on how
     to do active certificate maintenance is beyond scope for this current
     document (see Appendix A.4.3).

     If the MUA does find any of these issues and chooses to warn the
     user, it should use one aggregate warning with simple language that
     the certificates might not be acceptable for other people, and
     recommend a course of action that the user can take to remedy the
     problem.

  8.2.3.  Shipping Certificates in Outbound Messages

     When sending mail, a conformant MUA SHOULD include copies of the
     user's own certificates (and potentially other certificates) in each
     message to facilitate future communication, unless it has specific
     knowledge that the other parties involved already know the relevant
     keys (for example, if it is mail between members within a domain that
     has a synchronized and up-to-date certificate directory).

     The mechanism for including these certificates, and which
     certificates to include in the message, are protocol specific.

  8.2.3.1.  Shipping Certificates in S/MIME Messages

     In any S/MIME SignedData object, certificates can be shipped in the
     "certificates" member.  In S/MIME EnvelopedData object, certificates
     can be shipped in the "originatorInfo.certs" member.

     When a single S/MIME-protected e-mail message is encrypted and
     signed, it is usually sufficient to ship all the relevant
     certificates in the inner SignedData object's "certificates" member.

     The S/MIME certificates shipped in such a message SHOULD include:





  Gillmor, et al.           Expires 12 July 2025                 [Page 37]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  The user's own S/MIME signing certificate, so that signature on
        the current message can be validated.

     *  The user's own S/MIME encryption-capable certificate, so that the
        recipient can reply in encrypted form.

     *  On an encrypted message to multiple recipients, the encryption-
        capable peer certificates of the other recipients, so that any
        recipient can easily "reply all" without needing to search for
        certificates.

     *  Any intermediate CA certificates needed to chain all of the above
        to a widely-trusted set of root authorities.

  8.2.3.2.  Shipping Certificates in PGP/MIME Messages

     PGP/MIME does not have a single specific standard location for
     shipping certificates.

     Some MUAs ship relevant OpenPGP certificates in a single MIME leaf of
     Content-Type "application/pgp-keys".  When such a message has
     cryptographic protections, to ensure that the message is well-formed,
     this kind of MIME part SHOULD be a leaf of the Cryptographic Payload,
     and not outside of it.  One problem with this approach is that it
     appears to recipients with non-cryptographic MUAs as an "attachment",
     which can lead to confusion if the user does not know how to use it.

     Other implementations ship relevant OpenPGP certificates in
     "Autocrypt" or "Autocrypt-Gossip" message header fields (see
     [AUTOCRYPT]).  To ensure that those header fields receive the same
     cryptographic authenticity as the rest of the message, these header
     fields SHOULD be protected as described in
     [I-D.ietf-lamps-header-protection].

     The OpenPGP certificates shipped in such a message SHOULD include:

     *  The user's own OpenPGP certificate, capable of both signing and
        encryption, so that the user can validate the message's signature
        and can encrypt future messages

     *  On an encrypted message to multiple recipients, the OpenPGP
        certificates of the other recipients, so that any recipient can
        easily "reply all" without needing to search for certificates.

  9.  Common Pitfalls and Guidelines

     This section highlights a few "pitfalls" and guidelines based on
     these discussions and lessons learned.



  Gillmor, et al.           Expires 12 July 2025                 [Page 38]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  9.1.  Reading Sent Messages

     When sending a message, a typical MUA will store a copy of the
     message sent in sender's Sent mail folder so that the sender can read
     it later.  If the message is an encrypted message, storing it
     encrypted requires some forethought to ensure that the sender can
     read it in the future.

     It is a common and simple practice to encrypt the message not only to
     the recipients of the message, but also to the sender.  One advantage
     of doing this is that the message that is sent on the wire can be
     identical to the message stored in the sender's Sent mail folder.
     This allows the sender to review and re-read the message even though
     it was encrypted.

     There are at least three other approaches that are possible to ensure
     future readability by the sender of the message, but with different
     tradeoffs:

     *  Encrypt two versions of the message: one to the recipients (this
        version is sent on the wire), and one to the sender only (this
        version is stored in the sender's Sent folder).  This approach
        means that the message stored in the Sent folder is not byte-for-
        byte identical to the message sent to the recipients.  In the
        event that message delivery has a transient failure, the MUA
        cannot simply re-submit the stored message into the SMTP system
        and expect it to be readable by the recipient.

     *  Store a cleartext version of the message in the Sent folder.  This
        presents a risk of information leakage: anyone with access to the
        Sent folder can read the contents of the message.  Furthermore,
        any attempt to re-send the message needs to also re-apply the
        cryptographic transformation before sending, or else the message
        contents will leak upon re-send.  A conformant MUA SHOULD NOT
        store a cleartext copy in the Sent folder unless it knows that the
        Sent folder cannot be read by an attacker.  For example, if end-
        to-end confidentiality is desired, then storing the cleartext in
        an IMAP folder where a potentially adversarial server can read it
        defeats the purpose.

     *  A final option is that the MUA can store a copy of the message's
        encryption session key.  Standard e-mail encryption mechanisms
        (e.g., S/MIME and PGP/MIME) are hybrid mechanisms: the asymmetric
        encryption steps simply encrypt a symmetric "session key", which
        is used to encrypt the message itself.  If the MUA stores the
        session key itself, it can use the session key to decrypt the Sent
        message without needing the Sent message to be decryptable by the
        user's own asymmetric key.  An MUA doing this must take care to



  Gillmor, et al.           Expires 12 July 2025                 [Page 39]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


        store (and backup) its stash of session keys, because if it loses
        them it will not be able to read the sent messages; and if someone
        else gains access to them, they can decrypt the sent messages.
        This has the additional consequence that any other MUA accessing
        the same Sent folder cannot decrypt the message unless it also has
        access to the stashed session key.

  9.2.  Reading Encrypted Messages after Certificate Expiration

     When encrypting a message, the sending MUA should decline to encrypt
     to an expired certificate (see Section 8.1.1).  But when decrypting a
     message, as long as the viewing MUA has access to the appropriate
     secret key material, it should permit decryption of the message, even
     if the associated certificate is expired.  That is, the viewing MUA
     should not prevent the user from reading a message that they have
     already received.

     The viewing MUA may warn the user when decrypting a message that
     appears to have been encrypted to an encryption-capable certificate
     that was expired at the time of encryption (e.g., based on the Date:
     header field of the message, or the timestamp in the cryptographic
     signature), but otherwise should not complain.

     The primary goal of certificate expiration is to facilitate rotation
     of secret key material, so that secret key material does not need to
     be retained indefinitely.  Certificate expiration permits the user to
     destroy an older secret key if access to the messages received under
     it is no longer necessary (see also Appendix A.10).

  9.3.  Unprotected Message Header Fields

     Many legacy cryptographically-aware MUAs only apply cryptographic
     protections to the body of the message, but leave the header fields
     unprotected.  This gives rise to vulnerabilities like information
     leakage (e.g., the Subject line is visible to a passive intermediary)
     or message tampering (e.g., the Subject line is replaced, effectively
     changing the semantics of a signed message).  These are not only
     security vulnerabilities, but usability problems, because the
     distinction between what is a header and what is the body of a
     message is unclear to many end users, and requires a more complex
     mental model than is necessary.  Useful security comes from alignment
     between simple mental models and tooling.

     To avoid these concerns, a conformant MUA MUST implement header
     protection as described in [I-D.ietf-lamps-header-protection].






  Gillmor, et al.           Expires 12 July 2025                 [Page 40]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Note that some message header fields, like List-*, Archived-At, and
     Resent-* are typically added by an intervening MUA (see Section 9.8),
     not by one of the traditional "ends" of an end-to-end e-mail
     exchange.  A receiving MUA may choose to consider the contents of
     these header fields on an end-to-end protected message as markers
     added during message transit, even if they are not covered by the
     end-to-end cryptographic protection.

  9.4.  Composing an Encrypted Message with Bcc

     When composing an encrypted message containing at least one recipient
     address in the Bcc header field, there is a risk that the encrypted
     message itself could leak information about the actual recipients,
     even if the Bcc header field does not mention the recipient.  For
     example, if the message clearly indicates which certificates it is
     encrypted to, the set of certificates can identify the recipients
     even if they are not named in the message header fields.

     Because of these complexities, there are several interacting factors
     that need to be taken into account when composing an encrypted
     message with Bcc'ed recipients.

     *  Section 3.6.3 of [RFC5322] describes a set of choices about
        whether (and how) to populate the Bcc field explicitly on Bcc'ed
        copies of the message, and in the copy stored in the sender's Sent
        folder.

     *  When separate copies are made for Bcced recipients, should each
        separate copy _also_ be encrypted to the named recipients, or just
        to the designated Bcc recipient?

     *  When a copy is stored in the Sent folder, should that copy also be
        encrypted to Bcced recipients? (see also Section 9.1)

     *  When a message is encrypted, if there is a mechanism to include
        the certificates of the recipients, whose certificates should be
        included?

  9.4.1.  Simple Encryption with Bcc

     Here is a simple approach that tries to minimize the total number of
     variants of the message created while leaving a coherent view of the
     message itself:

     *  No cryptographic payload contains any Bcc header field.






  Gillmor, et al.           Expires 12 July 2025                 [Page 41]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  The main copy of the message is signed and encrypted to all named
        recipients and to the sender.  A copy of this message is also
        stored in the sender's Sent folder.

     *  Each Bcc recipient receives a distinct copy of the message, with
        an identical cryptographic payload, and the message is signed and
        encrypted to that specific recipient and all the named recipients.
        These copies are not stored in the sender's Sent folder.

     *  Any Bcc'ed recipient MUST NOT be taken into consideration when
        determining which certificates to include in the message.  In
        particular, certificates for Bcc'ed recipients MUST NOT included
        in any message.

  9.4.1.1.  Rationale

     The approach described in Section 9.4.1 aligns the list of
     cryptographic recipients as closely as possible with the set of named
     recipients, while still allowing a Bcced recipient to read their own
     copy, and to "Reply All" should they want to.

     This should reduce user confusion on the receiving side: a recipient
     of such a message who naively looks at the user-facing header fields
     from their own mailbox will have a good sense of what cryptographic
     treatments have been applied to the message.  It also simplifies
     message composition and user experience: the message composer sees
     fields that match their expectations about what will happen to the
     message.  Additionally, it may preserve the ability for a Bcc'ed
     recipient to retain their anonymity, should they need to offer the
     signed cryptographic payload to an outside party as proof of the
     original sender's intent without revealing their own identity.

  9.5.  Draft Messages

     When composing a message, most MUAs will save a copy of the as-yet-
     unsent message to a "Drafts" folder.  If that folder is itself stored
     somewhere not under the user's control (e.g., an IMAP mailbox), it
     would be a mistake to store the draft message in the clear, because
     its contents could leak.

     This is the case even if the message is ultimately sent deliberately
     in the clear.  During message composition, the MUA does not know
     whether the message is intended to be sent encrypted or not.  For
     example, just before sending, the sender could decide to encrypt the
     message, and the MUA would have had no way of knowing.






  Gillmor, et al.           Expires 12 July 2025                 [Page 42]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     The MUA SHOULD encrypt all draft messages, unless it has explicit
     knowledge that the message will not be encrypted when sent, or that
     the Drafts folder cannot be read by an attacker.  For example, if
     end-to-end confidentiality is desired, then storing a cleartext draft
     in an IMAP folder where a potentially adversarial server can read it
     defeats the purpose.

     Furthermore, when encrypting a draft message, the message draft MUST
     only be encrypted to the user's own certificate, or to some
     equivalent secret key that only the user possesses.  A draft message
     encrypted in this way can be decrypted when the user wants to resume
     composing the message, but cannot be read by anyone else, including a
     potential intended recipient.  Note that a draft message encrypted in
     this way will only be resumable by another MUA attached to the same
     mailbox if that other MUA has access to the user's decryption-capable
     secret key.  This shared access to key material is also likely
     necessary for useful interoperability, but is beyond the scope of
     this document (see Appendix A.4.1).

     A conformant MUA MUST NOT sign a message draft with the user's normal
     signing key.  If draft signing is intended for cryptographic
     coordination between multiple MUAs of the same user, it should be
     negotiated with a different key (but see Appendix A.4.1).

     The message should only be encrypted to its recipients upon actually
     sending the message.  No reasonable user expects their message's
     intended recipients to be able to read a message that is not yet
     complete.

  9.6.  Composing a Message to Heterogeneous Recipients

     When sending a message that the user intends to be encrypted, it's
     possible that some recipients will be unable to receive an encrypted
     copy.  For example, when Carol composes a message to Alice and Bob,
     Carol's MUA may be able to find a valid encryption-capable
     certificate for Alice, but none for Bob.

     In this situation, there are four possible strategies, each of which
     has a negative impact on the experience of using encrypted mail.
     Carol's MUA can:

     1.  send encrypted to Alice and Bob, knowing that Bob will be unable
         to read the message.

     2.  send encrypted to Alice only, dropping Bob from the message
         recipient list.

     3.  send the message in the clear to both Alice and Bob.



  Gillmor, et al.           Expires 12 July 2025                 [Page 43]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     4.  send an encrypted copy of the message to Alice, and a cleartext
         copy to Bob.

     Each of these strategies has different drawbacks.

     The problem with approach 1 is that Bob will receive unreadable mail.

     The problem with approach 2 is that Carol's MUA will not send the
     message to Bob, despite Carol asking it to.

     The problem with approach 3 is that Carol's MUA will not encrypt the
     message, despite Carol asking it to.

     Approach 4 has two problems:

     *  Carol's MUA will release a cleartext copy of the message, despite
        Carol asking it to send the message encrypted.

     *  If Alice wants to "reply all" to the message, she may not be able
        to find an encryption-capable certificate for Bob either.  This
        puts Alice in an awkward and confusing position, one that users
        are unlikely to understand.  In particular, if Alice's MUA is
        following the guidance about replies to encrypted messages in
        Section 5.4, having received an encrypted copy will make Alice's
        Reply buffer behave in an unusual fashion.

     This is particularly problematic when the second recipient is not
     "Bob" but in fact a public mailing list or other visible archive,
     where messages are simply never encrypted.

     Carol is unlikely to understand the subtleties and negative
     downstream interactions involved with approaches 1 and 4, so
     presenting the user with those choices is not advised.

     The most understandable approach for an MUA with an active user is to
     ask the user (when they hit "send") to choose between approach 2 and
     approach 3.  If the user declines to choose between 2 and 3, the MUA
     can drop them back to their message composition window and let them
     make alternate adjustments.

     See also further discussion of these scenarios in
     [I-D.dkg-mail-cleartext-copy].









  Gillmor, et al.           Expires 12 July 2025                 [Page 44]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  9.7.  Message Transport Protocol Proxy: A Dangerous Implementation
        Choice

     An implementer of end-to-end cryptographic protections may be tempted
     by a simple software design that piggybacks off of a mail protocol
     like SMTP Submission ([RFC6409]), IMAP ([RFC9051]), or JMAP
     ([RFC8621]) to handle message assembly and interpretation.  In such
     an architecture, a naive MUA speaks something like a "standard"
     protocol like SMTP, IMAP, or JMAP to a local proxy, and the proxy
     handles signing and encryption (outbound), and decryption and
     verification (inbound) internally on behalf of the user.  While such
     a "pluggable" architecture has the advantage that it is likely to be
     easy to apply to any mail user agent, it is problematic for the goals
     of end-to-end communication, especially in an existing cleartext
     ecosystem like e-mail, where any given message might be unsigned or
     signed, cleartext or encrypted.  In particular:

     *  the user cannot easily and safely identify what protections any
        particular message has (including messages currently being
        composed), and

     *  the proxy itself is unaware of subtle nuances about the message
        that the MUA actually knows.

     With a trustworthy and well-synchronized sidechannel or protocol
     extension between the MUA and the proxy, it is possible to deploy
     such an implementation safely, but the requirement for the
     sidechannel or extension eliminates the universal-deployability
     advantage of the scheme.

     Similar concerns apply to any implementation bound by an API which
     operates on message objects alone, without any additional contextual
     parameters.

     This section attempts to document some of the inherent risks involved
     with such an architecture.

  9.7.1.  Dangers of a Submission Proxy for Message Composition

     When composing and sending a message, the act of applying
     cryptographic protections has subtleties that cannot be directly
     expressed in the SMTP protocol used by Submission [RFC6409], or in
     any other simple protocol that hands off a cleartext message for
     further processing.







  Gillmor, et al.           Expires 12 July 2025                 [Page 45]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     For example, the sender cannot indicate via SMTP whether or not a
     given message _should_ be encrypted (some messages, like those sent
     to a publicly archived mailing list, are pointless to encrypt), or
     select among multiple certificates for a recipient, if they exist
     (see Section 8.1.1).

     Likewise, because such a proxy only interacts with the message when
     it is ready to be sent, it cannot indicate back to the user _during
     message composition_ whether or not the message is able to be
     encrypted (that is, whether a valid certificate is available for each
     intended recipient).  A message author may write an entirely
     different message if they know that it will be protected end-to-end;
     but without this knowledge, the author is obliged either to write
     text that they presume will be intercepted, or to risk revealing
     sensitive content.

     Even without encryption, deciding whether to sign or not (and which
     certificate to sign with, if more than one exists) is another choice
     that the proxy is ill-equipped to make.  The common message-signing
     techniques either render a message unreadable by any non-
     cryptographic MUA (i.e., PKCS7 signed-data), or appear as an
     attachment that can cause confusion to a naive recipient using a non-
     cryptographic MUA (i.e., multipart/signed).  If the sender knows that
     the recipient will not check signatures, they may prefer to leave a
     cleartext message without a cryptographic signature at all.

     Furthermore, handling encryption properly depends on the context of
     any given message, which cannot be expressed by the MUA to the
     Submission proxy.  For example, decisions about how to handle
     encryption and quoted or attributed text may depend on the
     cryptographic status of the message that is being replied to (see
     Section 5.4).

     Additionally, such a proxy would need to be capable of managing the
     user's own key and certificate (see Section 8.2).  How will the
     implementation indicate to the user when their own certificate is
     near expiry, for example?  How will any other error conditions be
     handled when communication with the user is needed?

     While an extension to SMTP might be able to express all the necessary
     semantics that would allow a generic MUA to compose messages with
     standard cryptographic protections via a proxy, such an extension is
     beyond the scope of this document.  See
     [I-D.ietf-jmap-smime-sender-extensions] for an example of how an MUA
     using a proxy protocol might indicate signing and encryption
     instructions to its proxy.





  Gillmor, et al.           Expires 12 July 2025                 [Page 46]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  9.7.2.  Dangers of an IMAP Proxy for Message Rendering

     When receiving and rendering a message, the process of indicating to
     the user the cryptographic status of a message requires subtleties
     that are difficult to offer from a straightforwad IMAP (or POP
     [RFC1939], or JMAP) proxy.

     One approach such a proxy could take is to remove all the
     Cryptographic Layers from a well-formed message, and to package a
     description of those layers into a special header field that the MUA
     can read.  But this merely raises the question: what semantics need
     to be represented?  For example:

     *  Was the message signed?  If so, by whom?  When?

     *  Should the details of the cryptographic algorithms used in any
        signatures found be indicated as well?

     *  Was the message encrypted?  if so, to whom?  What key was used to
        decrypt it?

     *  If both signed and encrypted, was the signing outside the
        encryption or inside?

     *  How should errant Cryptographic Layers (see Section 4.5) be dealt
        with?

     *  What cryptographic protections do the header fields of the message
        have? (see [I-D.ietf-lamps-header-protection])

     *  How are any errors or surprises communicated to the user?

     If the proxy passes any of this cryptographic status to the client in
     an added header field, it must also ensure that no such header field
     is present on the messages it receives before processing it.  If it
     were to allow such a header field through unmodified to any client
     that is willing to trust its contents, an attacker could spoof the
     field to make the user believe lies about the cryptographic status of
     the message.  In order for an MUA to be confident in such a header
     field, then, it needs a guarantee from the proxy that any header it
     produces will be safe.  How does the MUA reliably negotiate this
     guarantee with the proxy?  If the proxy can no longer offer this
     guarantee, how will the MUA know that things have changed?

     If such an inbound proxy handles certificate discovery in inbound
     messages (see Appendix A.3.1), it will also need to communicate the
     results of that discovery process to its corresponding outbound proxy
     for message composition (see Section 9.7.1).



  Gillmor, et al.           Expires 12 July 2025                 [Page 47]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     While an extension to IMAP (or POP, or JMAP) might be able to express
     all the necessary semantics that would allow a generic MUA to
     indicate standardized cryptographic message status, such an extension
     is beyond the scope of this document.  [RFC9219] describes S/MIME
     signature verification status over JMAP, which is a subset of the
     cryptographic status information described here.

  9.7.3.  Who Controls the Proxy?

     Finally, consider that the naive proxy deployment approach is risky
     precisely because of its opacity to the end user.  Such a deployment
     could be placed anywhere in the stack, including on a machine that is
     not ultimately controlled by the end user, making it effectively a
     form of transport protection, rather than end-to-end protection.

     An MUA explicitly under the control of the end user with thoughtful
     integration can offer UI/UX and security guarantees that a simple
     proxy cannot provide.  See also Appendix A.13 for suggestions of
     future work that might augment a proxy to make it safer.

  9.8.  Intervening MUAs Do Not Handle End-to-End Cryptographic
        Protections

     Some Mail User Agents (MUAs) will resend a message in identical form
     (or very similar form) to the way that they received it.  For
     example, consider the following use cases:

     *  A mail expander or mailing list that receives a message and re-
        sends it to all subscribers (see also Appendix A.14 for more
        discussion of mailing lists).

     *  An individual user who reintroduces a message they received into
        the mail transport system (see Section 3.6.6 of [RFC5322]).

     *  An automated e-mail intake system that forwards a report to the
        mailboxes of responsible staffers.

     These MUAs intervene in message transport by receiving and then re-
     injecting messages into the mail transport system.  In some cases,
     the original sender or final recipient of a message that has passed
     through such an MUA may be unaware of the intervention.  (Note that
     an MUA that forwards a received message as a attachment (MIME
     subpart) of type message/rfc822 or message/global or "inline" in the
     body of a message is _not_ acting as an intervening MUA in this
     sense, because the forwarded message is encapsulated within a visible
     outer message that is clearly from the MUA itself.)





  Gillmor, et al.           Expires 12 July 2025                 [Page 48]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     An intervening MUA should be aware of end-to-end cryptographic
     protections that might already exist on messages that they re-send.
     In particular, it is unclear what the "end-to-end" properties are of
     a message that has been handled by an intervening MUA.  For signed-
     only messages, if the intervening MUA makes any substantive
     modifications to the message as it passes it along, it may break the
     signature from the original sender.  In many cases, breaking the
     original signature is the appropriate result, since the original
     message has been modified, and the original sender has no control
     over the modifications made by the intervening MUA.  For encrypted-
     and-signed messages, if the intervening MUA is capable of decrypting
     the message, it must be careful when re-transmitting the message.
     Will the new recipient be able to decrypt it?  If not, will the
     message be useful to the recipient?  If not, it may not make sense to
     re-send the message.

     Beyond the act of re-sending, an intervening MUA should not itself
     try to apply end-to-end cryptographic protections on a message that
     it is resending unless directed otherwise by some future
     specification.  Additional layers of cryptographic protection added
     in an ad-hoc way by an intervening MUA are more likely to confuse the
     recipient and will not be interpretable as end-to-end protections as
     they do not originate with the original sender of the message.

  9.9.  External Subresources in MIME Parts Break Cryptographic
        Protections

     A MIME part with a content type that can refer to external resources
     (like text/html) may itself have some sort of end-to-end
     cryptographic protections.  However, retrieving or rendering these
     external resources may violate the properties that users expect from
     cryptographic protection.

     As a baseline, retrieving the external resource at the time a message
     is read can be used as a "web bug", leaking the activity and network
     location of the receiving user to the server hosting the external
     resource.  This privacy risk is present, of course, even for messages
     with no cryptographic protections, but may be even more surprising to
     users who are shown some level of security indicator about a given
     message.

     Other problems with external resources are more specifically bound to
     cryptographic protections.

     For example, an signed e-mail message with at text/html part that
     refers to an external image (i.e., via <img src="https://example.com/
     img.png">) may render differently if the hosting webserver decides to
     serve different content at the source URL for the image.  This



  Gillmor, et al.           Expires 12 July 2025                 [Page 49]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     effectively breaks the goals of integrity and authenticity that the
     user should be able to rely on for signed messages, unless the
     external subresource has strict integrity guarantees (e.g., via
     [SRI]).

     Likewise, fetching an external subresource for an encrypted-and-
     signed message effectively breaks goals of privacy and
     confidentiality for the user.

     This is loosely analogous to security indicator problems that arose
     for web browsers as described in [mixed-content].  However, while
     fetching the external subresource over https is sufficient to avoid a
     "mixed content" warning from most browsers, it is insufficicent for
     an MUA that wants to offer its users true end-to-end guarantees for
     e-mail messages.

     A conformant sending MUA that applies signing-only cryptographic
     protection to a new e-mail message with an external subresource
     should take one of the following options:

     *  pre-fetch the external subresource and include it in the message
        itself,

     *  use a strong integrity mechanism like Subresource Integrity
        ([SRI]) to guarantee the content of the subresource (though this
        does not fix the "web bug" privacy risk described above), or

     *  prompt the composing user to remove the subresource from the
        message.

     A conformant sending MUA that applies encryption to a new e-mail
     message with an external resource cannot depend on subresource
     integrity to protect the privacy and confidentiality of the message,
     so it should either pre-fetch the external resource to include it in
     the message, or prompt the composing user to remove it before
     sending.

     A conformant receiving MUA that encounters a message with end-to-end
     cryptographic protections that contain a subresource MUST either
     refuse to retrieve and render the external subresource, or it should
     decline to treat the message as having cryptographic protections.
     For example, it could indicate in the Cryptographic Summary that the
     message is Unprotected.

     Note that when composing a message reply with quoted text from the
     original message, if the original message did contain an external
     resource, the composing MUA SHOULD NOT fetch the external resource
     solely to include it in the reply message, as doing so would trigger



  Gillmor, et al.           Expires 12 July 2025                 [Page 50]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     the "web bug" at reply composition time.  Instead, the safest way to
     deal with quoted text that contains an external resource in an end-
     to-end encrypted reply is to strip any reference to the external
     resource during initial composition of the reply.

  10.  IANA Considerations

     This document does not require anything from IANA.

  11.  Security Considerations

     This entire document addresses security considerations about end-to-
     end cryptographic protections for e-mail messages.

  12.  Acknowledgements

     The set of constructs and recommendations in this document are
     derived from discussions with many different implementers, including
     Bjarni Rúnar Einarsson, Daniel Huigens, David Bremner, Deb Cooley,
     Eliot Lear, Fabian Ising, Heiko Schaefer, Holger Krekel, Jameson
     Rollins, John Levine, Jonathan Hammell, juga, Patrick Brunschwig,
     Paul Kyzivat, Pete Resnick, Roman Danyliw, Santosh Chokhani, Stephen
     Farrell, Thore Göbel, and Vincent Breitmoser.

  13.  References

  13.1.  Normative References

     [I-D.ietf-lamps-header-protection]
                Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header
                Protection for Cryptographically Protected E-mail", Work
                in Progress, Internet-Draft, draft-ietf-lamps-header-
                protection-25, 6 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
                header-protection-25>.

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

     [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
                "MIME Security with OpenPGP", RFC 3156,
                DOI 10.17487/RFC3156, August 2001,
                <https://www.rfc-editor.org/rfc/rfc3156>.






  Gillmor, et al.           Expires 12 July 2025                 [Page 51]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
                Extensions (MIME) Part Four: Registration Procedures",
                BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
                <https://www.rfc-editor.org/rfc/rfc4289>.

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, DOI 10.17487/RFC5890, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5890>.

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

     [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
                Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
                Message Specification", RFC 8551, DOI 10.17487/RFC8551,
                April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

  13.2.  Informative References

     [AUTOCRYPT]
                Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt
                - Convenient End-to-End Encryption for E-Mail", July 2018,
                <https://autocrypt.org/>.

     [chrome-indicators]
                Schechter, E., "Evolving Chrome's security indicators",
                May 2018, <https://blog.chromium.org/2018/05/evolving-
                chromes-security-indicators.html>.

     [DROWN]    Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
                Dankel, M., Steube, J., Valenta, L., Adrian, D.,
                Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S.,
                Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS
                using SSLv2", March 2016, <https://drownattack.com/>.

     [EFAIL]    Poddebniak, D., Dresen, C., Müller, J., Ising, F.,
                Schinzel, S., Friedberger, S., Somorovsky, J., and J.
                Schwenk, "Efail: breaking S/MIME and OpenPGP email
                encryption using exfiltration channels", August 2018,
                <https://efail.de>.









  Gillmor, et al.           Expires 12 July 2025                 [Page 52]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     [I-D.dkg-mail-cleartext-copy]
                Gillmor, D. K., "Encrypted E-mail with Cleartext Copies",
                Work in Progress, Internet-Draft, draft-dkg-mail-
                cleartext-copy-01, 21 February 2023,
                <https://datatracker.ietf.org/doc/html/draft-dkg-mail-
                cleartext-copy-01>.

     [I-D.ietf-jmap-smime-sender-extensions]
                Melnikov, A., "JMAP extension for S/MIME signing and
                encryption", Work in Progress, Internet-Draft, draft-ietf-
                jmap-smime-sender-extensions-04, 3 August 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-jmap-
                smime-sender-extensions-04>.

     [I-D.koch-openpgp-webkey-service]
                Koch, W., "OpenPGP Web Key Directory", Work in Progress,
                Internet-Draft, draft-koch-openpgp-webkey-service-19, 5
                December 2024, <https://datatracker.ietf.org/doc/html/
                draft-koch-openpgp-webkey-service-19>.

     [I-D.woodhouse-cert-best-practice]
                Woodhouse, D. and N. Mavrogiannopoulos, "Recommendations
                for applications using X.509 client certificates", Work in
                Progress, Internet-Draft, draft-woodhouse-cert-best-
                practice-01, 25 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-woodhouse-
                cert-best-practice-01>.

     [I-D.wussler-openpgp-forwarding]
                Wussler, A., "Automatic Forwarding for ECDH Curve25519
                OpenPGP messages", Work in Progress, Internet-Draft,
                draft-wussler-openpgp-forwarding-00, 10 July 2023,
                <https://datatracker.ietf.org/doc/html/draft-wussler-
                openpgp-forwarding-00>.

     [IKE]      Felsch, D., Grothe, M., Schwenk, J., Czubak, A., and M.
                Szymane, "The Dangers of Key Reuse: Practical Attacks on
                IPsec IKE", August 2018,
                <https://www.usenix.org/system/files/conference/
                usenixsecurity18/sec18-felsch.pdf>.

     [mixed-content]
                "Mixed Content", February 2023,
                <https://www.w3.org/TR/mixed-content/>.

     [ORACLE]   Ising, F., Poddebniak, D., Kappert, T., Saatjohann, C.,
                and S. Schinzel, "Content-Type: multipart/oracle Tapping
                into Format Oracles in Email End-to-End Encryption",



  Gillmor, et al.           Expires 12 July 2025                 [Page 53]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


                August 2023,
                <https://www.usenix.org/conference/usenixsecurity23/
                presentation/ising>.

     [PKCS11]   Bong, D. and T. Cox, "PKCS", 23 July 2023,
                <https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/
                pkcs11-spec-v3.1-os.html>.

     [REPLY]    Müller, J., Brinkmann, M., Poddebniak, D., Schinzel, S.,
                and J. Schwenk, "Re: What’s Up Johnny?: Covert Content
                Attacks on Email End-to-End Encryption", Springer
                International Publishing, Lecture Notes in Computer
                Science pp. 24-42, DOI 10.1007/978-3-030-21568-2_2,
                ISBN ["9783030215675", "9783030215682"], 2019,
                <https://doi.org/10.1007/978-3-030-21568-2_2>.

     [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
                STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
                <https://www.rfc-editor.org/rfc/rfc1939>.

     [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
                <https://www.rfc-editor.org/rfc/rfc2045>.

     [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
                Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
                February 2002, <https://www.rfc-editor.org/rfc/rfc3207>.

     [RFC3274]  Gutmann, P., "Compressed Data Content Type for
                Cryptographic Message Syntax (CMS)", RFC 3274,
                DOI 10.17487/RFC3274, June 2002,
                <https://www.rfc-editor.org/rfc/rfc3274>.

     [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
                Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
                <https://www.rfc-editor.org/rfc/rfc3370>.

     [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
                Protocol (LDAP): The Protocol", RFC 4511,
                DOI 10.17487/RFC4511, June 2006,
                <https://www.rfc-editor.org/rfc/rfc4511>.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                DOI 10.17487/RFC5322, October 2008,
                <https://www.rfc-editor.org/rfc/rfc5322>.





  Gillmor, et al.           Expires 12 July 2025                 [Page 54]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     [RFC5355]  Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S.,
                and M. Holdrege, "Threats Introduced by Reliable Server
                Pooling (RSerPool) and Requirements for Security in
                Response to Threats", RFC 5355, DOI 10.17487/RFC5355,
                September 2008, <https://www.rfc-editor.org/rfc/rfc5355>.

     [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
                "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
                RFC 6376, DOI 10.17487/RFC6376, September 2011,
                <https://www.rfc-editor.org/rfc/rfc6376>.

     [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
                STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
                <https://www.rfc-editor.org/rfc/rfc6409>.

     [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
                and M. Scott, "PKCS #12: Personal Information Exchange
                Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
                <https://www.rfc-editor.org/rfc/rfc7292>.

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

     [RFC7929]  Wouters, P., "DNS-Based Authentication of Named Entities
                (DANE) Bindings for OpenPGP", RFC 7929,
                DOI 10.17487/RFC7929, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7929>.

     [RFC8162]  Hoffman, P. and J. Schlyter, "Using Secure DNS to
                Associate Certificates with Domain Names for S/MIME",
                RFC 8162, DOI 10.17487/RFC8162, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8162>.

     [RFC8621]  Jenkins, N. and C. Newman, "The JSON Meta Application
                Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621,
                August 2019, <https://www.rfc-editor.org/rfc/rfc8621>.

     [RFC8823]  Melnikov, A., "Extensions to Automatic Certificate
                Management Environment for End-User S/MIME Certificates",
                RFC 8823, DOI 10.17487/RFC8823, April 2021,
                <https://www.rfc-editor.org/rfc/rfc8823>.

     [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
                Access Protocol (IMAP) - Version 4rev2", RFC 9051,
                DOI 10.17487/RFC9051, August 2021,
                <https://www.rfc-editor.org/rfc/rfc9051>.




  Gillmor, et al.           Expires 12 July 2025                 [Page 55]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     [RFC9216]  Gillmor, D. K., Ed., "S/MIME Example Keys and
                Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9216>.

     [RFC9219]  Melnikov, A., "S/MIME Signature Verification Extension to
                the JSON Meta Application Protocol (JMAP)", RFC 9219,
                DOI 10.17487/RFC9219, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9219>.

     [RFC9580]  Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
                "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
                <https://www.rfc-editor.org/rfc/rfc9580>.

     [SPOOFING] Müller, J., Brinkmann, M., Poddebniak, D., Böck, H.,
                Schinzel, S., Somorovsky, J., and J. Schwenk, "“Johnny,
                you are fired!” – Spoofing OpenPGP and S/MIME Signatures
                in Emails", August 2019,
                <https://www.usenix.org/system/files/sec19-muller.pdf>.

     [SRI]      "Subresource Integrity", June 2016,
                <https://www.w3.org/TR/SRI/>.

  Appendix A.  Future Work

     This document contains useful guidance for MUA implementers, but it
     cannot contain all possible guidance.  Future revisions to this
     document may want to further explore the following topics, which are
     out of scope for this version.

  A.1.  Webmail Threat Model

     The webmail threat model for end-to-end cryptographic protections is
     significantly more complex than the traditional MUA model.  For
     example, the web server hosting the webmail interface could be a
     potential adversary.  If the user treats the web server as a trusted
     party, but the web server violates that trust, the end-to-end
     cryptographic protections do not hold.

     A future version of this document could include more detailed
     discussion of an adversarial threat model for end-to-end
     cryptographic protections in a webmail context.

  A.2.  Test Vectors

     A future version of this document (or a companion document) could
     contain examples of well-formed and malformed messages using
     cryptographic key material and certificates from [RFC9580] and
     [RFC9216].



  Gillmor, et al.           Expires 12 July 2025                 [Page 56]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     It may also include example renderings of these messages.

  A.3.  Further Guidance on Peer Certificates

  A.3.1.  Certificate Discovery from Incoming Messages

     As described in Section 8.2.3, an incoming e-mail message may have
     one or more certificates embedded in it.  This document currently
     acknowledges that receiving MUA should assemble a cache of
     certificates for future use, but providing more detailed guidance for
     how to assemble and manage that cache is currently out of scope.

     Existing recommendations like [AUTOCRYPT] provide some guidance for
     handling incoming certificates about peers, but only in certain
     contexts.  A future version of this document may describe in more
     detail how these incoming certs should be handled.

  A.3.2.  Certificate Directories

     Some MUAs may have the capability to look up peer certificates in a
     directory, for example via LDAP [RFC4511], WKD
     [I-D.koch-openpgp-webkey-service], or the DNS (e.g., SMIMEA [RFC8162]
     or OPENPGPKEY [RFC7929] resource records).

     A future version of this document may describe in more detail what
     sources an MUA should consider when searching for a peer's
     certificates, and what to do with the certificates found by various
     methods.

  A.3.3.  Checking for Certificate Revocation

     A future version of this document could discuss how/when to check for
     revocation of peer certificates, or of the user's own certificate.

     Such discussion should address privacy concerns: what information
     leaks to whom when checking peer cert revocations?

  A.3.4.  Further Peer Certificate Selection

     A future version of this document may describe more prescriptions for
     deciding whether a peer certificate is acceptable for encrypting a
     message.  For example, if the SPKI is an EC Public Key and the
     keyUsage extension is absent, what should the encrypting MUA do?








  Gillmor, et al.           Expires 12 July 2025                 [Page 57]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     A future version of this document might also provide guidance on what
     to do if multiple certificates are all acceptable for encrypting to a
     given recipient.  For example, the sender could select among them in
     some deterministic way; it could encrypt to all of them; or it could
     present them to the user to let the user select any or all of them.

  A.3.5.  Human-readable Names in Peer Certificates, Header Fields, and
          Addressbooks

     In header fields like From: that may contain a display-name as
     described in Section 3.4 of [RFC5322], a malicious sender (or
     interfering adversary) may populate the display-name part with a
     human-readable name that does not at all match the actual name of the
     participant.  Section 8.1.1 describes some matching rules relating
     peer certificates to e-mail addresses (the addr-spec part of these
     e-mail header fields), but does not contemplate matching display-
     names or other or similar user-visible data elements.  Section 6.4
     describes how signature validation should confirm a binding between
     the addr-spec and the certificate itself, but also does not
     contemplate matching display-names or other similar user-visible data
     elements.  Depending on how the receiving MUA renders the display-
     name in a message's header field, that unvalidated field may present
     a risk of user confusion which could break the intended end-to-end
     assurances.  Yet both X.509 and OpenPGP certificate formats offer
     ways to provide cryptographically certified (though possibly not
     unique) comparable human-readable names.  Additionally, many MUAs
     also include an addressbook or comparable feature which can make
     substantive connections between user-relevant identity labels and
     e-mail addresses.

     A human-readable name like a display-name does not have the property
     of global uniqueness that an addr-spec does, so reasoning about
     human-readable names and rendering them to the user as an element in
     a system providing end-to-end cryptographic assurance requires
     additional deliberate analysis.

     A future version of this document might offer strategies for
     associating human-readable names from certificates (and features like
     addressbooks) to the rendering of header fields that include display-
     name.  Such guidance should be paired with an analysis of specific
     usability and security risks associated with these human-readable
     fields, as well as a description of how the recommended guidance
     mitigates those risks.

  A.4.  Further Guidance on Local Certificates and Secret Keys






  Gillmor, et al.           Expires 12 July 2025                 [Page 58]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  A.4.1.  Cross-MUA sharing of Local Certificates and Secret Keys

     Many users today use more than one MUA to access the same mailbox
     (for example, one MUA on a mobile device, and another MUA on a
     desktop computer).

     A future version of this document might offer guidance on how
     multiple MUAs attached to the same mailbox can efficiently and
     securely share the user's own secret key material and certificates
     between each other.  This guidance should include suggestions on how
     to maintain the user's keys (e.g., avoiding certificate expiration)
     and safe secret key transmission.

  A.4.2.  Use of Smartcards or Other Portable Secret Key Mechanisms

     Rather than having to transfer secret key material between clients,
     some users may prefer to rely on portable hardware-backed secret keys
     in the form of smartcards, USB tokens or other comparable form
     factors.  These secret keys sometimes require direct user interaction
     for each use, which can complicate the usability of any MUA that uses
     them to decrypt a large number of messages.

     Guidance on the use of this kind of secret key management are beyond
     the scope of this document, but future revisions may bring them into
     scope.

  A.4.3.  Active Local Certificate Maintenance

     Section 8.2.2 describes conditions where the MUA SHOULD warn the user
     that something is going wrong with their certificate.

     A future version of this document might outline how an MUA could
     actively avoid these warning situations, for example, by
     automatically updating the certificate or prompting the user to take
     specific action.

  A.5.  Certification Authorities

     A future document could offer guidance on how an MUA should select
     and manage root certification authorities (CAs).

     For example:

     *  Should the MUA cache intermediate CAs?

     *  Should the MUA share such a cache with other PKI clients (e.g.,
        web browsers)?




  Gillmor, et al.           Expires 12 July 2025                 [Page 59]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  What distinctions are there between a CA for S/MIME and a CA for
        the web?

  A.6.  Indexing and Search of Encrypted Messages

     A common use case for MUAs is search of existing messages by keyword
     or topic.  This is done most efficiently for large mailboxes by
     assembling an index of message content, rather than by a linear scan
     of all message content.

     When message contents and header fields are encrypted, search by
     index is complicated.  If the cleartext is not indexed, then messages
     cannot be found by search.  On the other hand, if the cleartext is
     indexed, then the index effectively contains the sensitive contents
     of the message, and needs to be protected.

     Detailed guidance on the tradeoff here, including choices about
     remote search vs local search, are beyond the scope of this document,
     but a future version of the document may bring them into scope.

  A.7.  Cached Signature Validation

     Asymmetric signature validation can be computationally expensive, and
     the results can also potentially vary over time (e.g., if a signing
     certificate is discovered to be revoked).  In some cases, the user
     may care about the signature validation that they saw when they first
     read or received the message, not only about the status of the
     signature verification at the current time.

     So, for both performance reasons and historical perspective, it may
     be useful for an MUA to cache signature validation results in a way
     that they can be easily retrieved and compared.  Documenting how and
     when to cache signature validation, as well as how to indicate it to
     the user, is beyond the scope of this document, but a future version
     of the document may bring these topics into scope.

  A.8.  Aggregate Cryptographic Status

     This document limits itself to consideration of the cryptographic
     status of single messages as a baseline concept that can be clearly
     and simply communicated to the user.  However, some users and some
     MUAs may find it useful to contemplate even higher-level views of
     cryptographic status which are not considered directly here.








  Gillmor, et al.           Expires 12 July 2025                 [Page 60]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     For example, a future version of the document may also consider how
     to indicate a simple cryptographic status of message threads (groups
     of explicitly related messages), conversations (groups of messages
     with shared sets of participants), peers, or other perspectives that
     an MUA can provide.

  A.9.  Expectations of Cryptographic Protection

     As mentioned in Section 2.3, the types of security indicators
     displayed to the user may well vary based on the expectations of the
     user for a given communication.  At present, there is no widely
     shared method for the MUA to establish and maintain reasonable
     expectations about whether a specific received message should have
     cryptographic protections.

     If such a standard is developed, a future version of this document
     should reference it and encourage the deployment of clearer and
     simpler security indicators.

  A.10.  Secure Deletion

     One feature many users desire from a secure communications medium is
     the ability to reliably destroy a message such that it cannot be
     recovered even by a determined adversary.  In other contexts, a
     similar desired property is called "forward secrecy".  Doing this
     with standard e-mail mechanisms like S/MIME and PGP/MIME is
     challenging because of two interrelated factors:

     *  A copy of of an e-mail message may be retained by any of the mail
        transport agents that handle it during delivery, and

     *  The secret key used to decrypt an encrypted e-mail message is
        typically retained indefinitely.

     This means that an adversary aiming to recover the cleartext contents
     of a deleted message can do so by getting access to a copy of the
     encrypted message and the long-term secret key material.

     Some mitigation measures may be available to make it possible to
     delete some encrypted messages securely, but this document considers
     this use case out of scope.  A future version of the document may
     elaborate on secure message deleton in more detail.









  Gillmor, et al.           Expires 12 July 2025                 [Page 61]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  A.11.  Interaction with Opportunistic Encryption

     This document focuses on guidance for strong, user-comprehensible
     end-to-end cryptographic protections for e-mail.  Other approaches
     are possible, including various forms of opportunistic and transport
     encryption, which are out of scope for this document.

     A future version of this document could describe the interaction
     between this guidance and more opportunistic forms of encryption, for
     example some of the scenarios contemplated in
     [I-D.dkg-mail-cleartext-copy].

  A.12.  Split Attachments

     As noted in Section 7.2, the standard form for encrypted e-mail
     messages is a single cryptographic envelope.  In a scenario where
     multiple user agents are drafting a single encrypted message over
     low-bandwidth links, this can create a poor user experience, as each
     MUA has to retrieve the full message, including attachments, to
     modify the draft.  Similarly, when retrieving a message with a large
     attachment, the receiving MUA might want to only render the main body
     part, and will have a significant delay in doing so if required to
     process the full message before handling.

     Future work might include an attempt to standardize a mechanism that
     eases this use case, potentially at the risk of additional metadata
     leakage about the message (e.g., the size and number of message
     parts).  Any such work should explicitly try to minimize the risks
     and concerns described in Section 7.2.

  A.13.  Proxy Extensions

     As noted in Section 9.7, a proxy-based implementation can be a
     tempting approach.  But its naive form is likely to be insufficient
     to provide safe end-to-end encrypted e-mail.

     A future version of this document, or a separate but related
     document, could try to outline the specific additional information,
     state, and network API surface that would be needed to allow an MUA
     to be safely integrated with an encryption provider.  Any such work
     should try to address the potential problems described in
     Section 9.7.









  Gillmor, et al.           Expires 12 July 2025                 [Page 62]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  A.14.  Mailing Lists

     Mailing lists offer challenging complications to any notion of end-
     to-end cryptographic protections.  By default, there is some sort of
     intervening MUA (see Section 9.8), but more than that, user
     expectations about cryptographic protections might differ from normal
     messages, at least insofar as they understand they are writing to a
     mailing list.  A particular challenge to the notion of end-to-end
     cryptographic security with mailing lists is that a subscriber to a
     mailing list often does not know who else is subscribed to the
     mailing list.  Another challenge is that for some mailing lists, some
     subscribers might not have a valid, non-expired certificate.

     Encryption can interact with mailing lists in different ways,
     depending on the use case of the list.  It's not clear that there are
     any useful motivations for sending encrypted mail to a publicly
     archived mailing list.  But an unarchived mailing list might want to
     provide confidentiality between all recipients, even if the
     recipients don't know for certain who all the other participants are.
     Or, a mailing list with private archives might well decide that two
     "hops" of encryption (between the sender and the mailing list, and
     the mailing list and all the subscribers) are a useful
     confidentiality measure even though they are not "end-to-end" in the
     sense of the sender directly to all recipients.

     Similarly, cryptographic signatures may play different roles in a
     mailing list, depending on the list's communication goals.  The
     mailing list itself might want to verify that an incoming message is
     cryptographically signed by an authorized sender before
     redistribution to the list subscribers.  It might also want to pass
     along the sender's signature in a way that the subscribers can all
     verify it.  Alternately, the mailing list might want to sign each
     redistributed message itself, and change the message so it appears to
     come from the list rather than the original sender.

     Yet another design for a mailing list with end-to-end cryptographic
     protections might involve redistributing shared secret keys to all
     recipients, or using some sort of proxied re-encryption scheme,
     similar to [I-D.wussler-openpgp-forwarding].

     A future version of this document or a separate but related document
     might describe some of these tradeoffs and provide guidance for
     safely meeting common requirements or use cases when combining end-
     to-end cryptographic protections with mailing lists.







  Gillmor, et al.           Expires 12 July 2025                 [Page 63]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  Appendix B.  Document History

  B.1.  Substantive changes from draft-ietf-...-16 to draft-ietf-...-17

     *  Update OpenPGP references to RFC 9580

     *  Clarify ciphertext malleability concerns

  B.2.  Substantive changes from draft-ietf-...-15 to draft-ietf-...-16

     *  Address feedback from Last Call and IESG review:

     *  Add "Weak Encryption" section

     *  Add Future Work subsection on mailing lists

     *  Add Future Work subsection on human-readable names

     *  Mention possible user control over stripping quoted text in
        cleartext reply to encrypted message

     *  Simplify Bcc guidance about certificate inclusion

  B.3.  Substantive changes from draft-ietf-...-14 to draft-ietf-...-15

     *  update IMAP reference to RFC 9051

     *  add webmail concerns as part of Future Work

  B.4.  Substantive changes from draft-ietf-...-13 to draft-ietf-...-14

     *  Responded to SEC AD Review, including:

     *  clarify "conformant" vs "legacy" vs "non-cryptographic" MUA
        categories

     *  tighten up MUSTs for conformant MUAs

     *  explicitly recommend encrypting drafts

     *  clarify debugging as a use case for showing invalid signatures

     *  clarify "Headers" to "Header Fields"

     *  3 states for sending, 4 for receiving






  Gillmor, et al.           Expires 12 July 2025                 [Page 64]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


  B.5.  Substantive changes from draft-ietf-...-12 to draft-ietf-...-13

     *  clarify RFC 2119 guidance about not rendering cryptographic layers
        other than message cryptographic status

  B.6.  Substantive changes from draft-ietf-...-11 to draft-ietf-...-12

     *  More nuance (and future work) around split attachments

     *  More nuance (and future work) around proxy-style design

     *  Clearer caveats about external resources in text/html parts

  B.7.  Substantive changes from draft-ietf-...-10 to draft-ietf-...-11

     *  Mention List-* and Archived-At message header fields

     *  Add additional references to papers that describe flaws in e2e
        e-mail

  B.8.  Substantive changes from draft-ietf-...-09 to draft-ietf-...-10

     *  Introduction: describe one major theme of Future Work

  B.9.  Substantive changes from draft-ietf-...-08 to draft-ietf-...-09

     *  Clarify goals of document

     *  Identify cross-protocol attacks in more detail to justify
        prescription against key reuse

     *  Add informative references to Opportunistic Encryption RFC and
        Certificate Best Practice draft

     *  Add "Reading Encrypted Messages after Certificate Expiration"
        section to Common Pitfalls and Guidelines

     *  Clean up nits identified by Stephen Farrell and Eliot Lear

  B.10.  Substantive changes from draft-ietf-...-07 to draft-ietf-...-08

     *  Add guidance about importing and exporting secret key material

     *  More explanation about "encryption outside, signature inside"

     *  Guidance about Intervening (resending) MUAs

     *  Include Sender and Resent-* as user-facing header fields



  Gillmor, et al.           Expires 12 July 2025                 [Page 65]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  Guidance about external subresources for cryptographically
        protected messages

     *  Relax "user-facing" definition to be more advisory

  B.11.  Substantive changes from draft-ietf-...-06 to draft-ietf-...-07

     *  Add Bernie Hoeneisen and Alexey Melnikov as editors

     *  Explicitly avoid requiring anything from IANA

     *  Simplify description of "attachments"

     *  Add concrete detail on how to compare e-mail addresses

     *  Explicitly define "Cryptographic Summary"

  B.12.  Substantive changes from draft-ietf-...-05 to draft-ietf-...-06

     *  Expand proxy implementation warning to comparable APIs

     *  Move many marked TODO and FIXME items to "Future Work"

     *  More detailed guidance on local certificates

     *  Provide guidance on encrypting draft messages

     *  More detailed guidanc eon shipping certificates in outbound
        messages

     *  Recommend implementing header protection

     *  Added "Future Work" subsection about interactions with
        opportunistic approaches

  B.13.  Substantive changes from draft-ietf-...-04 to draft-ietf-...-05

     *  Adopt and update text about Bcc from draft-ietf-lamps-header-
        protection

     *  Add section about the dangers of an implementation based on a
        network protocol proxy

  B.14.  Substantive changes from draft-ietf-...-03 to draft-ietf-...-04

     *  Added reference to multipart/oracle attacks





  Gillmor, et al.           Expires 12 July 2025                 [Page 66]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     *  Clarified that "Structural Header fields" are the same as
        RFC2045's "MIME Headers"

  B.15.  Substantive changes from draft-ietf-...-02 to draft-ietf-...-03

     *  Added section about mixed recipients

     *  Noted SMIMEA and OPENPGPKEY DNS RR cert discovery mechanisms

     *  Added more notes about simplified mental models

     *  More clarification on one-status-per-message

     *  Added guidance to defend against EFAIL

  B.16.  Substantive changes from draft-ietf-...-01 to draft-ietf-...-02

     *  Added definition of "user-facing" header fields

  B.17.  Substantive changes from draft-ietf-...-00 to draft-ietf-...-01

     *  Added section about distinguishing Main Body Parts and Attachments

     *  Updated document considerations section, including reference to
        auto-built editor's copy

  B.18.  Substantive changes from draft-dkg-...-01 to draft-ietf-...-00

     *  WG adopted draft

     *  moved Document History and Document Considerations sections to end
        of appendix, to avoid section renumbering when removed

  B.19.  Substantive changes from draft-dkg-...-00 to draft-dkg-...-01

     *  consideration of success/failure indicators for usability

     *  clarify extendedKeyUsage and keyUsage algorithm-specific details

     *  initial section on certificate management

     *  added more TODO items

  Authors' Addresses







  Gillmor, et al.           Expires 12 July 2025                 [Page 67]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 2025


     Daniel Kahn Gillmor (editor)
     American Civil Liberties Union
     125 Broad St.
     New York, NY,  10004
     United States of America
     Email: dkg@fifthhorseman.net


     Bernie Hoeneisen (editor)
     pEp Project
     Oberer Graben 4
     CH- 8400 Winterthur
     Switzerland
     Email: bernie@ietf.hoeneisen.ch
     URI:   https://pep-project.org/


     Alexey Melnikov (editor)
     Isode Ltd
     14 Castle Mews
     Hampton, Middlesex
     TW12 2NP
     United Kingdom
     Email: alexey.melnikov@isode.com



























  Gillmor, et al.           Expires 12 July 2025                 [Page 68]


