# drafts

name: draft-annevk-johannhof-httpbis-cookies
rev: 01
title: Cookies: HTTP State Management Mechanism
time: 2025-04-18T22:06:21Z
group_uri: /api/v1/group/group/1718/
expires: 2025-10-19T22:36:58Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578529+00:00
source: ietf
abstract:
  This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.

full_text:
  Network Working Group                               A. van Kesteren, Ed.
  Internet-Draft                                                     Apple
  Obsoletes: [6265] (if approved)                          J. Hofmann, Ed.
  Intended status: Standards Track                                  Google
  Expires: 19 October 2025                                   17 April 2025


                  Cookies: HTTP State Management Mechanism
                 draft-annevk-johannhof-httpbis-cookies-01

  Abstract

     This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.

  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://johannhof.github.io/draft-annevk-johannhof-httpbis-cookies/
     draft-annevk-johannhof-httpbis-cookies.html.  Status information for
     this document may be found at https://datatracker.ietf.org/doc/draft-
     annevk-johannhof-httpbis-cookies/.

     Discussion of this document takes place on the HTTP Working Group
     mailing list (mailto:ietf-http-wg@w3.org), which is archived at
     https://lists.w3.org/Archives/Public/ietf-http-wg/.  Working Group
     information can be found at https://httpwg.org/.

     Source for this draft and an issue tracker can be found at
     https://github.com/johannhof/draft-annevk-johannhof-httpbis-cookies.

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




  van Kesteren & Hofmann   Expires 19 October 2025                [Page 1]


  Internet-Draft                   Cookies                      April 2025


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

     This document may contain material from IETF Documents or IETF
     Contributions published or made publicly available before November
     10, 2008.  The person(s) controlling the copyright in some of this
     material may not have granted the IETF Trust the right to allow
     modifications of such material outside the IETF Standards Process.
     Without obtaining an adequate license from the person(s) controlling
     the copyright in such materials, this document may not be modified
     outside the IETF Standards Process, and derivative works of it may
     not be created outside the IETF Standards Process, except to format
     it for publication as an RFC or to translate it into languages other
     than English.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Which Requirements to Implement . . . . . . . . . . . . . . .   7
       3.1.  Cookie Producing Implementations  . . . . . . . . . . . .   8
       3.2.  Cookie Consuming Implementations  . . . . . . . . . . . .   8
       3.3.  Programming Languages & Software Frameworks . . . . . . .   8
     4.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .   9
         4.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .   9
         4.1.2.  Semantics (Non-Normative) . . . . . . . . . . . . . .  11



  van Kesteren & Hofmann   Expires 19 October 2025                [Page 2]


  Internet-Draft                   Cookies                      April 2025


         4.1.3.  Cookie Name Prefixes  . . . . . . . . . . . . . . . .  14
       4.2.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  15
         4.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  15
         4.2.2.  Semantics . . . . . . . . . . . . . . . . . . . . . .  16
     5.  User Agent Requirements . . . . . . . . . . . . . . . . . . .  17
       5.1.  Cookie Concepts . . . . . . . . . . . . . . . . . . . . .  17
         5.1.1.  Cookie Store And Limits . . . . . . . . . . . . . . .  17
         5.1.2.  Cookie Struct . . . . . . . . . . . . . . . . . . . .  17
       5.2.  Cookie Store Eviction . . . . . . . . . . . . . . . . . .  18
         5.2.1.  Remove Excess Cookies for a Host  . . . . . . . . . .  18
         5.2.2.  Remove Global Excess Cookies  . . . . . . . . . . . .  19
       5.3.  Subcomponent Algorithms . . . . . . . . . . . . . . . . .  19
         5.3.1.  Parse a Date  . . . . . . . . . . . . . . . . . . . .  19
         5.3.2.  Domain Matching . . . . . . . . . . . . . . . . . . .  21
         5.3.3.  Cookie Default Path . . . . . . . . . . . . . . . . .  21
         5.3.4.  Path Matching . . . . . . . . . . . . . . . . . . . .  22
       5.4.  Main Algorithms . . . . . . . . . . . . . . . . . . . . .  22
         5.4.1.  Parse and Store a Cookie  . . . . . . . . . . . . . .  22
         5.4.2.  Parse a Cookie  . . . . . . . . . . . . . . . . . . .  23
         5.4.3.  Store a Cookie  . . . . . . . . . . . . . . . . . . .  26
         5.4.4.  Retrieve Cookies  . . . . . . . . . . . . . . . . . .  29
         5.4.5.  Serialize Cookies . . . . . . . . . . . . . . . . . .  31
       5.5.  Requirements Specific to Non-Browser User Agents  . . . .  31
         5.5.1.  The Set-Cookie Header Field . . . . . . . . . . . . .  31
         5.5.2.  The Cookie Header Field . . . . . . . . . . . . . . .  32
       5.6.  Requirements Specific to Browser User Agents  . . . . . .  33
     6.  Implementation Considerations . . . . . . . . . . . . . . . .  33
       6.1.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       6.2.  Application Programming Interfaces  . . . . . . . . . . .  33
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  34
       7.1.  Third-Party Cookies . . . . . . . . . . . . . . . . . . .  35
       7.2.  Cookie Policy . . . . . . . . . . . . . . . . . . . . . .  35
       7.3.  User Controls . . . . . . . . . . . . . . . . . . . . . .  36
       7.4.  Expiration Dates  . . . . . . . . . . . . . . . . . . . .  36
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  36
       8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  36
       8.2.  Ambient Authority . . . . . . . . . . . . . . . . . . . .  37
       8.3.  Clear Text  . . . . . . . . . . . . . . . . . . . . . . .  37
       8.4.  Session Identifiers . . . . . . . . . . . . . . . . . . .  38
       8.5.  Weak Confidentiality  . . . . . . . . . . . . . . . . . .  39
       8.6.  Weak Integrity  . . . . . . . . . . . . . . . . . . . . .  39
       8.7.  Reliance on DNS . . . . . . . . . . . . . . . . . . . . .  40
       8.8.  SameSite Cookies  . . . . . . . . . . . . . . . . . . . .  40
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  41
       9.1.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       9.2.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .  41
     10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .  41
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  41



  van Kesteren & Hofmann   Expires 19 October 2025                [Page 3]


  Internet-Draft                   Cookies                      April 2025


     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  42
       Normative References  . . . . . . . . . . . . . . . . . . . . .  42
       Informative References  . . . . . . . . . . . . . . . . . . . .  42
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43

  1.  Introduction

     This document defines the HTTP Cookie and Set-Cookie header fields.
     Using the Set-Cookie header field, an HTTP server can pass name/value
     pairs and associated metadata (called cookies) to a user agent.  When
     the user agent makes subsequent requests to the server, the user
     agent uses the metadata and other information to determine whether to
     return the name/value pairs in the Cookie header field.

     Although simple on their surface, cookies have a number of
     complexities.  For example, the server can scope the maximum amount
     of time during which the user agent should return the cookie, the
     servers to which the user agent should return the cookie, and whether
     the cookie can be accessed through a non-HTTP API, such as JavaScript
     in a web browser.

     For historical reasons, cookies contain a number of security and
     privacy infelicities.  For example, a server can indicate that a
     given cookie is intended for "secure" connections, but the cookie's
     Secure attribute does not provide integrity in the presence of an
     active network attacker.  Similarly, cookies for a given host are
     shared across all the ports on that host, even though the usual
     "same-origin policy" used by web browsers isolates content retrieved
     via different ports.

     This document specifies the syntax and semantics of these header
     fields.  Where some existing software differs from the requirements
     in significant ways, the document contains a note explaining the
     difference.

     This document obsoletes [RFC6265] and 6265bis.

  1.1.  Examples

     Using the Set-Cookie header field, a server can send the user agent a
     short string in an HTTP response that the user agent will return in
     future HTTP requests that are within the scope of the cookie.  For
     example, the server can send the user agent a "session identifier"
     named SID with the value 31d4d96e407aad42.  The user agent then
     returns the session identifier in subsequent requests.






  van Kesteren & Hofmann   Expires 19 October 2025                [Page 4]


  Internet-Draft                   Cookies                      April 2025


     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

     The server can alter the default scope of the cookie using the Path
     and Domain attributes.  For example, the server can instruct the user
     agent to return the cookie to every path and every subdomain of
     site.example.

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

     As shown in the next example, the server can store multiple cookies
     at the user agent.  For example, the server can store a session
     identifier as well as the user's preferred language by returning two
     Set-Cookie header fields.  Notice that the server uses the Secure and
     HttpOnly attributes to provide additional security protections for
     the more sensitive session identifier (see Section 4.1.2).

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
     Set-Cookie: lang=en-US; Path=/; Domain=site.example

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; lang=en-US

     Notice that the Cookie header field above contains two cookies, one
     named SID and one named lang.

     Cookie names are case-sensitive, meaning that if a server sends the
     user agent two Set-Cookie header fields that differ only in their
     name's case the user agent will store and return both of those
     cookies in subsequent requests.







  van Kesteren & Hofmann   Expires 19 October 2025                [Page 5]


  Internet-Draft                   Cookies                      April 2025


     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42
     Set-Cookie: sid=31d4d96e407aad42

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42

     If the server wishes the user agent to persist the cookie over
     multiple "sessions" (e.g., user agent restarts), the server can
     specify an expiration date in the Expires attribute.  Note that the
     user agent might delete the cookie before the expiration date if the
     user agent's cookie store exceeds its quota or if the user manually
     deletes the server's cookie.

     == Server -> User Agent ==

     Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; lang=en-US

     Finally, to remove a cookie, the server returns a Set-Cookie header
     field with an expiration date in the past.  The server will be
     successful in removing the cookie only if the Path and the Domain
     attribute in the Set-Cookie header field match the values used when
     the cookie was created.

     == Server -> User Agent ==

     Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

  2.  Conventions

  2.1.  Terminology

     This specification depends on Infra.  [INFRA]

     Some terms used in this specification are defined in the following
     standards and specifications:

     *  HTTP [RFC9110]



  van Kesteren & Hofmann   Expires 19 October 2025                [Page 6]


  Internet-Draft                   Cookies                      April 2025


     *  URL [URL]

     A *non-HTTP API* is a non-HTTP mechanisms used to set and retrieve
     cookies, such as a web browser API that exposes cookies to
     JavaScript.

  2.2.  ABNF

     This specification uses the Augmented Backus-Naur Form (ABNF)
     notation of [RFC5234].

     The following core rules are included by reference, as defined in
     [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
     (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
     HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
     OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
     (horizontal tab), CHAR (any ASCII byte), VCHAR (any visible ASCII
     byte), and WSP (whitespace).

     The OWS (optional whitespace) and BWS (bad whitespace) rules are
     defined in Section 5.6.3 of [RFC9110].

  3.  Which Requirements to Implement

     The upcoming two sections, Section 4 and Section 5, discuss the set
     of requirements for two distinct types of implementations.  This
     section is meant to help guide implementers in determining which set
     of requirements best fits their goals.  Choosing the wrong set of
     requirements could result in a lack of compatibility with other
     cookie implementations.

     It's important to note that being compatible means different things
     depending on the implementer's goals.  These differences have built
     up over time due to both intentional and unintentional specification
     changes, specification interpretations, and historical implementation
     differences.

     This section roughly divides implementers of this specification into
     two types, producers and consumers.  These are not official terms and
     are only used here to help readers develop an intuitive understanding
     of the use cases.










  van Kesteren & Hofmann   Expires 19 October 2025                [Page 7]


  Internet-Draft                   Cookies                      April 2025


  3.1.  Cookie Producing Implementations

     An implementer should choose Section 4 whenever cookies are created
     and will be sent to a user agent, such as a web browser.  These
     implementations are frequently referred to as servers by the
     specification but that term includes anything which primarily
     produces cookies.  Some potential examples:

     *  Server applications hosting a website or API

     *  Programming languages or software frameworks that support cookies

     *  Integrated third-party web applications, such as a business
        management suite

     All these benefit from not only supporting as many user agents as
     possible but also supporting other servers.  This is useful if a
     cookie is produced by a software framework and is later sent back to
     a server application which needs to read it.  Section 4 advises best
     practices that help maximize this sense of compatibility.

  3.2.  Cookie Consuming Implementations

     An implementer should choose Section 5 whenever cookies are primarily
     received from another source.  These implementations are referred to
     as user agents.  Some examples:

     *  Web browsers

     *  Tools that support stateful HTTP

     *  Programming languages or software frameworks that support cookies

     Because user agents don't know which servers a user will access, and
     whether or not that server is following best practices, users agents
     are advised to implement a more lenient set of requirements and to
     accept some things that servers are warned against producing.
     Section 5 advises best practices that help maximize this sense of
     compatibility.

  3.3.  Programming Languages & Software Frameworks

     A programming language or software framework with support for cookies
     could reasonably be used to create an application that acts as a
     cookie producer, cookie consumer, or both.  Because a developer may
     want to maximize their compatibility as either a producer or
     consumer, these languages or frameworks should strongly consider
     supporting both sets of requirements, Section 4 and Section 5, behind



  van Kesteren & Hofmann   Expires 19 October 2025                [Page 8]


  Internet-Draft                   Cookies                      April 2025


     a compatibility mode toggle.  This toggle should default to
     Section 4's requirements.

     Doing so will reduce the chances that a developer's application can
     inadvertently create cookies that cannot be read by other servers.

  4.  Server Requirements

     This section describes the conforming syntax and semantics of the
     HTTP Cookie and Set-Cookie header fields.

  4.1.  Set-Cookie

     The Set-Cookie HTTP response header field is used to send cookies
     from the server to the user agent.

     Origin servers MAY send a Set-Cookie response header field with any
     response.  An origin server can include multiple Set-Cookie header
     fields in a single response.  The presence of a Cookie or a Set-
     Cookie header field does not preclude HTTP caches from storing and
     reusing a response.

     Origin servers and intermediaries MUST NOT combine multiple Set-
     Cookie header fields into a single header field.  The usual mechanism
     for combining HTTP headers fields (i.e., as defined in Section 5.3 of
     [RFC9110]) might change the semantics of the Set-Cookie header field
     because the %x2C (",") character is used by Set-Cookie in a way that
     conflicts with such combining.

     For example,

     Set-Cookie: a=b;path=/c,d=e

     is ambiguous.  It could be intended as two cookies, a=b and d=e, or a
     single cookie with a path of /c,d=e.

  4.1.1.  Syntax

     Informally, the Set-Cookie response header field contains a cookie,
     which begins with a name-value-pair, followed by zero or more
     attribute-value pairs.  Servers MUST send Set-Cookie header fields
     that conform to the following grammar:









  van Kesteren & Hofmann   Expires 19 October 2025                [Page 9]


  Internet-Draft                   Cookies                      April 2025


     set-cookie        = set-cookie-string
     set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
     cookie-pair       = cookie-name BWS "=" BWS cookie-value
     cookie-name       = token
     cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
     cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                           ; US-ASCII characters excluding CTLs,
                           ; whitespace, DQUOTE, comma, semicolon,
                           ; and backslash
     token             = <token, defined in [HTTP], Section 5.6.2>

     cookie-av         = expires-av / max-age-av / domain-av /
                         path-av / secure-av / httponly-av /
                         samesite-av / extension-av
     expires-av        = "Expires" BWS "=" BWS sane-cookie-date
     sane-cookie-date  =
         <IMF-fixdate, defined in [HTTP], Section 5.6.7>
     max-age-av        = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT
     non-zero-digit    = %x31-39
                           ; digits 1 through 9
     domain-av         = "Domain" BWS "=" BWS domain-value
     domain-value      = <subdomain>
                           ; see details below
     path-av           = "Path" BWS "=" BWS path-value
     path-value        = *av-octet
     secure-av         = "Secure"
     httponly-av       = "HttpOnly"
     samesite-av       = "SameSite" BWS "=" BWS samesite-value
     samesite-value    = "Strict" / "Lax" / "None"
     extension-av      = *av-octet
     av-octet          = %x20-3A / %x3C-7E
                           ; any CHAR except CTLs or ";"

     Note that some of the grammatical terms above reference documents
     that use different grammatical notations than this document (which
     uses ABNF from [RFC5234]).

     Per the grammar above, servers MUST NOT produce nameless cookies
     (i.e., an empty cookie-name) as such cookies may be unpredictably
     serialized by user agents when sent back to the server.

     The semantics of the cookie-value are not defined by this document.

     To maximize compatibility with user agents, servers that wish to
     store arbitrary data in a cookie-value SHOULD encode that data, for
     example, using Base64 [RFC4648].





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 10]


  Internet-Draft                   Cookies                      April 2025


     Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
     characters.  Note that in this case, the initial and trailing DQUOTE
     characters are not stripped.  They are part of the cookie-value, and
     will be included in Cookie header fields sent to the server.

     The domain-value is a subdomain as defined by [RFC1034], Section 3.5,
     and as enhanced by [RFC1123], Section 2.1.  Thus, domain-value is a
     byte sequence of ASCII bytes.

     The portions of the set-cookie-string produced by the cookie-av term
     are known as attributes.  To maximize compatibility with user agents,
     servers SHOULD NOT produce two attributes with the same name in the
     same set-cookie-string.

     NOTE: The name of an attribute-value pair is not case-sensitive.  So
     while they are presented here in CamelCase, such as HttpOnly or
     SameSite, any case is accepted.  E.g., httponly, Httponly, hTTPoNLY,
     etc.

     Servers MUST NOT include more than one Set-Cookie header field in the
     same response with the same cookie-name.  (See Section 5.5.1 for how
     user agents handle this case.)

     If a server sends multiple responses containing Set-Cookie header
     fields concurrently to the user agent (e.g., when communicating with
     the user agent over multiple sockets), these responses create a "race
     condition" that can lead to unpredictable behavior.

     NOTE: Some existing user agents differ in their interpretation of
     two-digit years.  To avoid compatibility issues, servers SHOULD use
     the rfc1123-date format, which requires a four-digit year.

     NOTE: Some user agents store and process dates in cookies as 32-bit
     UNIX time_t values.  Implementation bugs in the libraries supporting
     time_t processing on some systems might cause such user agents to
     process dates after the year 2038 incorrectly.

  4.1.2.  Semantics (Non-Normative)

     This section describes simplified semantics of the Set-Cookie header
     field.  These semantics are detailed enough to be useful for
     understanding the most common uses of cookies by servers.  The full
     semantics are described in Section 5.

     When the user agent receives a Set-Cookie header field, the user
     agent stores the cookie together with its attributes.  Subsequently,
     when the user agent makes an HTTP request, the user agent includes
     the applicable, non-expired cookies in the Cookie header field.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 11]


  Internet-Draft                   Cookies                      April 2025


     If the user agent receives a new cookie with the same cookie-name,
     domain-value, and path-value as a cookie that it has already stored,
     the existing cookie is evicted and replaced with the new cookie.
     Notice that servers can delete cookies by sending the user agent a
     new cookie with an Expires attribute with a value in the past.

     Unless the cookie's attributes indicate otherwise, the cookie is
     returned only to the origin server (and not, for example, to any
     subdomains), and it expires at the end of the current session (as
     defined by the user agent).  User agents ignore unrecognized cookie
     attributes (but not the entire cookie).

  4.1.2.1.  The Expires Attribute

     The Expires attribute indicates the maximum lifetime of the cookie,
     represented as the date and time at which the cookie expires.  The
     user agent is not required to retain the cookie until the specified
     date has passed.  In fact, user agents often evict cookies due to
     memory pressure or privacy concerns.

  4.1.2.2.  The Max-Age Attribute

     The Max-Age attribute indicates the maximum lifetime of the cookie,
     represented as the number of seconds until the cookie expires.  The
     user agent is not required to retain the cookie for the specified
     duration.  In fact, user agents often evict cookies due to memory
     pressure or privacy concerns.

     NOTE: Some existing user agents do not support the Max-Age attribute.
     User agents that do not support the Max-Age attribute ignore the
     attribute.

     If a cookie has both the Max-Age and the Expires attribute, the Max-
     Age attribute has precedence and controls the expiration date of the
     cookie.  If a cookie has neither the Max-Age nor the Expires
     attribute, the user agent will retain the cookie until "the current
     session is over" (as defined by the user agent).

  4.1.2.3.  The Domain Attribute

     The Domain attribute specifies those hosts to which the cookie will
     be sent.









  van Kesteren & Hofmann   Expires 19 October 2025               [Page 12]


  Internet-Draft                   Cookies                      April 2025


     If the server includes the Domain attribute, the value applies to
     both the specified domain and any subdomains.  For example, if the
     value of the Domain attribute is "site.example", the user agent will
     include the cookie in the Cookie header field when making HTTP
     requests to site.example, www.site.example, and
     www.corp.site.example.  Note that a leading %x2E ("."), if present,
     is ignored even though that character is not permitted.

     If the server omits the Domain attribute, the user agent will return
     the cookie only to the origin server and not to any subdomains.

     WARNING: Some existing user agents treat an absent Domain attribute
     as if the Domain attribute were present and contained the current
     host name.  For example, if site.example returns a Set-Cookie header
     field without a Domain attribute, these user agents will erroneously
     send the cookie to www.site.example and www.corp.site.example as
     well.

     The user agent will reject cookies unless the Domain attribute
     specifies a scope for the cookie that would include the origin
     server.  For example, the user agent will accept a cookie with a
     Domain attribute of "site.example" or of "foo.site.example" from
     foo.site.example, but the user agent will not accept a cookie with a
     Domain attribute of "bar.site.example" or of "baz.foo.site.example".

  4.1.2.4.  The Path Attribute

     The scope of each cookie is limited to a set of paths, controlled by
     the Path attribute.  If the server omits the Path attribute, the user
     agent will use the "directory" of the request-uri's path component as
     the default value.  (See Section 5.3.3 for more details.)

     The user agent will include the cookie in an HTTP request only if the
     path portion of the request-uri matches (or is a subdirectory of) the
     cookie's Path attribute, where the %x2F ("/") character is
     interpreted as a directory separator.

     Although seemingly useful for isolating cookies between different
     paths within a given host, the Path attribute cannot be relied upon
     for security (see Section 8).











  van Kesteren & Hofmann   Expires 19 October 2025               [Page 13]


  Internet-Draft                   Cookies                      April 2025


  4.1.2.5.  The Secure Attribute

     The Secure attribute limits the scope of the cookie to "secure"
     channels (where "secure" is outside the scope of this document).
     E.g., when a cookie has the Secure attribute, the user agent will
     include the cookie in an HTTP request only if the request is
     transmitted over a secure channel (typically HTTP over Transport
     Layer Security (TLS) [TLS13] [RFC9110]).

  4.1.2.6.  The HttpOnly Attribute

     The HttpOnly attribute limits the scope of the cookie to HTTP
     requests.  In particular, the attribute instructs the user agent to
     omit the cookie when providing access to cookies via non-HTTP APIs.

  4.1.2.7.  The SameSite Attribute

     The SameSite attribute limits the scope of the cookie upon creation
     and delivery with respect to whether the cookie is considered to be
     "same-site" within a larger context (where "same-site" is outside the
     scope of this document).  The SameSite attribute is particularly
     relevant for web browsers and web applications accessible through
     them.

     The SameSite attribute supports Strict, Lax, and None as values.

  4.1.3.  Cookie Name Prefixes

     Section 8.5 and Section 8.6 of this document spell out some of the
     drawbacks of cookies' historical implementation.  In particular, it
     is impossible for a server to have confidence that a given cookie was
     set with a particular set of attributes.  In order to provide such
     confidence in a backwards-compatible way, two common sets of
     requirements can be inferred from the first few characters of the
     cookie's name.

     To maximize compatibility with user agents, servers SHOULD use
     prefixes as described below.

  4.1.3.1.  The "__Secure-" Prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Secure-, then the cookie will have been set with a Secure
     attribute.

     For example, the following Set-Cookie header field would be rejected
     by a conformant user agent, as it does not have a Secure attribute.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 14]


  Internet-Draft                   Cookies                      April 2025


     Set-Cookie: __Secure-SID=12345; Domain=site.example

     Whereas the following Set-Cookie header field would be accepted if
     set from a secure origin (e.g. https://site.example/), and rejected
     otherwise:

     Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

  4.1.3.2.  The "__Host-" Prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Host-, then the cookie will have been set with a Secure attribute,
     a Path attribute with a value of /, and no Domain attribute.

     This combination yields a cookie that hews as closely as a cookie can
     to treating the origin as a security boundary.  The lack of a Domain
     attribute ensures that cookie's host-only is true, locking the cookie
     to a particular host, rather than allowing it to span subdomains.
     Setting the Path to / means that the cookie is effective for the
     entire host, and won't be overridden for specific paths.  The Secure
     attribute ensures that the cookie is unaltered by non-secure origins,
     and won't span protocols.

     Ports are the only piece of the same-origin policy that __Host-
     cookies continue to ignore.

     For example, the following cookies would always be rejected:

     Set-Cookie: __Host-SID=12345
     Set-Cookie: __Host-SID=12345; Secure
     Set-Cookie: __Host-SID=12345; Domain=site.example
     Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
     Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

     While the following would be accepted if set from a secure origin
     (e.g. https://site.example/), and rejected otherwise:

     Set-Cookie: __Host-SID=12345; Secure; Path=/

  4.2.  Cookie

  4.2.1.  Syntax

     The user agent sends stored cookies to the origin server in the
     Cookie header field.  If the server conforms to the requirements in
     Section 4.1 (and the user agent conforms to the requirements in
     Section 5), the user agent will send a Cookie header field that
     conforms to the following grammar:



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 15]


  Internet-Draft                   Cookies                      April 2025


     cookie        = cookie-string
     cookie-string = cookie-pair *( ";" SP cookie-pair )

     While Section 5.4 of [RFC9110] does not define a length limit for
     header fields it is likely that the web server's implementation does
     impose a limit; many popular implementations have default limits of 8
     kibibytes.  Servers SHOULD avoid setting a large number of large
     cookies such that the final cookie-string would exceed their header
     field limit.  Not doing so could result in requests to the server
     failing.

     Servers MUST be tolerant of multiple Cookie headers.  For example, an
     HTTP/2 [RFC9113] or HTTP/3 [HTTP] client or intermediary might split
     a Cookie header to improve compression.  Servers are free to
     determine what form this tolerance takes.  For example, the server
     could process each Cookie header individually or the server could
     concatenate all the Cookie headers into one and then process that
     final, single, header.  The server should be mindful of any header
     field limits when deciding which approach to take.

     Note: Since intermediaries can modify Cookie headers they should also
     be mindful of common server header field limits in order to avoid
     sending servers headers that they cannot process.  For example,
     concatenating multiple cookie headers into a single header might
     exceed a server's size limit.

  4.2.2.  Semantics

     Each cookie-pair represents a cookie stored by the user agent.  The
     cookie-pair contains the cookie-name and cookie-value the user agent
     received in the Set-Cookie header field.

     Notice that the cookie attributes are not returned.  In particular,
     the server cannot determine from the Cookie field alone when a cookie
     will expire, for which hosts the cookie is valid, for which paths the
     cookie is valid, or whether the cookie was set with the Secure or
     HttpOnly attributes.

     The semantics of individual cookies in the Cookie header field are
     not defined by this document.  Servers are expected to imbue these
     cookies with application-specific semantics.

     Although cookies are serialized linearly in the Cookie header field,
     servers SHOULD NOT rely upon the serialization order.  In particular,
     if the Cookie header field contains two cookies with the same name
     (e.g., that were set with different Path or Domain attributes),
     servers SHOULD NOT rely upon the order in which these cookies appear
     in the header field.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 16]


  Internet-Draft                   Cookies                      April 2025


  5.  User Agent Requirements

     This section specifies the processing models associated with the
     Cookie and Set-Cookie header fields in sufficient detail that a user
     agent can interoperate with existing servers (even those that do not
     conform to the well-behaved profile described in Section 4).

     A user agent could enforce more restrictions than those specified
     herein (e.g., restrictions specified by its cookie policy, described
     in Section 7.2).  However, such additional restrictions may reduce
     the likelihood that a user agent will be able to interoperate with
     existing servers.

  5.1.  Cookie Concepts

     To facilitate the algorithms that follow, a number of pre-requisite
     concepts need to be introduced.

  5.1.1.  Cookie Store And Limits

     A user agent has an associated *cookie store*, which is a list of
     cookies.  It is initially « ».

     A user agent has an associated *total cookies-per-host limit*, which
     is an integer.  It SHOULD be 50 or more.

     A user agent has an associated *total cookies limit*, which is an
     integer.  It SHOULD be 3000 or more.

     A user agent has an associated *cookie age limit*, which is a number
     of days.  It SHOULD be 400 days or less (see Section 7.2).

  5.1.2.  Cookie Struct

     A *cookie* is a struct that represents a piece of state to be
     transmitted between a client and a server.

     A cookie's *name* is a byte sequence.  It always needs to be set.

     A cookie's *value* is a byte sequence.  It always needs to be set.

     A cookie's *secure* is a boolean.  It is initially false.

     A cookie's *host* is a domain, IP address, null, or failure.  It is
     initially null.  Note: Once a cookie is in the user agent's cookie
     store its host is a domain or IP address.

     A cookie's *host-only* is a boolean.  It is initially false.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 17]


  Internet-Draft                   Cookies                      April 2025


     A cookie's *path* is a URL path.

     A cookie's *same-site* is "strict", "lax", "unset", or "none".  It is
     initially "unset".

     A cookie's *http-only* is a boolean.  It is initially false.

     A cookie's *creation-time* is a time.  It is initially the current
     time.

     A cookie's *expiry-time* is null or a time.  It is initially null.
     Note: A prior version of this specification referred to null with a
     distinct "persistent-flag" field being false.

     A cookie's *last-access-time* is a time.  It is initially the current
     time.

  5.1.2.1.  Cookie Struct Miscellaneous

     A cookie is *expired* if its expiry-time is non-null and its expiry-
     time is in the past.

  5.2.  Cookie Store Eviction

     The user agent SHOULD evict all expired cookies from its cookie store
     if, at any time, an expired cookie exists in the cookie store.

     When "the current session is over" (as defined by the user agent),
     the user agent MUST remove from the cookie store all cookies whose
     expiry-time is null.

  5.2.1.  Remove Excess Cookies for a Host

     To *Remove Excess Cookies for a Host* given a host _host_:

     1.  Let _insecureCookies_ be all cookies in the user agent's cookie
         store whose host is host-equal to _host_ and whose secure is
         false.

     2.  Sort _insecureCookies_ by earliest last-access-time first.

     3.  Let _secureCookies_ be all cookies in the user agent's cookie
         store whose host is host-equal to _host_ and whose secure is
         true.

     4.  Sort _secureCookies_ by earliest last-access-time first.





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 18]


  Internet-Draft                   Cookies                      April 2025


     5.  While _insecureCookies_'s size + _secureCookies_'s size is
         greater than the user agent's total cookies-per-host limit:

         1.  If _insecureCookies_ is not empty, remove the first item of
             _insecureCookies_ and delete the corresponding cookie from
             the user agent's cookie store.

         2.  Otherwise, remove the first item of _secureCookies_ and
             delete the corresponding cookie from the user agent's cookie
             store.

  5.2.2.  Remove Global Excess Cookies

     To *Remove Global Excess Cookies*:

     1.  Let _allCookies_ be the result of sorting the user agent's cookie
         store by earliest last-access-time first.

     2.  While _allCookies_'s size is greater than the user agent's total
         cookies limit:

         1.  Remove the first item of _allCookies_ and delete the
             corresponding cookie from the user agent's cookie store.

  5.3.  Subcomponent Algorithms

     This section defines some algorithms used by user agents to process
     specific subcomponents of the Cookie and Set-Cookie header fields.

  5.3.1.  Parse a Date

     To *Parse a Date* given a byte sequence _input_, run these steps.
     They return a date and time or failure.

     Note that the various boolean flags defined as a part of the
     algorithm (i.e., found-time, found-day-of-month, found-month, found-
     year) are initially "not set".

     1.  Using the grammar below, divide the cookie-date into date-tokens.












  van Kesteren & Hofmann   Expires 19 October 2025               [Page 19]


  Internet-Draft                   Cookies                      April 2025


        cookie-date     = *delimiter date-token-list *delimiter
        date-token-list = date-token *( 1*delimiter date-token )
        date-token      = 1*non-delimiter

        delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
        non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA
                          / %x7F-FF
        non-digit       = %x00-2F / %x3A-FF

        day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
        month           = ( "jan" / "feb" / "mar" / "apr" /
                            "may" / "jun" / "jul" / "aug" /
                            "sep" / "oct" / "nov" / "dec" ) *OCTET
        year            = 2*4DIGIT [ non-digit *OCTET ]
        time            = hms-time [ non-digit *OCTET ]
        hms-time        = time-field ":" time-field ":" time-field
        time-field      = 1*2DIGIT

     2.  Process each date-token sequentially in the order the date-tokens
         appear in the cookie-date:

         1.  If the found-time flag is not set and the token matches the
             time production, set the found-time flag and set the hour-
             value, minute-value, and second-value to the numbers denoted
             by the digits in the date-token, respectively.  Skip the
             remaining sub-steps and continue to the next date-token.

         2.  If the found-day-of-month flag is not set and the date-token
             matches the day-of-month production, set the found-day-of-
             month flag and set the day-of-month-value to the number
             denoted by the date-token.  Skip the remaining sub-steps and
             continue to the next date-token.

         3.  If the found-month flag is not set and the date-token matches
             the month production, set the found-month flag and set the
             month-value to the month denoted by the date-token.  Skip the
             remaining sub-steps and continue to the next date-token.

         4.  If the found-year flag is not set and the date-token matches
             the year production, set the found-year flag and set the
             year-value to the number denoted by the date-token.  Skip the
             remaining sub-steps and continue to the next date-token.

     3.  If the year-value is greater than or equal to 70 and less than or
         equal to 99, increment the year-value by 1900.

     4.  If the year-value is greater than or equal to 0 and less than or
         equal to 69, increment the year-value by 2000.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 20]


  Internet-Draft                   Cookies                      April 2025


         1.  NOTE: Some existing user agents interpret two-digit years
             differently.

     5.  If one of the following is true:

         *  at least one of the found-day-of-month, found-month, found-
            year, or found-time flags is not set,

         *  the day-of-month-value is less than 1 or greater than 31,

         *  the year-value is less than 1601,

         *  the hour-value is greater than 23,

         *  the minute-value is greater than 59, or

         *  the second-value is greater than 59,

         then return failure.

         (Note that leap seconds cannot be represented in this syntax.)

     6.  Let the parsed-cookie-date be the date whose day-of-month, month,
         year, hour, minute, and second (in UTC) are the day-of-month-
         value, the month-value, the year-value, the hour-value, the
         minute-value, and the second-value, respectively.  If no such
         date exists, abort these steps and fail to parse the cookie-date.

     7.  Return the parsed-cookie-date as the result of this algorithm.

  5.3.2.  Domain Matching

     A host _host_ *Domain-Matches* a string _domainAttributeValue_ if at
     least one of the following is true:

     *  _host_ equals _domainAttributeValue_, or

     *  if all of the following are true:

        -  _host_ is a domain, and

        -  _host_ ends with the concatenation of U+002E (.) and
           _domainAttributeValue_.

  5.3.3.  Cookie Default Path

     To determine the *Cookie Default Path*, given a URL path _path_, run
     these steps.  They return a URL path.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 21]


  Internet-Draft                   Cookies                      April 2025


     1.  Assert: _path_ is a non-empty list.

     2.  If _path_'s size is greater than 1, then remove _path_'s last
         item.

     3.  Otherwise, set _path_[0] to the empty string.

     4.  Return _path_.

  5.3.4.  Path Matching

     To determine if a URL path _requestPath_ *Path-Matches* a URL path
     _cookiePath_, run these steps.  They return a boolean.

     1.  Let _serializedRequestPath_ be the result of URL path serializing
         _requestPath_.

     2.  Let _serializedCookiePath_ be the result of URL path serializing
         _cookiePath_.

     3.  If _serializedCookiePath_ is _serializedRequestPath_, then return
         true.

     4.  If _serializedRequestPath_ starts with _serializedCookiePath_ and
         _serializedCookiePath_ ends with a U+002F (/), then return true.

     5.  Return whether the concatenation of _serializedRequestPath_
         followed by U+002F (/) starts with _serializedCookiePath_.

  5.4.  Main Algorithms

  5.4.1.  Parse and Store a Cookie

     To *Parse and Store a Cookie* given a byte sequence _input_, boolean
     _isSecure_, domain or IP address _host_, URL path _path_, boolean
     _httpOnlyAllowed_, boolean _allowNonHostOnlyCookieForPublicSuffix_,
     and boolean _sameSiteStrictOrLaxAllowed_:

     1.  Let _cookie_ be the result of running Parse a Cookie with
         _input_, _isSecure_, _host_, and _path_.

     2.  If _cookie_ is failure, then return.

     3.  Run Store a Cookie given _cookie_, _isSecure_, _host_, _path_,
         _httpOnlyAllowed_, _allowNonHostOnlyCookieForPublicSuffix_, and
         _sameSiteStrictOrLaxAllowed_.





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 22]


  Internet-Draft                   Cookies                      April 2025


  5.4.2.  Parse a Cookie

     To *Parse a Cookie* given a byte sequence _input_, boolean
     _isSecure_, host _host_, URL path _path_, run these steps.  They
     return a new cookie or failure:

     1.   If _input_ contains a byte in the range 0x00 to 0x08, inclusive,
          the range 0x0A to 0x1F inclusive, or 0x7F (CTL bytes excluding
          HTAB), then return failure.

     2.   Let _nameValueInput_ be null.

     3.   Let _attributesInput_ be the empty byte sequence.

     4.   If _input_ contains 0x3B (;), then set _nameValueInput_ to the
          bytes up to, but not including, the first 0x3B (;), and
          _attributesInput_ to the remainder of _input_ (including the
          0x3B (;) in question).

     5.   Otherwise, set _nameValueInput_ to _input_.

     6.   Assert: _nameValueInput_ is a byte sequence.

     7.   Let _name_ be null.

     8.   Let _value_ be null.

     9.   If _nameValueInput_ does not contain a 0x3D (=) character, then
          set _name_ to the empty byte sequence, and _value_ to
          _nameValueInput_.

     10.  Otherwise, set _name_ to the bytes up to, but not including, the
          first 0x3D (=), and set _value_ to the bytes after the first
          0x3D (=) (possibly being the empty byte sequence).

     11.  Remove any leading or trailing WSP bytes from _name_ and
          _value_.

     12.  If _name_'s length + _value_'s length is 0 or is greater than
          4096, then return failure.

     13.  Let _cookie_ be a new cookie whose name is _name_ and value is
          _value_.

     14.  Set _cookie_'s path to the result of running Cookie Default Path
          with _path_.

          Note: A Path attribute can override this.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 23]


  Internet-Draft                   Cookies                      April 2025


     15.  While _attributesInput_ is not an empty byte sequence:

          1.   Let _maxAgeSeen_ be false.

          2.   Let _char_ be the result of consuming the first byte of
               _attributesInput_.

          3.   Assert: _char_ is 0x3B (;).

          4.   Let _attributeNameValueInput_ be null.

          5.   If _attributesInput_ contains 0x3B (;), then set
               _attributeNameValueInput_ to the result of consuming the
               bytes of _attributesInput_ up to, but not including, the
               first 0x3B (;).

          6.   Otherwise, set _attributeNameValueInput_ to the result of
               consuming the remainder of _attributesInput_.

          7.   Let _attributeName_ be null.

          8.   Let _attributeValue_ be the empty string.

          9.   If _attributeNameValueInput_ contains a 0x3D (=), then set
               _attributeName_ to the bytes up to, but not including, the
               first 0x3D (=) of _attributeNameValueInput_, and
               _attributeValue_ to the bytes after the first 0x3D (=) of
               _attributeNameValueInput_.

          10.  Otherwise, set _attributeName_ to
               _attributeNameValueInput_.

          11.  Remove any leading or trailing WSP bytes from
               _attributeName_ and _attributeValue_.

          12.  If _attributeValue_'s length is greater than 1024, then
               continue.

          13.  If _attributeName_ is a byte-case-insensitive match for
               Expires:

               1.  If _maxAgeSeen_ is true, then continue.

               2.  Let _expiryTime_ be the result of running Parse a Date
                   given _attributeValue_.

               3.  If _attributeValue_ is failure, then continue.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 24]


  Internet-Draft                   Cookies                      April 2025


               4.  If _expiryTime_ is greater than the current time and
                   date + the user agent's cookie age limit, then set
                   _expiryTime_ to the user agent's cookie age limit.

               5.  If _expiryTime_ is earlier than the earliest date the
                   user agent can represent, the user agent MAY replace
                   _expiryTime_ with the earliest representable date.

               6.  Set _cookie_'s expiry-time to _expiryTime_.

          14.  If _attributeName_ is a byte-case-insensitive match for
               Max-Age:

               1.  If _attributeValue_ is empty, continue.

               2.  If the first byte of _attributeValue_ is neither a
                   DIGIT, nor 0x2D (-) followed by a DIGIT, then continue.

               3.  If the remainder of _attributeValue_ contains a non-
                   DIGIT, then continue.

               4.  Let _deltaSeconds_ be _attributeValue_, converted to a
                   base 10 integer.

               5.  Set _deltaSeconds_ to the smaller of _deltaSeconds_ and
                   the user agent's cookie age limit, in seconds.

               6.  If _deltaSeconds_ is less than or equal to 0, let
                   _expiryTime_ be the earliest representable date and
                   time.  Otherwise, let _expiryTime_ be the current date
                   and time + _deltaSeconds_ seconds.

               7.  Set _cookie_'s expiry-time to _expiryTime_.

               8.  Set _maxAgeSeen_ to true.

          15.  If _attributeName_ is a byte-case-insensitive match for
               Domain:

               1.  Let _host_ be failure.

               2.  If _attributeValue_ contains only ASCII bytes:

                   1.  Let _hostInput_ be _attributeValue_, ASCII decoded.

                   2.  If _hostInput_ starts with U+002E (.), then set
                       _hostInput_ to _hostInput_ without its leading
                       U+002E (.).



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 25]


  Internet-Draft                   Cookies                      April 2025


                   3.  Set _host_ to the result of host parsing
                       _hostInput_.

               3.  Set _cookie_'s host to _host_.

          16.  If _attributeName_ is a byte-case-insensitive match for
               Path:

               1.  If _attributeValue_ is not empty and if the first byte
                   of _attributeValue_ is 0x2F (/), then set _cookie_'s
                   path to _attributeValue_ split on 0x2F (/).

          17.  If _attributeName_ is a byte-case-insensitive match for
               Secure:

               1.  Set _cookie_'s secure to true.

          18.  If _attributeName_ is a byte-case-insensitive match for
               HttpOnly:

               1.  Set _cookie_'s http-only to true.

          19.  If _attributeName_ is a byte-case-insensitive match for
               SameSite:

               1.  If _attributeValue_ is a byte-case-insensitive match
                   for None, then set _cookie_'s same-site to "none".

               2.  If _attributeValue_ is a byte-case-insensitive match
                   for Strict, then set _cookie_'s same-site to "strict".

               3.  If _attributeValue_ is a byte-case-insensitive match
                   for Lax, then set _cookie_'s same-site to "lax".

     16.  Return _cookie_.

     Note: Attributes with an unrecognized _attributeName_ are ignored.

     Note: This intentionally overrides earlier cookie attributes so that
     generally the last specified cookie attribute "wins".

  5.4.3.  Store a Cookie

     To *Store a Cookie* given a cookie _cookie_, boolean _isSecure_,
     domain or IP address _host_, boolean _httpOnlyAllowed_, boolean
     _allowNonHostOnlyCookieForPublicSuffix_, and boolean
     _sameSiteStrictOrLaxAllowed_:




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 26]


  Internet-Draft                   Cookies                      April 2025


     1.   Assert: _cookie_'s name's length + _cookie_'s value's length is
          not 0 or greater than 4096.

     2.   Assert: _cookie_'s name does not contain a byte in the range
          0x00 to 0x08, inclusive, in the range 0x0A to 0x1F, inclusive,
          or 0x7F (CTL characters excluding HTAB).

     3.   If _cookie_'s host is failure, then return.

     4.   Set _cookie_'s creation-time and last-access-time to the current
          date and time.

     5.   If _allowNonHostOnlyCookieForPublicSuffix_ is false and
          _cookie_'s host is a public suffix:

          1.  If _cookie_'s host is host-equal to _host_, then set
              _cookie_'s host to null.

          2.  Otherwise, return.

          Note: This step prevents attacker.example from disrupting the
          integrity of site.example by setting a cookie with a Domain
          attribute of example.  In the event the end user navigates
          directly to example, a cookie can still be set and will forcibly
          have its host-only set to true.

     6.   If _cookie_'s host is null:

          1.  Set _cookie_'s host-only to true.

          2.  Set _cookie_'s host to _host_.

     7.   Otherwise:

          1.  If _host_ does not Domain-Match _cookie_'s host, then
              return.

          2.  Set _cookie_'s host-only to false.

     8.   Assert: _cookie_'s host is a domain or IP address.

     9.   If _httpOnlyAllowed_ is false and _cookie_'s http-only is true,
          then return.

     10.  If _isSecure_ is false:

          1.  If _cookie_'s secure-only is true, then return.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 27]


  Internet-Draft                   Cookies                      April 2025


          2.  If the user agent's cookie store contains at least one
              cookie _existingCookie_ that meets all of the following
              criteria:

              1.  _existingCookie_'s name is _cookie_'s name;

              2.  _existingCookie_'s secure-only is true;

              3.  _existingCookie_'s host Domain-Matches _cookie_'s host,
                  or vice-versa; and

              4.  _cookie_'s path Path-Matches _existingCookie_'s path,

              then return.

              Note: The path comparison is not symmetric, ensuring only
              that a newly-created, non-secure cookie does not overlay an
              existing secure cookie, providing some mitigation against
              cookie-fixing attacks.  That is, given an existing secure
              cookie named 'a' with a path of '/login', a non-secure
              cookie named 'a' could be set for a path of '/' or '/foo',
              but not for a path of '/login' or '/login/en'.

     11.  If _cookie_'s same-site is not "none" and
          _sameSiteStrictOrLaxAllowed_ is false, then return.

     12.  If _cookie_'s same-site is "none" and _cookie_'s secure-only is
          false, then return.

     13.  If _cookie_'s name, byte-lowercased, starts with __secure- and
          _cookie_'s secure-only is false, then return.

          Note: The check here and those below are with a byte-lowercased
          value in order to protect servers that process these values in a
          case-insensitive manner.

     14.  If _cookie_'s name, byte-lowercased, starts with __host- and not
          all of the following are true:

          1.  _cookie_'s secure-only is true;

          2.  _cookie_'s host-only is true; and

          3.  _cookie_'s path's size is 1 and _cookie_'s path[0] is the
              empty string,

          then return.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 28]


  Internet-Draft                   Cookies                      April 2025


     15.  If _cookie_'s name is the empty byte sequence and one of the
          following is true:

          *  _cookie_'s value, byte-lowercased, starts with __secure-, or

          *  _cookie_'s value, byte-lowercased, starts with __host-

          then return.

     16.  If the user agent's cookie store contains a cookie _oldCookie_
          whose name is _cookie_'s name, host is host-equal to _cookie_'s
          host, host-only is _cookie_'s host-only, and path is path-equal
          to _cookie_'s path:

          1.  If _httpOnlyAllowed_ is false and _oldCookie_'s http-only is
              true, then return.

          2.  Set _cookie_'s creation-time to _oldCookie_'s creation-time.

          3.  Remove _oldCookie_ from the user agent's cookie store.

          Note: This algorithm maintains the invariant that there is at
          most one such cookie.

     17.  Insert _cookie_ into the user agent's cookie store.

     18.  Remove all expired cookies from the user agent's cookie store.

     19.  Run Remove Excess Cookies for Host given _cookie_'s host.

     20.  Run Remove Global Excess Cookies.

  5.4.4.  Retrieve Cookies

     To *Retrieve Cookies* given a boolean _isSecure_, host _host_, URL
     path _path_, boolean _httpOnlyAllowed_, and string _sameSite_:

     1.  Assert: _sameSite_ is "strict-or-less", "lax-or-less", "unset-or-
         less", or "none".

     2.  Let _cookies_ be all cookies from the user agent's cookie store
         that meet these conditions:

         *  One of the following is true:

            -  cookie's host-only is true and _host_ is host-equal to
               cookie's host, or




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 29]


  Internet-Draft                   Cookies                      April 2025


            -  cookie's host-only is false and _host_ Domain-Matches
               cookie's host.

            It's possible that the public suffix list changed since a
            cookie was created.  If this change results in a cookie's host
            becoming a public suffix and the cookie's host-only is false,
            then that cookie SHOULD NOT be returned.

            XXX: We should probably move this requirement out-of-bound as
            this invalidation should happen as part of updating the public
            suffixes.

         *  _path_ Path-Matches cookie's path.

         *  One of the following is true:

            -  cookie's secure is true and _isSecure_ is true, or

            -  cookie's secure is false.

         *  One of the following is true:

            -  cookie's http-only is true and _httpOnlyAllowed_ is true,
               or

            -  cookie's http-only is false.

         *  One of the following is true:

            -  cookie's same-site is "strict" and _sameSite_ is "strict-
               or-less";

            -  cookie's same-site is "lax" and _sameSite_ is one of
               "strict-or-less" or "lax-or-less";

            -  cookie's same-site is "unset" and _sameSite_ is one of
               "strict-or-less", "lax-or-less", or "unset-or-less"; or

            -  cookie's same-site is "none".

     3.  Sort _cookies_ in the following order:

         *  Cookies whose path's size is greater are listed before cookies
            whose path's size is smaller.

         *  Among cookies whose path's size is equal, cookies whose
            creation-time is earlier are listed before cookies whose
            creation-time is later.



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 30]


  Internet-Draft                   Cookies                      April 2025


     4.  Set the last-access-time of each cookie of _cookies_ to the
         current date and time and reflect these changes in the user
         agent's cookie store.

     5.  Return _cookies_.

  5.4.5.  Serialize Cookies

     To *Serialize Cookies* given a list of cookies _cookies_:

     1.  Let _output_ be an empty byte sequence.

     2.  For each _cookie_ of _cookies_:

         1.  If _output_ is not the empty byte sequence, then append 0x3B
             (;) followed by 0x20 (SP) to _output_.

         2.  If _cookie_'s name is not the empty byte sequence, then
             append _cookie_'s name followed by 0x3D (=) to _output_.

         3.  Append _cookie_'s value to _output_.

     3.  Return _output_.

  5.5.  Requirements Specific to Non-Browser User Agents

  5.5.1.  The Set-Cookie Header Field

     When a user agent receives a Set-Cookie header field in an HTTP
     response, the user agent MAY ignore the Set-Cookie header field in
     its entirety as per its cookie policy (see Section 7.2).

     User agents MAY ignore Set-Cookie header fields contained in
     responses with 100-level status codes.

     Set-Cookie header fields contained in responses with non-100-level
     status codes (including those in responses with 400- and 500-level
     status codes) SHOULD be processed as follows:

     1.  Let _isSecure_ be a boolean indicating whether request's URL's
         scheme is deemed secure, in an implementation-defined manner.

     2.  Let _host_ be request's host.

     3.  Let _path_ be request's URL's path.

     4.  Let _httpOnlyAllowed_ be true.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 31]


  Internet-Draft                   Cookies                      April 2025


     5.  Let _allowNonHostOnlyCookieForPublicSuffix_ be a boolean whose
         value is implementation-defined.

     6.  Let _sameSiteStrictOrLaxAllowed_ be a boolean whose value is
         implementation-defined.

     7.  Let _cookie_ be the result of running Parse and Store a Cookie
         given the header field value, _isSecure_, _host_, _path_,
         _httpOnlyAllowed_, _allowNonHostOnlyCookieForPublicSuffix_, and
         _sameSiteStrictOrLaxAllowed_.

  5.5.2.  The Cookie Header Field

     The user agent includes stored cookies in the Cookie request header
     field.

     When the user agent generates an HTTP request, the user agent MUST
     NOT attach more than one Cookie header field.

     A user agent MAY omit the Cookie header field in its entirety.

     If the user agent does attach a Cookie header field to an HTTP
     request, the user agent MUST compute its value as follows:

     1.  Let _isSecure_ be a boolean indicating whether request's URL's
         scheme is deemed secure, in an implementation-defined manner.

     2.  Let _host_ be request's host.

     3.  Let _path_ be request's URL's path.

     4.  Let _httpOnlyAllowed_ be true.

     5.  Let _sameSite_ be a string whose value is implementation-defined,
         but has to be one of "strict-or-less", "lax-or-less", "unset-or-
         less", or "none".

     6.  Let _cookies_ be the result of running Retrieve Cookies given
         _isSecure_, _host_, _path_, _httpOnlyAllowed_, and _sameSite_.

     7.  Return the result of running Serialize Cookies given _cookies_.

     Note: Previous versions of this specification required that only one
     Cookie header field be sent in requests.  This is no longer a
     requirement.  While this specification requires that a single cookie-
     string be produced, some user agents may split that string across
     multiple Cookie header fields.  For examples, see Section 8.2.3 of
     [RFC9113] and Section 4.2.1 of [HTTP].



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 32]


  Internet-Draft                   Cookies                      April 2025


  5.6.  Requirements Specific to Browser User Agents

     While browsers are expected to generally follow the same model as
     non-browser user agents, they have additional complexity due to the
     document model (and the ability to nest documents) that is considered
     out-of-scope for this specification.

     Specifications for such a user agent are expected to build upon the
     following algorithms and invoke them appropriately to process Cookie
     and Set-Cookie header fields, as well as manipulating the user
     agent's cookie store through non-HTTP APIs:

     *  Parse and Store a Cookie

     *  Store a Cookie

     *  Retrieve Cookies

     *  Serialize Cookies

     This provides the flexibility browsers need to detail their
     requirements in considerable detail.

  6.  Implementation Considerations

  6.1.  Limits

     Servers SHOULD use as few and as small cookies as possible to avoid
     reaching these implementation limits, minimize network bandwidth due
     to the Cookie header field being included in every request, and to
     avoid reaching server header field limits (See Section 4.2.1).

     Servers SHOULD gracefully degrade if the user agent fails to return
     one or more cookies in the Cookie header field because the user agent
     might evict any cookie at any time.

  6.2.  Application Programming Interfaces

     One reason the Cookie and Set-Cookie header fields use such esoteric
     syntax is that many platforms (both in servers and user agents)
     provide a string-based application programming interface (API) to
     cookies, requiring application-layer programmers to generate and
     parse the syntax used by the Cookie and Set-Cookie header fields,
     which many programmers have done incorrectly, resulting in
     interoperability problems.






  van Kesteren & Hofmann   Expires 19 October 2025               [Page 33]


  Internet-Draft                   Cookies                      April 2025


     Instead of providing string-based APIs to cookies, platforms would be
     well-served by providing more semantic APIs.  It is beyond the scope
     of this document to recommend specific API designs, but there are
     clear benefits to accepting an abstract "Date" object instead of a
     serialized date string.

  7.  Privacy Considerations

     Cookies' primary privacy risk is their ability to correlate user
     activity.  This can happen on a single site, but is most problematic
     when activity is tracked across different, seemingly unconnected Web
     sites to build a user profile.

     Over time, this capability (warned against explicitly in [RFC2109]
     and all of its successors) has become widely used for varied reasons
     including:

     *  authenticating users across sites,

     *  assembling information on users,

     *  protecting against fraud and other forms of undesirable traffic,

     *  targeting advertisements at specific users or at users with
        specified attributes,

     *  measuring how often ads are shown to users, and

     *  recognizing when an ad resulted in a change in user behavior.

     While not every use of cookies is necessarily problematic for
     privacy, their potential for abuse has become a widespread concern in
     the Internet community and broader society.  In response to these
     concerns, user agents have actively constrained cookie functionality
     in various ways (as allowed and encouraged by previous
     specifications), while avoiding disruption to features they judge
     desirable for the health of the Web.

     It is too early to declare consensus on which specific mechanism(s)
     should be used to mitigate cookies' privacy impact; user agents'
     ongoing changes to how they are handled are best characterised as
     experiments that can provide input into that eventual consensus.

     Instead, this document describes limited, general mitigations against
     the privacy risks associated with cookies that enjoy wide deployment
     at the time of writing.  It is expected that implementations will
     continue to experiment and impose stricter, more well-defined
     limitations on cookies over time.  Future versions of this document



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 34]


  Internet-Draft                   Cookies                      April 2025


     might codify those mechanisms based upon deployment experience.  If
     functions that currently rely on cookies can be supported by
     separate, targeted mechanisms, they might be documented in separate
     specifications and stricter limitations on cookies might become
     feasible.

     Note that cookies are not the only mechanism that can be used to
     track users across sites, so while these mitigations are necessary to
     improve Web privacy, they are not sufficient on their own.

  7.1.  Third-Party Cookies

     A "third-party" or cross-site cookie is one that is associated with
     embedded content (such as scripts, images, stylesheets, frames) that
     is obtained from a different server than the one that hosts the
     primary resource (usually, the Web page that the user is viewing).
     Third-party cookies are often used to correlate users' activity on
     different sites.

     Because of their inherent privacy issues, most user agents now limit
     third-party cookies in a variety of ways.  Some completely block
     third-party cookies by refusing to process third-party Set-Cookie
     header fields and refusing to send third-party Cookie header fields.
     Some partition cookies based upon the first-party context, so that
     different cookies are sent depending on the site being browsed.  Some
     block cookies based upon user agent cookie policy and/or user
     controls.

     While this document does not endorse or require a specific approach,
     it is RECOMMENDED that user agents adopt a policy for third-party
     cookies that is as restrictive as compatibility constraints permit.
     Consequently, resources cannot rely upon third-party cookies being
     treated consistently by user agents for the foreseeable future.

  7.2.  Cookie Policy

     User agents MAY enforce a cookie policy consisting of restrictions on
     how cookies may be used or ignored (see Section 5.5.1).

     A cookie policy may govern which domains or parties, as in first and
     third parties (see Section 7.1), for which the user agent will allow
     cookie access.  The policy can also define limits on cookie size,
     cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the
     number of cookies per domain or in total.

     The goal of a restrictive cookie policy is often to improve security
     or privacy.  User agents often allow users to change the cookie
     policy (see Section 7.3).



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 35]


  Internet-Draft                   Cookies                      April 2025


  7.3.  User Controls

     User agents SHOULD provide users with a mechanism for managing the
     cookies stored in the cookie store.  For example, a user agent might
     let users delete all cookies received during a specified time period
     or all the cookies related to a particular domain.  In addition, many
     user agents include a user interface element that lets users examine
     the cookies stored in their cookie store.

     User agents SHOULD provide users with a mechanism for disabling
     cookies.  When cookies are disabled, the user agent MUST NOT include
     a Cookie header field in outbound HTTP requests and the user agent
     MUST NOT process Set-Cookie header fields in inbound HTTP responses.

     User agents MAY offer a way to change the cookie policy (see
     Section 7.2).

     User agents MAY provide users the option of preventing persistent
     storage of cookies across sessions.  When configured thusly, user
     agents MUST treat all received cookies as if their expiry-time is
     null.

  7.4.  Expiration Dates

     Although servers can set the expiration date for cookies to the
     distant future, most user agents do not actually retain cookies for
     multiple decades.  Rather than choosing gratuitously long expiration
     periods, servers SHOULD promote user privacy by selecting reasonable
     cookie expiration periods based on the purpose of the cookie.  For
     example, a typical session identifier might reasonably be set to
     expire in two weeks.

  8.  Security Considerations

  8.1.  Overview

     Cookies have a number of security pitfalls.  This section overviews a
     few of the more salient issues.

     In particular, cookies encourage developers to rely on ambient
     authority for authentication, often becoming vulnerable to attacks
     such as cross-site request forgery [CSRF].  Also, when storing
     session identifiers in cookies, developers often create session
     fixation vulnerabilities.

     Transport-layer encryption, such as that employed in HTTPS, is
     insufficient to prevent a network attacker from obtaining or altering
     a victim's cookies because the cookie protocol itself has various



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 36]


  Internet-Draft                   Cookies                      April 2025


     vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
     below).  In addition, by default, cookies do not provide
     confidentiality or integrity from network attackers, even when used
     in conjunction with HTTPS.

  8.2.  Ambient Authority

     A server that uses cookies to authenticate users can suffer security
     vulnerabilities because some user agents let remote parties issue
     HTTP requests from the user agent (e.g., via HTTP redirects or HTML
     forms).  When issuing those requests, user agents attach cookies even
     if the remote party does not know the contents of the cookies,
     potentially letting the remote party exercise authority at an unwary
     server.

     Although this security concern goes by a number of names (e.g.,
     cross-site request forgery, confused deputy), the issue stems from
     cookies being a form of ambient authority.  Cookies encourage server
     operators to separate designation (in the form of URLs) from
     authorization (in the form of cookies).  Consequently, the user agent
     might supply the authorization for a resource designated by the
     attacker, possibly causing the server or its clients to undertake
     actions designated by the attacker as though they were authorized by
     the user.

     Instead of using cookies for authorization, server operators might
     wish to consider entangling designation and authorization by treating
     URLs as capabilities.  Instead of storing secrets in cookies, this
     approach stores secrets in URLs, requiring the remote entity to
     supply the secret itself.  Although this approach is not a panacea,
     judicious application of these principles can lead to more robust
     security.

  8.3.  Clear Text

     Unless sent over a secure channel (such as TLS [TLS13]), the
     information in the Cookie and Set-Cookie header fields is transmitted
     in the clear.

     1.  All sensitive information conveyed in these header fields is
         exposed to an eavesdropper.

     2.  A malicious intermediary could alter the header fields as they
         travel in either direction, with unpredictable results.

     3.  A malicious client could alter the Cookie header fields before
         transmission, with unpredictable results.




  van Kesteren & Hofmann   Expires 19 October 2025               [Page 37]


  Internet-Draft                   Cookies                      April 2025


     Servers SHOULD encrypt and sign the contents of cookies (using
     whatever format the server desires) when transmitting them to the
     user agent (even when sending the cookies over a secure channel).
     However, encrypting and signing cookie contents does not prevent an
     attacker from transplanting a cookie from one user agent to another
     or from replaying the cookie at a later time.

     In addition to encrypting and signing the contents of every cookie,
     servers that require a higher level of security SHOULD use the Cookie
     and Set-Cookie header fields only over a secure channel.  When using
     cookies over a secure channel, servers SHOULD set the Secure
     attribute (see Section 4.1.2.5) for every cookie.  If a server does
     not set the Secure attribute, the protection provided by the secure
     channel will be largely moot.

     For example, consider a webmail server that stores a session
     identifier in a cookie and is typically accessed over HTTPS.  If the
     server does not set the Secure attribute on its cookies, an active
     network attacker can intercept any outbound HTTP request from the
     user agent and redirect that request to the webmail server over HTTP.
     Even if the webmail server is not listening for HTTP connections, the
     user agent will still include cookies in the request.  The active
     network attacker can intercept these cookies, replay them against the
     server, and learn the contents of the user's email.  If, instead, the
     server had set the Secure attribute on its cookies, the user agent
     would not have included the cookies in the clear-text request.

  8.4.  Session Identifiers

     Instead of storing session information directly in a cookie (where it
     might be exposed to or replayed by an attacker), servers commonly
     store a nonce (or "session identifier") in a cookie.  When the server
     receives an HTTP request with a nonce, the server can look up state
     information associated with the cookie using the nonce as a key.

     Using session identifier cookies limits the damage an attacker can
     cause if the attacker learns the contents of a cookie because the
     nonce is useful only for interacting with the server (unlike non-
     nonce cookie content, which might itself be sensitive).  Furthermore,
     using a single nonce prevents an attacker from "splicing" together
     cookie content from two interactions with the server, which could
     cause the server to behave unexpectedly.

     Using session identifiers is not without risk.  For example, the
     server SHOULD take care to avoid "session fixation" vulnerabilities.
     A session fixation attack proceeds in three steps.  First, the
     attacker transplants a session identifier from his or her user agent
     to the victim's user agent.  Second, the victim uses that session



  van Kesteren & Hofmann   Expires 19 October 2025               [Page 38]


  Internet-Draft                   Cookies                      April 2025


     identifier to interact with the server, possibly imbuing the session
     identifier with the user's credentials or confidential information.
     Third, the attacker uses the session identifier to interact with
     server directly, possibly obtaining the user's authority or
     confidential information.

  8.5.  Weak Confidentiality

     Cookies do not provide isolation by port.  If a cookie is readable by
     a service running on one port, the cookie is also readable by a
     service running on another port of the same server.  If a cookie is
     writable by a service on one port, the cookie is also writable by a
     service running on another port of the same server.  For this reason,
     servers SHOULD NOT both run mutually distrusting services on
     different ports of the same host and use cookies to store security-
     sensitive information.

     Cookies do not provide isolation by scheme.  Although most commonly
     used with the http and https schemes, the cookies for a given host
     might also be available to other schemes, such as ftp and gopher.
     Although this lack of isolation by scheme is most apparent in non-
     HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
     API), the lack of isolation by scheme is actually present in
     requirements for processing cookies themselves (e.g., consider
     retrieving a URI with the gopher scheme via HTTP).

     Cookies do not always provide isolation by path.  Although the
     network-level protocol does not send cookies stored for one path to
     another, some user agents expose cookies via non-HTTP APIs, such as
     HTML's document.cookie API.  Because some of these user agents (e.g.,
     web browsers) do not isolate resources received from different paths,
     a resource retrieved from one path might be able to access cookies
     stored for another path.

  8.6.  Weak Integrity

     Cookies do not provide integrity guarantees for sibling domains (and
     their subdomains).  For example, consider foo.site.example and
     bar.site.example.  The foo.site.example server can set a cookie with
     a Domain attribute of "site.example" (possibly overwriting an
     existing "site.example" cookie set by bar.site.example), and the user
     agent will include that cookie in HTTP requests to bar.site.example.
     In the worst case, bar.site.example will be unable to distinguish
     this cookie from a cookie it set itself.  The foo.site.example server
     might be able to leverage this ability to mount an attack against
     bar.site.example.





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 39]


  Internet-Draft                   Cookies                      April 2025


     Even though the Set-Cookie header field supports the Path attribute,
     the Path attribute does not provide any integrity protection because
     the user agent will accept an arbitrary Path attribute in a Set-
     Cookie header field.  For example, an HTTP response to a request for
     http://site.example/foo/bar can set a cookie with a Path attribute of
     "/qux".  Consequently, servers SHOULD NOT both run mutually
     distrusting services on different paths of the same host and use
     cookies to store security-sensitive information.

     An active network attacker can also inject cookies into the Cookie
     header field sent to https://site.example/ by impersonating a
     response from http://site.example/ and injecting a Set-Cookie header
     field.  The HTTPS server at site.example will be unable to
     distinguish these cookies from cookies that it set itself in an HTTPS
     response.  An active network attacker might be able to leverage this
     ability to mount an attack against site.example even if site.example
     uses HTTPS exclusively.

     Servers can partially mitigate these attacks by encrypting and
     signing the contents of their cookies, or by naming the cookie with
     the __Secure- prefix.  However, using cryptography does not mitigate
     the issue completely because an attacker can replay a cookie he or
     she received from the authentic site.example server in the user's
     session, with unpredictable results.

     Finally, an attacker might be able to force the user agent to delete
     cookies by storing a large number of cookies.  Once the user agent
     reaches its storage limit, the user agent will be forced to evict
     some cookies.  Servers SHOULD NOT rely upon user agents retaining
     cookies.

  8.7.  Reliance on DNS

     Cookies rely upon the Domain Name System (DNS) for security.  If the
     DNS is partially or fully compromised, the cookie protocol might fail
     to provide the security properties required by applications.

  8.8.  SameSite Cookies

     SameSite cookies offer a robust defense against CSRF attack when
     deployed in strict mode, and when supported by the client.  It is,
     however, prudent to ensure that this designation is not the extent of
     a site's defense against CSRF, as same-site navigations and
     submissions can certainly be executed in conjunction with other
     attack vectors such as cross-site scripting.






  van Kesteren & Hofmann   Expires 19 October 2025               [Page 40]


  Internet-Draft                   Cookies                      April 2025


     Developers are strongly encouraged to deploy the usual server-side
     defenses (CSRF tokens, ensuring that "safe" HTTP methods are
     idempotent, etc) to mitigate the risk more fully.

  9.  IANA Considerations

  9.1.  Cookie

     The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to
     be updated with the following registration:

     Header field name:  Cookie

     Applicable protocol:  http

     Status:  standard

     Author/Change controller:  IETF

     Specification document:  this specification (Section 5.5.2)

  9.2.  Set-Cookie

     The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to
     be updated with the following registration:

     Header field name:  Set-Cookie

     Applicable protocol:  http

     Status:  standard

     Author/Change controller:  IETF

     Specification document:  this specification (Section 5.5.1)

  10.  Changes

     Revamped the document to allow for more detailed requirements on
     browsers in downstream specifications.

  Acknowledgements

     Many thanks to Adam Barth for laying the groundwork for a modern
     cookie specification with RFC 6265.






  van Kesteren & Hofmann   Expires 19 October 2025               [Page 41]


  Internet-Draft                   Cookies                      April 2025


     And thanks to John Wilander, Lily Chen, Mike West, Steven Bingler,
     and Steven Englehardt for improving upon that work in subsequent
     drafts.

  References

  Normative References

     [HTML]     Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt,
                P., and D. Denicola, "HTML", n.d.,
                <https://html.spec.whatwg.org/>.

     [INFRA]    van Kesteren, A. and D. Denicola, "Infra", n.d.,
                <https://infra.spec.whatwg.org>.

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

     [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
                Application and Support", STD 3, RFC 1123,
                DOI 10.17487/RFC1123, October 1989,
                <https://www.rfc-editor.org/rfc/rfc1123>.

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

     [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5234>.

     [URL]      van Kesteren, A., "URL", n.d.,
                <https://url.spec.whatwg.org>.

  Informative References

     [CSRF]     Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
                for Cross-Site Request Forgery",
                DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7,
                ACM CCS '08: Proceedings of the 15th ACM conference on
                Computer and communications security (pages 75-88),
                October 2008,
                <http://portal.acm.org/citation.cfm?id=1455770.1455782>.





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 42]


  Internet-Draft                   Cookies                      April 2025


     [HTTP]     Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
                June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

     [HttpFieldNameRegistry]
                "Hypertext Transfer Protocol (HTTP) Field Name Registry",
                n.d., <https://www.iana.org/assignments/http-fields/>.

     [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
                Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997,
                <https://www.rfc-editor.org/rfc/rfc2109>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4648>.

     [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
                DOI 10.17487/RFC6265, April 2011,
                <https://www.rfc-editor.org/rfc/rfc6265>.

     [RFC7034]  Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
                Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7034>.

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

     [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
                DOI 10.17487/RFC9113, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9113>.

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

  Authors' Addresses

     Anne van Kesteren (editor)
     Apple
     Email: annevk@annevk.nl


     Johann Hofmann (editor)
     Google
     Email: johannhof@google.com





  van Kesteren & Hofmann   Expires 19 October 2025               [Page 43]


name: draft-daviel-html-geo-tag
rev: 08
title: Geographic registration of HTML documents
time: 2024-12-18T18:43:37Z
group_uri: /api/v1/group/group/934/
expires: 2008-05-03T08:28:49Z
ad: /api/v1/person/person/2515/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578533+00:00
source: ietf
abstract:
  This memo describes a method of registering HTML documents with a
  specific geographic location through means of embedded META tags.
  The content of the META tags gives the geographic position of the
  resource described by the HTML document in terms of Latitude,
  Longitude, and optionally Elevation in a simple, machine-readable
  manner.  This information may be used for automated resource
  discovery by means of an HTML indexing agent or search engine.  META
  tags giving a civic location of a resource are also described.

full_text:
  INTERNET-DRAFT                                     Vancouver Webpages
  <draft-daviel-html-geo-tag-08.txt>                   October 30, 2007
  Expires: May 2, 2008
  Intended status: Standards Track

                 Geographic registration of HTML documents

  Status of this Memo

     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of 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 April 1, 2008.


  Abstract

     This memo describes a method of registering HTML documents with a
     specific geographic location through means of embedded META tags.
     The content of the META tags gives the geographic position of the
     resource described by the HTML document in terms of Latitude,
     Longitude, and optionally Elevation in a simple, machine-readable
     manner.  This information may be used for automated resource
     discovery by means of an HTML indexing agent or search engine.  META
     tags giving a civic location of a resource are also described.


  1.  Introduction

     Many resources described by HTML documents on the World-Wide-Web are



  Daviel,Kaegi                                                    [Page 1]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     associated with a particular place on the Earth's surface.  While
     resource discovery on the Web has thus far focussed on document title
     and open-text keyword searching, in these cases it may be beneficial
     to facilitate geographic searching.  Examples of this kind of
     resource include pages describing restaurants, shipwrecks, retail
     stores etc. Consumers may use this information in order to select the
     closest facility, and in order to navigate towards a resource by
     road, on foot or by other means.

     Although some resources, such as restaurants, have a street address
     which may be mapped to geographic location by existing tools, other
     objects on the Web, such as a photograph of a mountain, may not.

     This draft describes a method of adding static location data to
     legacy HTML documents using a construct that is familiar to many HTML
     authors.  It is intended to be concise, unambiguous, simple to use
     and compatible with existing editing tools.  The intended use is to
     provide location data to Web robots that typically revisit pages
     every few weeks.

     It is anticipated that in many cases this location data will be added
     manually by persons unfamiliar with GIS terminology or metadata
     standards.  For this reason a minimal data set with few options is
     preferred over a more complex and extensible one.

     The method described in this draft is not intended to preempt
     existing or future metadata encapsulation schemes which may better
     serve the needs of a particular community, such as geographic
     information systems (GIS). Nor is it intended to preempt richer, more
     structured data encapsulations such as RDF or XML, which typically
     require software to generate correctly.

  2.  Coordinate Systems

     Resource positions on the Earth's surface should be expressed in
     degrees North of Latitude, degrees East of Longitude as signed
     decimal numbers.

     Where the precision of the coordinates is such that the datum used is
     significant, typically more precise than one kilometre distance,
     positions should be converted to the WGS 84 datum [WGS84].
     Elevations, if given, should be in metres above datum.  Positions
     given by a GPS set [GPS] with datum set to "WGS 84" will in most
     cases be adequate, of the order of 15 metres accuracy in horizontal
     position and 25 metres in elevation.

     It should be noted that elevations referred to the WGS 84 geoid will
     in some areas differ appreciably from those measured with respect to



  Daviel,Kaegi                                                    [Page 2]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     local datum in coastal regions, which may be Mean High Water Springs,
     Mean Sea Level, Higher High Water or a similar reference level, and
     will differ substantially from "ground level".  Use of elevation is
     not recommended unless its value may be reliably determined.


  3.  Implementation

     XHTML, HTML or WML markup should be added to the document in the form
     of a META statement.  This should be placed in the document head in
     accordance with the XHTML specification [XHTML].

     There are several possible GEO identifiers:
     The identifier "geo.position" is used for  Latitude, Longitude and
     optionally Elevation data.
     The identifier "geo.country" is used for the two-letter country code
     from ISO 3166 [ISO3166], e.g.  "US" (United States), "DE" (Germany).
     The identifiers "geo.a1", "geo.a2" etc. are used to define a civic
     address, as in RFC 4776 [RFC4776].

     For resources within the United States and Canada, the "geo.a1"
     identifier corresponds to and the common 2-character State/Province
     codes [STATES][PROVINCES], e.g. "BC" (British Columbia), "CA"
     (California)

     To facilitate machine indexing, wherever possible a controlled list
     should be used for civic elements. For instance, ISO 3166-2
     [ISO3166-2] might be used for "geo.a1"

     Use of the numeric "geo.position" is generally recommended to ensure
     accurate indexing.  However, if the resource described is localized
     to a country or region, but not to a single point, the civic
     identifiers "geo.country", "geo.a1" etc. may be used alone without a
     corresponding "geo.position" identifier.


     It is the intention of this draft to provide a means to associate a
     single point with an XHTML, HTML or WML document.  Some consideration
     should be given to the choice of location when describing a resource,
     given that positioning mechanisms may provide an accuracy of the
     order of ten metres in horizontal position.  For instance, when
     describing a retail store or small business, it may be more
     meaningful to give the position of the street entrance rather than
     the position of the center of the property.


     Although the XHTML specification [XHTML] states that the name field
     is in general case-sensitive, these GEO tags should be recognized by



  Daviel,Kaegi                                                    [Page 3]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     compliant agents regardless of case.  Coordinates should be ordered
     (Latitude ; Longitude) as for RFC 2426, RFC 2445 (vCard and iCal
     specifications) [ICAL][VCARD].  If elevation is given, coordinates
     should be ordered (Latitude ; Longitude ; Elevation).

  3.1 Migration from earlier versions

     To migrate documents and applicaitons written against earlier
     versions of this draft, the following correspondences are noted:

     geo.position       geo.position
     geo.region         geo.country   (2 character region)
     geo.region         geo.country and geo.a1  (extended region XX-YYY)
     geo.placename      geo.lmk     (landmark or vanity address)

  4. Examples

       <meta name="geo.position" content="48.54;-123.84;115" />

     describes a resource 115 metres above datum at position
     48.54 degrees North, 123.84 degrees West, while

       <meta name="geo.position" content="-10;60" />

     describes a resource at position 10 degrees South,
     60 degrees East.

       <meta name="geo.country" content="CA" />
       <meta name="geo.a1" content="ON" />
       <meta name="geo.a3" content="London" />

     describes a resource in London, Ontario, Canada,
     while

       <meta name="geo.country" content="GB" />
       <meta name="geo.a1" "LND" />
       <meta name="geo.a3" content="London" />

     describes a resource in London, England (Great Britain).

  5. Semantics

     Values for latitude and longitude shall be expressed as decimal
     fractions of degrees.  Whole degrees of latitude shall be represented
     by a decimal number ranging from 0 through 90.  Whole degrees of
     longitude shall be represented by a decimal number ranging from 0
     through 180.  When a decimal fraction of a degree is specified, it
     shall be separated from the whole number of degrees by a decimal



  Daviel,Kaegi                                                    [Page 4]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     point (the period character, ".").  Decimal fractions of a degree
     should be expressed to the precision available, with trailing zeroes
     being used as placeholders if required.  A decimal point is optional
     where the precision is less than one degree.  Some effort should be
     made to preserve the apparent precision when converting from another
     datum or representation, for example 41 degrees 13 minutes should be
     represented as 41.22 and not 41.21666, while 41 13' 11" may be
     represented as 41.2197.

     Latitudes north of the equator MAY be specified by a plus sign (+),
     or by the absence of a minus sign (-), preceding the designating
     degrees.  Latitudes south of the Equator MUST be designated by a
     minus sign (-) preceding the digits designating degrees.  Latitudes
     on the Equator MUST be designated by a latitude value of 0.

     Longitudes east of the prime meridian shall be specified by a plus
     sign (+), or by the absence of a minus sign (-), preceding the
     designating degrees.  Longitudes west of the prime meridian MUST be
     designated by a minus sign (-) preceding the digits designating
     degrees.  Longitudes on the prime meridian  MUST be designated by a
     longitude value of 0.  A point on the 180th meridian shall be taken
     as 180 degrees West, and shall include a minus sign.

     Any spatial address with a latitude of +90 (90) or -90 degrees will
     specify a position at the True North or True South Poles,
     respectively.  The component for longitude may have any legal value.



     The vertical coordinate (Elevation)  must be expressed in meters
     above WGS-84 (EGM96) datum.  Points having zero elevation must not
     have a negative sign.


  5.1 Interpretation

     User agents should accept metadata written according to the HTML or
     XHTML specifications [HTML][XHTML].

     Whitespace within a position value shall be ignored.

     An interpreting agent shall internally mark position values either
     valid or invalid.  If a position is marked invalid, it shall not be
     used to index or qualify the containing document.

     A position having a Latitude greater than 90 degrees, or less than
     -90 degrees, shall be marked invalid.




  Daviel,Kaegi                                                    [Page 5]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     A position having a Longitude greater than 180 degrees, or less than
     -180 degrees, shall be marked invalid.

     Where a value is given for geo.country, and the latitude and
     longitude values given for geo.position fall outside the recognized
     boundaries of this region, the position may be marked invalid.  For
     example, if a country code of "US" is given for a location in the US
     mainland, the position may be marked invalid if the Latitude is
     negative or the Longitude is positive.

     No formal reliance shall be placed on the precision implicit in
     position data.  It is likely that few content providers are qualified
     to determine reliable precision or accuracy data, and may use
     position data from other sources which does not give the datum.

  5.2. Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].


  6. Formal Syntax

     DIGIT = %x30-39   ; 0-9
     PLUS = %x2B       ; +
     MINUS = %x2D      ; -
     DECIMAL = %x2E    ; .
     SEMI = %x3B       ; ;
     CRLF = %x0D.%x0A  ; return, linefeed
     SP = %x20         ; space
     HTAB = %x09       ; tab
     WSP = SP / HTAB   ;
     LWSP = (WSP / CRLF WSP)  ; linear whitespace
     UCASE = %x41-5A   ; A-Z
     HYPHEN = %x2D     ; -
     USCORE = %x5F     ; _
     country = 2UCASE  ; 2-letter code from ISO3166
     TEXT = <any OCTET except CTLs, but including LWSP>
     placename = 1*TEXT
     delimiter =  SEMI

     latitude =   [ MINUS / PLUS ] 0*2DIGIT [ DECIMAL *DIGIT]
     longitude =  [ MINUS / PLUS ] 0*3DIGIT [ DECIMAL *DIGIT]
     elevation =  [ MINUS / PLUS ] 0*DIGIT [ DECIMAL *DIGIT]
     position = latitude <delimiter> longitude [ <delimiter> elevation ]

     geocivic = TEXT  ; civic address elements as per RFC 4776



  Daviel,Kaegi                                                    [Page 6]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     XHTML or WML syntax:
     <meta name="geo.position" content="<position>" />
     <meta name="geo.country" content="<country>" />
     <meta name="geo.<civic>" content="<TEXT>" />

     HTML (legacy) syntax:
     <meta name="geo.position" content="<position>">
     <meta name="geo.country" content="<country>">
     <meta name="geo.<civic>" content="<TEXT>">



  7.  Applicability

     As stated in the introduction, certain HTML documents may be
     associated with a geographic position, while other documents are not.
     For proper use of the GEO tags as described in this draft, the
     resource described in an HTML document should be associated with a
     particular geographic location for the lifetime of the document.  The
     tags may thus be properly used to describe an object fixed on the
     surface of the earth (or more properly, fixed in position relative to
     the surface of the earth) such as a retail store, a mountain peak or
     a railway station.  They may not be used to describe a non-localized,
     moving, or intangible object such as a multinational company, river,
     aircraft or mathematical theory.

     The geographic position given is associated with the resource
     described by the HTML document, not with the physical location of the
     document [RFC1876], or the location of the company responsible for
     publishing or hosting the document.  Thus, in some cases the country
     code used in "geo.country" may differ from the country code forming
     part of the host address in the document URL.

     Since the position given is associated with the content of the
     document, not the author, publishing and document conversion tools
     should not cache position data or store it in a template.

     In cases where the object being described is an area, such as a lake
     or a building, the position of the object should not in general be
     given to greater precision than the width of the object.  If desired,
     features within the object may be described in another page and their
     position given with greater precision.  In the case of an object such
     as a place of business, where only one page exists, the position of
     the entrance may be given rather than the position of the centroid.


  8.  Security Considerations




  Daviel,Kaegi                                                    [Page 7]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     The intended use of GEO metadata as described in this draft raises no
     privacy issues beyond those associated with normal use of the Web.
     It is assumed that information present in public Web pages has been
     published in accordance with applicable privacy regulations and
     guidelines.

     If the location data describes the position of a mobile Internet
     device, filters applicable to possible end recipients (typically, the
     public Internet) should be applied. The webserver in this case acts
     as a Location Recipient [RFC3693].


  9.  Internationalization considerations

     HTML meta element content, including geo elements, is coded using the
     character set of the containing document, typically UTF-8 or
     ISO8859-1.

     Geo.country and geo.position tag content should contain only ASCII
     characters.

  10.1  Normative References

     [HTML]  Raggett, Le Hors, Jacobs, "HTML 4.01 Specification",
          http://www.w3.org/TR/1999/REC-html401-19991224, W3C, December
     1999

     [XHTML] W3C HTML Working Group,  "XHTML 1.0 The Extensible HyperText
     Markup Language (Second Edition)",
       http://www.w3.org/TR/2002/REC-xhtml1-20020801, W3C,
       26 January 2000, revised 1 August 2002

     [ISO3166]  International Organization For Standardization /
     Organisation
          Internationale De Normalisation (ISO), "Standard ISO
          3166-1:1997: Codes for the Representation of Names of
          Countries and their subdivisions -- Part 1: Country codes",
          1997.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

  10.2 Informative References

     [RFC3693] Cuellar, Morris et al., "Geopriv Requirements", RFC 3693,
          February 2004
          http://www.ietf.org/rfc/rfc3693.txt




  Daviel,Kaegi                                                    [Page 8]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     [RFC1876]  Davis et al., "A Means for Expressing Location Information
     in
          the Domain Name System", RFC 1876, January 1996
          http://www.ietf.org/rfc/rfc1876.txt

     [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol
     (DHCPv4 and DHCPv6) Option
          for Civic Addresses Configuration Information", RFC 4776,
     November 2006
          http://www.ietf.org/rfc4776.txt

     [ISO3166-2] International Organization For Standardization /
     Organisation
          Internationale De Normalisation (ISO), "Standard ISO
          3166-2:1998: Codes for the Representation of Names of Countries
          and their subdivisions -- Part 2: Country subdivision code",
     1998.

     [GPS]  ARINC Research Corporation, "Navstar GPS Space Segment /
          Navigation User Interfaces", IRN-200C-002, September 1997

     [WGS84]  United States Department of Defense; DoD WGS-1984 - Its
          Definition and Relationships with Local Geodetic Systems;
          Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
          138-R; CV, KV;

     [ICAL]  Dawson & Stenerson, Internet Calendaring and Scheduling Core
          Object Specification (iCalendar), RFC 2445, November 1998
          http://www.ietf.org/rfc/rfc2445.txt

     [VCARD]  Dawson & Howes, vCard MIME Directory Profile, RFC 2426,
          September 1998
          http://www.ietf.org/rfc/rfc2426.txt

     [STATES]  United States Postal Service, Official Abbreviations -
          States and Possessions,
          http://www.usps.gov/ncsc/lookups/abbr_state.txt

     [PROVINCES]  Canada Postal Guide, Province and Territory Symbols
          http://www.canadapost.ca/tools/pg/manual/b03-e.asp

  11. Acknowledgments Rohan Mahy and Patrik Faltstrom of Cisco Systems,
     for semantics.

  12.  Authors' Addresses

     Andrew Daviel, BSc.
     Vancouver Webpages, Box 357



  Daviel,Kaegi                                                    [Page 9]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


     185-9040 Blundell Rd
     Richmond BC
     V6Y 1K3
     Canada

     Tel. (604)-377-4796
     Fax. (604)-270-8285
     advax@triumf.ca

     Felix A. Kaegi
     Dipl.Informatik Ing. ETH (M.Sc.)
     Friedensgasse 51
     CH-4056 Basel
     SWITZERLAND

     Phone +41 61 383 10 01
     Fax   +41 79 625 27 41
     skype felix_kaegi
     felix.kaegi@gmail.com
































  Daviel,Kaegi                                                   [Page 10]


  <draft-daviel-html-geo-tag-08.txt>           Oct 2007 (Expires May 2008)


  Intellectual Property Statement
     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed to
     pertain to the implementation or use of the technology described in
     this document or the extent to which any license under such rights
     might or might not be available; nor does it represent that it has
     made any independent effort to identify any such rights.  Information
     on the procedures with respect to rights in RFC documents can be
     found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use of
     such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR repository at
     http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard.  Please address the information to the IETF at ietf-
     ipr@ietf.org.

  Disclaimer of Validity
     This document and the information contained herein are provided on an
     "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
     OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
     OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  Copyright Statement
     Copyright (C) The IETF Trust (2007).

     This document is subject to the rights, licenses and restrictions
     contained in BCP 78, and except as set forth therein, the authors
     retain all their rights.

  Acknowledgment
     Funding for the RFC Editor function is currently provided by the
     Internet Society.

  15a.  IANA Considerations

     This document does not introduce any IANA considerations.





  Daviel,Kaegi                                                   [Page 11]



name: draft-moonesamy-rfc2369bis
rev: 04
time: 2024-12-18T18:43:57Z
group_uri: /api/v1/group/group/934/
expires: 2012-08-22T23:22:42Z
ad: /api/v1/person/person/18321/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578539+00:00
source: ietf
title:
  The Use of URIs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields

abstract:
  The mailing list command specification and identification header
     fields are a set of structured fields to be added to email messages
     sent by email distribution lists.  Command header fields typically
     contain URIs (usually including "mailto") locating the relevant
     information or performing the command directly.  The three core
     command header fields described in this document are List-Help, List-
     Subscribe, and List-Unsubscribe.

     There are three other header fields described here which, although
     not as widely applicable, will have utility for a sufficient number
     of mailing lists to justify their formalization here.  These are
     List-Post, List-Owner and List-Archive.

     By including these header fields, mailing list managers can make it
     possible for mail user agents to provide automated tools for users to
     perform list functions.

full_text:
  Individual Submission                                  S. Moonesamy, Ed.
  Internet-Draft                                                G. Neufeld
  Obsoletes: 2369 (if approved)                                    J. Baer
  Intended status: Standards Track                       February 20, 2012
  Expires: August 23, 2012


    The Use of URIs as Meta-Syntax for Core Mail List Commands and their
                  Transport through Message Header Fields
                       draft-moonesamy-rfc2369bis-04

  Abstract

     The mailing list command specification and identification header
     fields are a set of structured fields to be added to email messages
     sent by email distribution lists.  Command header fields typically
     contain URIs (usually including "mailto") locating the relevant
     information or performing the command directly.  The three core
     command header fields described in this document are List-Help, List-
     Subscribe, and List-Unsubscribe.

     There are three other header fields described here which, although
     not as widely applicable, will have utility for a sufficient number
     of mailing lists to justify their formalization here.  These are
     List-Post, List-Owner and List-Archive.

     By including these header fields, mailing list managers can make it
     possible for mail user agents to provide automated tools for users to
     perform list functions.

  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 http://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 August 23, 2012.

  Copyright Notice



  Moonesamy, et al.        Expires August 23, 2012                [Page 1]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Note . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.  The Command Syntax . . . . . . . . . . . . . . . . . . . . . .  4
     3.  The List Header Fields . . . . . . . . . . . . . . . . . . . .  5
       3.1.  List-Help  . . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.  List-Unsubscribe . . . . . . . . . . . . . . . . . . . . .  6
       3.3.  List-Subscribe . . . . . . . . . . . . . . . . . . . . . .  7
       3.4.  List-Post  . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.5.  List-Owner . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.6.  List-Archive . . . . . . . . . . . . . . . . . . . . . . .  9
     4.  Supporting Nested Lists  . . . . . . . . . . . . . . . . . . . 10
     5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
     8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
       8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
     Appendix A.  Implementation  . . . . . . . . . . . . . . . . . . . 12
     Appendix B.  Changes from RFC 2369 . . . . . . . . . . . . . . . . 12
     Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 12
       C.1.  Changes between between version -03 and version -04  . . . 12
       C.2.  Changes between between version -02 and version -03  . . . 13
       C.3.  Changes between between version -01 and version -02  . . . 13
       C.4.  Changes between between version -00 and version -01  . . . 13
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13








  Moonesamy, et al.        Expires August 23, 2012                [Page 2]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


  1.  Introduction

     RFC 2369 [RFC2369] defined additional header fields to be added to
     email messages sent by mailing list managers (MLMs).  The significant
     change in this document is the use of Uniform Resource Identifier
     (URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing
     an implementation to parse the common components of a URI reference
     without knowing the scheme-specific requirements of every possible
     identifier.  The content of each new header field is typically a URI
     - usually "mailto" [RFC6068] - which identifies the relevant
     information or performs the command directly.

     These headers fields are optional.  Significant functionality and
     convenience can be gained by including them.  The List-Help header
     field provides an access point to detailed user support information,
     and accommodates almost all existing mailing list managers command
     sets.  The List-Subscribe and List-Unsubscribe header fields provide
     access to two functions commonly requested by mailing list
     subscribers.

     The description of command syntax provided by the header fields can
     be used by mail user agents (MUAs) to provide simplified and
     consistent user access to mailing list functions.  The intent is to
     simplify the user experience, providing a common interface to the
     often cryptic and varied mailing list manager commands.

     Consideration has been given to avoiding the creation of too many
     header fields, while at the same time avoiding the overloading of
     individual header fields and keeping the syntax clear and simple.

     The use of these header fields does not remove the requirement to
     support the -Request command address for mailing lists [RFC2142].

     This document obsoletes RFC 2369 [RFC2369].

  1.1.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  1.2.  Syntax Notation

     This specification uses the Augmented Backus-Naur Form (ABNF)
     [RFC5234] notation for the formal definitions of the syntax of list
     header fields.





  Moonesamy, et al.        Expires August 23, 2012                [Page 3]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


  1.3.  Note

     This Internet-Draft can be discussed on the apps-discuss@ietf.org
     mailing list.  [RFC-Editor: please remove this paragraph]


  2.  The Command Syntax

     The list header fields are subject to the encoding and character
     restrictions for mail headers fields as described in [RFC5322].

     The contents of the list header fields mostly consist of angle-
     bracket ('<', '>') enclosed URIs [RFC3986], with internal whitespace
     being ignored. mailing list managers MUST NOT insert whitespace
     within the brackets.  Client applications SHOULD treat any
     whitespace, that might be inserted by poorly behaved mailing list
     managers, as characters to ignore.

     A list of multiple, alternate, URIs MAY be specified by a comma-
     separated list of angle-bracket enclosed URIs.  The URIs have order
     of preference from left to right.  The client application should use
     the left most scheme that it supports, or knows how to access by a
     separate application.  With this mechanism, schemes like http may be
     specified while still providing the basic "mailto" support for those
     clients who do not have access to non-mail scheme.  The client should
     only use one of the available URIs for a command, using another only
     if the first one used failed.

     The use of URIs allows for the use of the syntax with existing URI
     supporting applications.  As the standard for URIs is extended, the
     list header fields will gain the benefit of those extensions.
     Additionally, the use of URIs provides access to multiple schemes
     (such as ftp and http) although it is expected that the "mailto"
     scheme [RFC6068] will be the focus of most use of the list header
     fields.  Use of the schemes should be considered in light of those
     users who do not have access to the specified mechanism.

     Command syntaxes requiring variable fields to be set by the client
     (such as including the user's email address within a command) are not
     supported by this implementation.  However, mailing list managers
     using such syntaxes should still take advantage of the List-Help
     field to provide the user with detailed instructions as needed or -
     perhaps more usefully - provide access to some form of structured
     command interface such as an HTML-based form.

     The additional complications of supporting variable fields within the
     command syntax was determined to be too difficult to support by this
     protocol and would compromise the likelihood of implementation by



  Moonesamy, et al.        Expires August 23, 2012                [Page 4]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


     software authors.

     To allow for future extension, it is recommended that client
     applications follow the guidelines below for handling the contents of
     the header fields described in this document:

     1.  Except where noted for specific header fields, if the content of
         the header field (following any leading whitespace, including
         comments) begins with any character other than the opening angle
         bracket '<', the header field SHOULD be ignored.

     2.  Any characters following an angle bracket enclosed URI SHOULD be
         ignored, unless a comma is the first non-whitespace/comment
         character after the closing angle bracket.

     3.  If a sub-item (comma-separated item) within the field is not an
         angle-bracket enclosed URI, the remainder of the field (the
         current, and all subsequent, sub-items) SHOULD be ignored.


  3.  The List Header Fields

     This document presents header fields which will provide the command
     syntax description for the 'core' and key secondary functions of most
     mailing list managers.  The header fields implemented on a given
     mailing list SHOULD be included on all messages distributed by the
     list (including command responses to individual users), and on other
     messages where the message clearly applies to one distinct mailing
     list.  There MUST be no more than one of each header field present in
     any given message.

     These header fields MUST only be generated by mailing list managers,
     not by MUAs.

  3.1.  List-Help

     The List-Help header field can direct the user to complete
     instructions for all other commands.  Typically, the URI specified
     would request the help file, perhaps incorporating an HTML form for
     list commands, for the list, and alternatively provide access to an
     instructive website.

     Syntax:

        uri-list = "<" URI ">" *("," [ FWS ] "<" URI ">")

        ; whereas <URI> is defined in RFC 3986 and <FWS> and




  Moonesamy, et al.        Expires August 23, 2012                [Page 5]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


        ; <CFWS> in RFC 5322

        ; CRLF is the carriage return/line feed pair

        list-help = "List-Help:" [ CFWS ] uri-list [ CFWS ] CRLF

     Examples:



        List-Help:  <mailto:list-request@example.com?subject=help> (List
           Instructions)



        List-Help:  <mailto:list-request@example.com?body=info>



        List-Help:  <mailto:list-info@example.com> (Info about the list)



        List-Help:  <http://www.example.com/list/>,
           <mailto:list-info@example.com>



        List-Help:  <ftp://ftp.example.com/list.txt> (FTP),
           <mailto:list-request@example.com?subject=help>

  3.2.  List-Unsubscribe

     The List-Unsubscribe header field describes the command to directly
     unsubscribe the user (removing them from the list).

     Syntax:

        list-unsubscribe = "List-Unsubscribe:" uri-list [ CFWS ] CRLF

     Examples:



        List-Unsubscribe:
           <mailto:list-request@example.com?subject=unsubscribe>





  Moonesamy, et al.        Expires August 23, 2012                [Page 6]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012




        List-Unsubscribe:  (Use this command to get off the list)
           <mailto:list-request@example.com?body=unsubscribe%20list>



        List-Unsubscribe:  <mailto:list-remove@example.com>



        List-Unsubscribe:
           <http://www.example.com/list.cgi?cmd=unsub&lst=list>,
           <mailto:list-request@example.com?subject=unsubscribe>

  3.3.  List-Subscribe

     The List-Subscribe header field describes the command to directly
     subscribe the user (request addition to the list).

     Syntax:

        list-subscribe = "List-Subscribe:" uri-list [ CFWS ] CRLF

     Examples:



        List-Subscribe:
           <mailto:list-request@example.com?subject=subscribe>



        List-Subscribe:  (Use this command to join the list)
           <mailto:list-request@example.com?body=subscribe%20list>



        List-Subscribe:  <mailto:list-add@example.com>



        List-Subscribe:
           <http://www.example.com/list.cgi?cmd=sub&lst=list>,
           <mailto:list-request@example.com?body=subscribe%20list>






  Moonesamy, et al.        Expires August 23, 2012                [Page 7]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


  3.4.  List-Post

     The List-Post header field describes the method for posting to the
     mailing list.  This is typically the email address of the mailing
     list.  It can also be the email address of a moderator, or
     potentially some other form of submission.  For the special case of a
     mailing list that does not allow posting (e.g., an announcements
     list), the List-Post field may contain the special value "NO".

     Syntax:

        list-post = "List-Post:" uri-list/"NO" [ CFWS ] CRLF

     Examples:



        List-Post:  <mailto:list@example.com>



        List-Post:  <mailto:list-moderator@example.com> (Postings are
           Moderated)



        List-Post:
           <mailto:list-moderator@example.com?subject=list%20posting>



        List-Post:  NO (posting not allowed on this list)

  3.5.  List-Owner

     The List-Owner header field identifies the path to contact a human
     administrator for the mailing list.  The URI may contain the email
     address of an administrator for the mailing list, the mail system
     administrator, or any other person who can handle user contact for
     the mailing list.

     Syntax:

        list-owner = "List-Owner:" uri-list [ CFWS ] CRLF

     Examples:





  Moonesamy, et al.        Expires August 23, 2012                [Page 8]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012




        List-Owner:  <mailto:list-admin@example.com> (Contact Person for
           Help)



        List-Owner:  <mailto:grant@example.com> (Grant Neufeld)



        List-Owner:  <mailto:josh@example.com?Subject=list>

  3.6.  List-Archive

     The List-Archive header field describes how to access archives for
     the mailing list.

     Syntax:

        list-archive = "List-Archive:" uri-list [ CFWS ] CRLF

     Examples:



        List-Archive:
           <mailto:list-request@example.com?subject=index%20list>



        List-Archive:  <ftp://ftp.example.com/pub/list/archive/>



        List-Archive:  <http://www.example.com/list/archive/> (Web
           Archive)



        List-Archive:  <imap://archive.example.com/list>

     The Archive-At header field [RFC5064] provides a pointer to an
     archived form of a single message.







  Moonesamy, et al.        Expires August 23, 2012                [Page 9]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


  4.  Supporting Nested Lists

     A mailing list that is a sublist for another mailing list in a nested
     mailing list hierarchy will need to modify some of the List- header
     fields, while leaving others as the parent list set them.

     Sublists SHOULD remove the parent list's List-Help, List-Subscribe,
     List-Unsubscribe and List-Owner header fields, and SHOULD insert
     their own versions of those header fields.

     If the sublist provides its own archive, it SHOULD replace the List-
     Archive header field with its own.  Otherwise, it MUST leave the
     List-Archive header field untouched.

     Dependant on how postings to the mailing list are handled, the
     sublist MAY replace the List-Post field.  The appropriateness of
     whether to replace List-Post is left to the determination of the
     individual list administrators.  If the intention is that postings
     should be distributed to all members of the primary mailing list,
     List-Post should not be changed by a sublist in such a way that
     postings will be distributed only to members of the sublist.


  5.  Security Considerations

     There are very few new security concerns generated with this
     proposal.  Message headers fields are an existing standard, designed
     to easily accommodate new types.  There may be concern with multiple
     header fields being inserted or headers fields being forged, but
     these are problems inherent in Internet mail, not specific to this
     specification.

     Mailing list managers should not allow any user-originated list
     header fields to pass through to the mailing lists, lest they confuse
     the user and have the potential to create security problems.

     On the client side, there may be some concern with posts or commands
     being sent in error.  It is required that the user have a chance to
     confirm any action before it is executed.  In the case of "mailto",
     it may be appropriate to create the correctly formatted message
     without sending it, allowing the user to see exactly what is
     happening and giving the user the opportunity to approve or discard
     the message before it is sent.

     All security considerations for the use of URIs [RFC3986] apply
     equally to this specification.  Mail User Agents should not process
     list header field URIs which could compromise the security of the
     user's system.  This includes the "file://" URI type which could



  Moonesamy, et al.        Expires August 23, 2012               [Page 10]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


     potentially be used to trigger the execution of a local application
     on some user systems.


  6.  IANA Considerations

     The List-Archive, List-Help, List-Owner, List-Post, List-Subscribe,
     and List-Unsubscribe references in the Permanent Message Header Field
     Names registry should be updated to point to this document.


  7.  Acknowledgements

     The numerous participants of the List-Header, ListMom-Talk, List-
     Managers and MIDA-Mail mailing lists contributed much to the
     formation and structure of RFC 2369 with Keith Moore and Christopher
     Allen providing guidance on the standards process.

     We would like to thank the the following people for their
     contributions: Mykyta Yevstifeye, Murray S. Kucherawy and John
     Levine.


  8.  References

  8.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, January 2005.

     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                October 2008.

     [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
                URI Scheme", RFC 6068, October 2010.

  8.2.  Informative References

     [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
                FUNCTIONS", RFC 2142, May 1997.




  Moonesamy, et al.        Expires August 23, 2012               [Page 11]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


     [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
                for Core Mail List Commands and their Transport through
                Message Header Fields", RFC 2369, July 1998.

     [RFC5064]  Duerst, M., "The Archived-At Message Header Field",
                RFC 5064, December 2007.


  Appendix A.  Implementation

     RFC 2369 contains a discussion about the design decisions for List-
     header fields.


  Appendix B.  Changes from RFC 2369

     This appendix contains a list of changes between this document and
     RFC 2369.

     o  URL changed to URI

     o  Replaced MTAs with mailing list managers in the sentence: "MTAs
        generating the header fields SHOULD".

     o  Replaced MTAs with mailing list managers in the sentence: "MTAs
        MUST NOT insert whitespace within the brackets" in Section 2

     o  In Section 2, client application SHOULD ignore whitespace within
        brackets

     o  Updated references

     o  Added informative reference to RFC 5064

     o  Editorial changes

     o  Removed Background Discussion


  Appendix C.  Change Log

     [RFC-Editor: please remove this section]

  C.1.  Changes between between version -03 and version -04

     o  Removed sections about List-ID and List-Sequence as they are not
        URIs




  Moonesamy, et al.        Expires August 23, 2012               [Page 12]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


  C.2.  Changes between between version -02 and version -03

     o  Added Grant Neufeld as co-author

     o  Added Joshua Baer as co-author

     o  Move List-Sequence header field definition to I-D.moonesamy-
        rfc2919bis

  C.3.  Changes between between version -01 and version -02

     o  Added ABNF and reference to RFC 5234

     o  Removed text about postmaster in List-Owner Section

     o  Removed User Interface guidelines from Appendix B

     o  Removed SHOULD include a "mailto" based command in Section 3

     o  Modified the text to first paragraph of Section 3.1

  C.4.  Changes between between version -00 and version -01

     o  Added List-Sequence header field

     o  Added informative reference to I-D.moonesamy-rfc2919bis


  Authors' Addresses

     S. Moonesamy (editor)
     76, Ylang Ylang Avenue
     Quatre Bornes
     Mauritius

     Email: sm+ietf@elandsys.com


     Grant Neufeld
     Calgary, Alberta
     Canada

     Email: grant@grantneufeld.ca








  Moonesamy, et al.        Expires August 23, 2012               [Page 13]


  Internet-Draft     URIs for Core Mailing List Commands     February 2012


     Joshua Baer
     Austin, Texas
     USA

     Email: ietf@joshuabaer.com
     URI:   http://joshuabaer.com/













































  Moonesamy, et al.        Expires August 23, 2012               [Page 14]



name: draft-moonesamy-rfc2919bis
rev: 04
title: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
time: 2024-12-18T18:43:57Z
group_uri: /api/v1/group/group/934/
expires: 2012-08-22T23:23:14Z
ad: /api/v1/person/person/18321/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578544+00:00
source: ietf
abstract:
  Software that handles electronic mailing list messages (servers and
     user agents) needs a way to reliably identify messages that belong to
     a particular mailing list.  With the advent of list header fields, it
     has become even more important to provide a unique identifier for a
     mailing list regardless of the particular host that runs the mailing
     list manager at any given time.

     The List-Id header field provides a standard location for such an
     identifier.  In addition, a namespace for mailing list identifiers
     based on fully qualified domain names is described.  This namespace
     is intended to guarantee uniqueness for list owners who require it,
     while allowing for a less rigorous namespace for experimental and
     personal use.

     By including the List-Id field, mailing list managers can make it
     easier for mail user agents to provide automated tools for users to
     perform mailing list functions.  The mailing list identifier can
     serve as a key for automated processing tasks

full_text:
  Individual Submission                                  S. Moonesamy, Ed.
  Internet-Draft
  Obsoletes: 2919 (if approved)                                R. Chandhok
  Intended status: Standards Track                               G. Wenger
  Expires: August 23, 2012                                  QUALCOMM, Inc.
                                                         February 20, 2012


    List-Id: A Structured Field and Namespace for the Identification of
                               Mailing Lists
                       draft-moonesamy-rfc2919bis-04

  Abstract

     Software that handles electronic mailing list messages (servers and
     user agents) needs a way to reliably identify messages that belong to
     a particular mailing list.  With the advent of list header fields, it
     has become even more important to provide a unique identifier for a
     mailing list regardless of the particular host that runs the mailing
     list manager at any given time.

     The List-Id header field provides a standard location for such an
     identifier.  In addition, a namespace for mailing list identifiers
     based on fully qualified domain names is described.  This namespace
     is intended to guarantee uniqueness for list owners who require it,
     while allowing for a less rigorous namespace for experimental and
     personal use.

     By including the List-Id field, mailing list managers can make it
     easier for mail user agents to provide automated tools for users to
     perform mailing list functions.  The mailing list identifier can
     serve as a key for automated processing tasks

  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 http://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."




  Moonesamy, et al.        Expires August 23, 2012                [Page 1]


  Internet-Draft                   List-Id                   February 2012


     This Internet-Draft will expire on August 23, 2012.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.



































  Moonesamy, et al.        Expires August 23, 2012                [Page 2]


  Internet-Draft                   List-Id                   February 2012


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
       1.3.  Note . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.  List Identifier Syntax . . . . . . . . . . . . . . . . . . . .  5
     3.  List-Id Header Field . . . . . . . . . . . . . . . . . . . . .  6
     4.  Persistence of List Identifiers  . . . . . . . . . . . . . . .  7
     5.  Uniqueness of List Identifiers . . . . . . . . . . . . . . . .  7
     6.  Operations on List Identifier  . . . . . . . . . . . . . . . .  8
     7.  Supporting Nested Lists  . . . . . . . . . . . . . . . . . . .  8
     8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
     11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
       11.2. Informative References . . . . . . . . . . . . . . . . . . 10
     Appendix A.  Subject Tags  . . . . . . . . . . . . . . . . . . . . 10
     Appendix B.  Changes from RFC 2919 . . . . . . . . . . . . . . . . 10
     Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 11
       C.1.  Changes between between version -03 and version -04  . . . 11
       C.2.  Changes between between version -02 and version -03  . . . 11
       C.3.  Changes between between version -01 and version -02  . . . 11
       C.4.  Changes between between version -00 and version -01  . . . 11
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

























  Moonesamy, et al.        Expires August 23, 2012                [Page 3]


  Internet-Draft                   List-Id                   February 2012


  1.  Introduction

     Internet mailing lists have evolved into fairly sophisticated forums
     for group communication and collaboration. draft-moonesamy-rfc2369bis
     [ID.moonesamy-rfc2369bis] expands the functionality that the Mail
     User Agent (MUA) can provide by providing more information in each
     message sent by the mailing list manager (MLM).

     Implementing such functionality in the MUA depends on the ability to
     accurately identify messages as belonging to a particular mailing
     list.  The problem then becomes what attribute or property to use to
     identify a mailing list.  The most likely candidate is the submission
     address of the mailing list itself.  Unfortunately, when the server
     where the mailing list manager is hosted or the submission policy of
     the list changes the submission address itself can change.  This
     affects automated processing and filtering of messages from mailing
     lists.

     In order to further automate (and make more accurate) the processing
     a software agent can do, RFC 2919 [RFC2919] specified how to generate
     a unique identifier for a mailing list.  This identifier can be
     simply used for string matching in a filter, or it can be used in
     more sophisticated systems to uniquely identify messages as belonging
     to a particular mailing list independent of the particular host
     delivering the actual messages.  This identifier can also act as a
     key into a database of mailing lists.

     This document obsoletes RFC 2919 [RFC2919].

  1.1.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  1.2.  Syntax Notation

     This specification uses the Augmented Backus-Naur Form (ABNF)
     [RFC5234] notation for the formal definitions of the syntax of list
     header fields.

  1.3.  Note

     This Internet-Draft can be discussed on the apps-discuss@ietf.org
     mailing list.  [RFC-Editor: please remove this paragraph]






  Moonesamy, et al.        Expires August 23, 2012                [Page 4]


  Internet-Draft                   List-Id                   February 2012


  2.  List Identifier Syntax

     The List Identifier will, in most cases, appear like a host name in a
     domain of the list owner.  Using the domain name space as a basis for
     the List Identifier namespace, it is intended to leverage an existing
     name space structure to generate a unique identifier.  It also allows
     for the List Identifier to be kept separate from any particular
     delivery host or mechanism.

     While it is perfectly acceptable for a List Identifier to be
     completely independent of the domain name of the host machine
     servicing the mailing list, the owner of a mailing list MUST NOT
     generate List Identifiers in any domain name space for which they do
     not have authority.  For example, a mailing list hosting service may
     choose to assign List Identifiers in their own domain-based name
     space, or they may allow their clients (the list owners) to provide
     List Identifiers in a namespace for which the owner has authority.

     If the owner of the mailing list does not have the authority to
     create a List Identifier in a domain-based name space, they may
     create unmanaged List Identifiers in the special unmanaged domain
     "invalid".

     Syntax:

        list-id = list-label "." list-id-namespace

        list-label = dot-atom-text

        list-id-namespace = domain-name / unmanaged-list-id-namespace

        unmanaged-list-id-namespace = "invalid"

        domain-name = dot-atom-text

     Where:

        dot-atom-text is defined in [RFC5322]

        "invalid" is a reserved domain name defined in [RFC2606]

     In addition, a List Identifier (list-id) MUST NOT be longer than 255
     octets in length, for future compatibility.  It should be noted that
     "invalid" is not valid for the domain-name rule.







  Moonesamy, et al.        Expires August 23, 2012                [Page 5]


  Internet-Draft                   List-Id                   February 2012


  3.  List-Id Header Field

     This document specifies a List-Id header field which will provide an
     identifier for a mailing list.  This header field should be included
     on all messages distributed by the mailing list manager (including
     command responses to individual users), and on other messages where
     the message clearly applies to this particular distinct mailing list.
     There MUST be not be more than one of List-Id header field in any
     given message.

     This field MUST only be generated by mailing list managers, not MUAs.

     The contents of the List-Id header field mostly consist of angle-
     bracket ('<', '>') enclosed identifier, with internal whitespace
     being ignored.  Mailing List Managers MUST NOT insert whitespace
     within the brackets.  Client applications SHOULD treat any such
     whitespace, that might be inserted by poorly behaved mailing list
     managers, as characters to ignore.

     The List-Id header field is subject to the encoding and character
     restrictions for mail headers as described in [RFC5322].

     The List-Id header field MAY optionally include a description by
     including it as a "phrase" [RFC5322] before the angle-bracketed List
     Identifier.  The MUA MAY choose to use this description in its user
     interface; however, any MUA that intends to make use of the
     description should be prepared to properly parse and decode any
     encoded strings or other legal phrase components.  For many MUAs the
     parsing of the List-Id header field will simply consist of extracting
     the List Identifier from between the delimiting angle brackets.

     Syntax:

        list-id-header = "List-Id:" [phrase] "<" list-id ">" CRLF

     where phrase and CRLF are as defined in [RFC5322].  Unlike most
     headers fields in RFC 5322 [RFC5322], the List-Id header field does
     not allow free insertion of whitespace and comments around tokens.
     Any descriptive text MUST be presented in the optional phrase
     component of the header field.

     Examples:









  Moonesamy, et al.        Expires August 23, 2012                [Page 6]


  Internet-Draft                   List-Id                   February 2012


        List-Id:  List Header Mailing List <list-name.example.com>



        List-Id:  <commonspace-users.list-id.example.com>



        List-Id:  "Lena's Personal Joke List" <lenas-
           jokes.da39efc25c530ad145d41b86f7420c3b.021999.invalid>



        List-Id:  <da39efc25c530ad145d41b86f7420c3b.052000.invalid>


  4.  Persistence of List Identifiers

     Although the List Identifier may be changed by the mailing list
     administrator, this is not desirable.  (Note that there is no
     disadvantage to changing the description portion of the List-Id
     header field.)  A MUA would not recognize the change to the List
     Identifier because a MUA treats a different List Identifier as a
     different list.  As such the mailing list administrator should avoid
     changing the List Identifier even when the host serving the mailing
     list changes.  On the other hand, transitioning from an informal
     unmanaged-list-id-namespace to a domain name space is an acceptable
     reason to change the List Identifier.  Also if the focus of the
     mailing list changes sufficiently the administrator may wish to
     retire the previous mailing list and its associated identifier to
     start a new mailing list reflecting the new focus.


  5.  Uniqueness of List Identifiers

     This proposal uses a namespace that by definition can be used to
     create unique identifiers within the domain.

     There is a need for identification of mailing lists that are
     administrated by some entity without administrative access to a
     domain.  In this case, general heuristics can be given to reduce the
     chance of collision, but it cannot be guaranteed.  If a list owner
     requires a guarantee, they are free to register a domain name under
     their control.

     It is suggested, but not required, that List Identifiers be created
     under a subdomain of "list-id" within any given domain.  This can
     help to reduce internal conflicts between the administrators of the



  Moonesamy, et al.        Expires August 23, 2012                [Page 7]


  Internet-Draft                   List-Id                   February 2012


     subdomains of large organizations.  For example, List Identifiers at
     "example.com" are generated in the subdomain of "list-
     id.example.com".

     A List Identifier not ending with ".invalid" MUST be globally unique
     in reference to all other mailing lists.  List Identifiers ending
     with ".invalid" are not guaranteed to be globally unique.

     A List Identifier using the special "invalid" namespace SHOULD
     include the month and year (in the form MYYYY), i.e. the List
     Identifier is a "subdomain" of the "invalid" namespace.  In addition,
     some portion of the List Identifier MUST be a randomly generated
     string, e.g. the random [RFC4086] component contains a hex encoding
     of 128 bits of randomness (resulting in 32 hex characters) as part of
     the List Identifier.

     Thus, List Identifiers such as <lenas-
     jokes.da39efc25c530ad145d41b86f7420c3b.021999.invalid> and
     <da39efc25c530ad145d41b86f7420c3b.051998.invalid> follow these
     guidelines, while <lenas-jokes.021999.invalid> and <mylist.invalid>
     do not.


  6.  Operations on List Identifier

     There is only one operation defined for List Identifiers, that of
     case insensitive equality.

     The sole use of a List Identifier is to identify a mailing list, and
     the sole use of the List-Id header field is to mark a particular
     message as belonging to that list.  The comparison operation MUST
     ignore any part of the List-Id header field outside of the angle
     brackets, the MUA may inform the user if the descriptive name of a
     mailing list changes.


  7.  Supporting Nested Lists

     A list that is a sublist for another list in a nested mailing list
     hierarchy MUST NOT modify the List-Id header field; however, this
     will only be possible when the nested mailing list is aware of the
     relationship between it and its "parent" mailing lists.


  8.  Security Considerations

     There are very few new security concerns generated with this
     proposal.  Message headers fields are an existing standard, designed



  Moonesamy, et al.        Expires August 23, 2012                [Page 8]


  Internet-Draft                   List-Id                   February 2012


     to easily accommodate new types.  There may be concern with multiple
     header fields being inserted or headers fields being forged, but
     these are problems inherent in Internet mail, not specific to this
     specification.  If a mailing list manager encounters List-Id header
     fields from any unexpected source it SHOULD NOT pass them through to
     the mailing list.

     As mentioned above, mail list managers should not allow any user-
     originated List-Id header fields to pass through to their lists, lest
     they confuse the user and have the potential to create security
     problems.

     On the client side, a forged List Identifier may break automated
     processing.  The List Identifier (in its current form) should not be
     used as an indication of the authenticity of the message.


  9.  IANA Considerations

     The List-Id reference in the Permanent Message Header Field Names
     registry should be updated to point to this document.


  10.  Acknowledgements

     The numerous participants of the List-Header and ListMom-Talk mailing
     lists contributed much to the formation and structure of this
     document.

     Grant Neufeld focused much of the early discussion, and thus was
     essential in the creation of this document.

     Murray S. Kucherawy provided insightful comments.


  11.  References

  11.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                October 2008.




  Moonesamy, et al.        Expires August 23, 2012                [Page 9]


  Internet-Draft                   List-Id                   February 2012


  11.2.  Informative References

     [I-D.moonesamy-rfc2369bis]
                Moonesamy, S., Neufeld, G., and J. Baer, "The Use of URIs
                as Meta-Syntax for Core Mail List Commands and their
                Transport through Message Header Fields",
                draft-moonesamy-rfc2369bis-03 (work in progress),
                January 2012.

     [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
                Names", BCP 32, RFC 2606, June 1999.

     [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
                and Namespace for the Identification of Mailing Lists",
                RFC 2919, March 2001.

     [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                Requirements for Security", BCP 106, RFC 4086, June 2005.


  Appendix A.  Subject Tags

     A popular feature of some MLMs is the "tagging" of the Subject header
     field by prefixing the header field's contents with the name of the
     mailing list, e.g. "[example]" for a list called "example".  The
     difference between a List Identifier and a subject tag is that while
     a List Identifier is unique, a subject tag is usually the short form
     of a mailing list's name.  Such a namespace is inherently flat,
     unmanaged and thus non-unique.


  Appendix B.  Changes from RFC 2919

     This appendix contains a list of changes between this document and
     RFC 2919.

     o  Removed text about the domain name system and domain ownership in
        Section 2

     o  "localhost" replaced with "invalid"

     o  Replaced MTAs with mailing list managers in the sentence: "MTAs
        MUST NOT insert whitespace within the brackets" in Section 3

     o  Case independence in Section 6 changed to case insensitivity for
        ASCII





  Moonesamy, et al.        Expires August 23, 2012               [Page 10]


  Internet-Draft                   List-Id                   February 2012


     o  Added a paragraph in the appendix about subject tags

     o  Updated references

     o  Editorial changes


  Appendix C.  Change Log

     [RFC-Editor: please remove this section]

  C.1.  Changes between between version -03 and version -04

     o  Removed List-Sequence header field as it does not fit it

     o  Reverted recommended to MUST NOT in Section 2 as it is a
        requirement in RFC 2919

  C.2.  Changes between between version -02 and version -03

     o  Added Ravinder Chandhok as co-author

     o  Added Geoffrey Wenger as co-author

  C.3.  Changes between between version -01 and version -02

     o  Added List-Sequence header field

     o  Removed text about about case-insensitive string comparison

     o  Removed recommendation in Section 4 about how the MUA SHOULD treat
        a different List Identifier

  C.4.  Changes between between version -00 and version -01

     o  Added informative reference to I-D.moonesamy-rfc2369bis


  Authors' Addresses

     S. Moonesamy (editor)
     76, Ylang Ylang Avenue
     Quatre Bornes
     Mauritius

     Email: sm+ietf@elandsys.com





  Moonesamy, et al.        Expires August 23, 2012               [Page 11]


  Internet-Draft                   List-Id                   February 2012


     Ravinder Chandhok
     QUALCOMM, Inc.
     5775 Morehouse Drive
     San Diego, CA 92121
     USA

     Email: chandhok@qualcomm.com


     Geoffrey Wenger
     QUALCOMM, Inc.
     5775 Morehouse Drive
     San Diego, CA 92121
     USA

     Email: gwenger@qualcomm.com



































  Moonesamy, et al.        Expires August 23, 2012               [Page 12]



name: draft-rosenberg-ai-protocols
rev: 00
title: Framework, Use Cases and Requirements for AI Agent Protocols
time: 2025-05-05T17:53:43Z
group_uri: /api/v1/group/group/1027/
expires: 2025-11-06T17:53:43Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578581+00:00
source: ietf
abstract:
  AI Agents are software applications that utilize Large Language
     Models (LLM)s to interact with humans (or other AI Agents) for
     purposes of performing tasks.  AI Agents can make use of resources -
     including APIs and documents - to perform those tasks, and are
     capable of reasoning about which resources to use.  To facilitate AI
     agent operation, AI agents need to communicate with users, and then
     interact with other resources over the Internet, including APIs and
     other AI agents.  This document describes a framework for AI Agent
     communications on the Internet, identifying the various protocols
     that come into play.  It introduces use cases that motivate features
     and functions that need to be present in those protocols.  It also
     provides a brief survey of existing work in standardizing AI agent
     protocols, including the Model Context Protocol (MCP), the Agent to
     Agent Protocol (A2A) and the Agntcy Framework, and describes how
     those works fit into this framework.  The primary objective of this
     document is to set the stage for possible standards activity at the
     IETF in this space.

full_text:
  Network Working Group                                       J. Rosenberg
  Internet-Draft                                                     Five9
  Intended status: Informational                               C. Jennings
  Expires: 6 November 2025                                           Cisco
                                                                5 May 2025


        Framework, Use Cases and Requirements for AI Agent Protocols
                      draft-rosenberg-ai-protocols-00

  Abstract

     AI Agents are software applications that utilize Large Language
     Models (LLM)s to interact with humans (or other AI Agents) for
     purposes of performing tasks.  AI Agents can make use of resources -
     including APIs and documents - to perform those tasks, and are
     capable of reasoning about which resources to use.  To facilitate AI
     agent operation, AI agents need to communicate with users, and then
     interact with other resources over the Internet, including APIs and
     other AI agents.  This document describes a framework for AI Agent
     communications on the Internet, identifying the various protocols
     that come into play.  It introduces use cases that motivate features
     and functions that need to be present in those protocols.  It also
     provides a brief survey of existing work in standardizing AI agent
     protocols, including the Model Context Protocol (MCP), the Agent to
     Agent Protocol (A2A) and the Agntcy Framework, and describes how
     those works fit into this framework.  The primary objective of this
     document is to set the stage for possible standards activity at the
     IETF in this space.

  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 6 November 2025.





  Rosenberg & Jennings     Expires 6 November 2025                [Page 1]


  Internet-Draft                AI Protocols                      May 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  The Framework . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  AI Agent to User  . . . . . . . . . . . . . . . . . . . .   6
         2.1.1.  User Initiated  . . . . . . . . . . . . . . . . . . .   6
         2.1.2.  AI Agent Initiated  . . . . . . . . . . . . . . . . .   7
       2.2.  AI Agent to API . . . . . . . . . . . . . . . . . . . . .   7
       2.3.  AI Agent to AI Agent  . . . . . . . . . . . . . . . . . .   8
     3.  Protocol Requirements and Considerations  . . . . . . . . . .  11
       3.1.  User to AI Agent  . . . . . . . . . . . . . . . . . . . .  11
         3.1.1.  Authentication  . . . . . . . . . . . . . . . . . . .  11
       3.2.  AI Agent to API . . . . . . . . . . . . . . . . . . . . .  12
         3.2.1.  Discovery . . . . . . . . . . . . . . . . . . . . . .  12
         3.2.2.  AuthN and AuthZ on APIs . . . . . . . . . . . . . . .  12
         3.2.3.  User Confirmation . . . . . . . . . . . . . . . . . .  15
         3.2.4.  API Customization for AI Agents . . . . . . . . . . .  16
       3.3.  AI Agent to AI Agent  . . . . . . . . . . . . . . . . . .  16
         3.3.1.  Discovery . . . . . . . . . . . . . . . . . . . . . .  17
         3.3.2.  Routing and Connection  . . . . . . . . . . . . . . .  17
         3.3.3.  Lifecycle Management  . . . . . . . . . . . . . . . .  18
         3.3.4.  Data Transferrance  . . . . . . . . . . . . . . . . .  20
         3.3.5.  Authentication and Authorization  . . . . . . . . . .  22
         3.3.6.  User Confirmation . . . . . . . . . . . . . . . . . .  23
         3.3.7.  Prompt Injection Attacks  . . . . . . . . . . . . . .  23
     4.  Analysis of Existing Protocols  . . . . . . . . . . . . . . .  23
       4.1.  MCP . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       4.2.  A2A . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       4.3.  Agntcy  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  25
     6.  Informative References  . . . . . . . . . . . . . . . . . . .  26
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26





  Rosenberg & Jennings     Expires 6 November 2025                [Page 2]


  Internet-Draft                AI Protocols                      May 2025


  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
     whether to interact further with the user for more information,
     whether to invoke an API to retrieve information, or to perform an
     action that might require human confirmation (such as booking a
     flight).

     AI Agents are often built to be task specific.  In the examples
     above, each AI agent was uniquely tuned (primarily through its prompt
     structure, though perhaps also with fine-tuned models) to the
     specific task at hand.  This introduces a problem.  A user
     interacting with one agent might require the agent to do something
     which it is not tuned to do, requiring the agent to interact with a
     different agent that has the appropriate skills.  This is called
     agent federation or Agent-to-Agent communication.

     The result of this is a system which has many different software
     elements communicating over the Internet.  This introduces the
     potential need for additional areas of protocol standardization to
     facilitate deployment of these AI Agent systems.  This need has been
     broadly recognized already in the industry, resulting in a rapid
     stream of open source and protocol efforts.  Examples include the



  Rosenberg & Jennings     Expires 6 November 2025                [Page 3]


  Internet-Draft                AI Protocols                      May 2025


     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 the Agntcy
     framework, driven by Cisco (https://agntcy.org/
     (https://agntcy.org/)).  There are certainly others.  These efforts
     cover parts of the standardization spectrum, partially overlapping in
     scope in some cases.

     With the potential for significant adoption of AI Agents across the
     Internet, these protocols may become the foundation for the next wave
     of Internet communication technologies, especially between domains.
     Indeed, we can think of inter-domain protocol stack as being composed
     of IP [RFC791], UDP [RFC768], TCP [RFC9293], and QUIC [RFC9000] as
     the foundation for communicating between hosts.  The next layer -
     HTTP [RFC9114], SIP [RFC3261] and RTP [RFC3550] are the main inter-
     domain protocols at the application layer.  If AI Agents are the new
     way in which users interact with applications, then the protocols
     between them could represent the next layer of this stack.

     +-----------------+    we are now here  +-----------------+
     |     AI Agent    |<------------------->|     AI Agent    |
     +-----------------+                     +-----------------+

     +-----------------+   HTTP, SIP, RTP    +-----------------+
     |    Application  |<------------------->|    Application  |
     +-----------------+                     +-----------------+

     +-----------------+  IP, TCP, UDP, QUIC +-----------------+
     |      Host       |<------------------->|      Host       |
     +-----------------+                     +-----------------+

           Figure 1: Are AI Protocols the next layer of the modern IP
                                Protocol Stack?

     This means they must be designed with care, and deeply consider the
     necessary security, privacy, and extensibility requirements needed
     for broad adoption.  Most importantly, they must consider the needs
     of the humans who ultimately use these systems, and be designed to
     manage the harms that may be introduced through inaccuracy and
     hallucination that are an unavoidable consequence of using LLMs.

     This document provides a framework to aid in standardization efforts
     in this area.  It identifies the different protocols which come into
     play, and considers different variations in their use cases.  It
     discusses requirements for these protocols, covering functionality



  Rosenberg & Jennings     Expires 6 November 2025                [Page 4]


  Internet-Draft                AI Protocols                      May 2025


     along with considerations for privacy, security and hallucination
     management.  The document also includes a brief overview of some of
     the existing protocols and open source efforts, and maps them into
     the framework provided here.

  2.  The Framework

     The overall architecture is shown in Figure 2.

               Domain A                   Domain B
     ..............................    ................
     .                            .    .              .
     .                            .    .              .
     .                +---------+ .    . +---------+  .
     .                |         | .    . |         |  .
     .                |         | .    . |         |  .
     .                | A APIs  | .  +-.-+ B APIs  |  .
     .                |         | .  | . |         |  .
     .                |         | .  | . |         |  .
     .                +----+----+ .  | . +----+----+  .
     .                     |      .  | .      |       .
     .                     |      .  | .      |       .
     . +---------+    +----+----+ .  | . +----+----+  .
     . |         |    |         | .  | . |         |  .
     . |         |    |         +-.--+ . |         |  .
     . | User A  +----+AI Agent +-.----.-+AI Agent |  .
     . |         |    |    A    | .    . |    B    |  .
     . |         |    |         +-.-+  . |         |  .
     . +---------+    +-+--+----+ . |  . +----+----+  .
     .                  |  |      . |  .      |       .
     .      +-----------+  |      . |  .      |       .
     .      |              |      . |  .      |       .
     . +----+----+    +----+----+ . |  . +----+----+  .
     . |         |    |         | . |  . |         |  .
     . |         |    |         | . |  . |         |  .
     . | User S  |    | AI Agent| . +--.-+  User B |  .
     . |         |    |    Z    | .    . |         |  .
     . |         |    |         | .    . |         |  .
     . +---------+    +---------+ .    . +---------+  .
     .                            .    .              .
     .                            .    .              .
     ..............................    ................

                     Figure 2: AI Agent Protocol Framework

     The framework focuses on the AI agent in domain A - "AI Agent A".
     This AI agent is providing services to a user, User A.  To do that,
     User A communicates with AI agent A over voice, chat or other



  Rosenberg & Jennings     Expires 6 November 2025                [Page 5]


  Internet-Draft                AI Protocols                      May 2025


     channels.  AI Agent A supports this user by invoking APIs - either in
     its own domain, or in another.  AI Agent A might also communicate
     with other users - ones in domain A, or outside of it.  Consequently,
     there are broadly speaking three classes of protocols in play: (1)
     Protocols for human to AI Agent, (2) Protocols for AI agents to
     invoke APIs, and (3) Protocols for AI agents to talk to each other.

  2.1.  AI Agent to User

     We refer to this protocol as the "User to Agent Communications
     Protocol".  These communications can be initiated by the user, or
     initiated by the agent.

  2.1.1.  User Initiated

     The process generally starts when the user initiates communications
     with its AI Agent.

     User A communicates to AI agent 1 over some kind of communications
     technology.  It could be a via a phone call, or via voice chat via a
     widget on a web page or inside a mobile or desktop app.  It could be
     via chat, using a chat widget in a webpage, or via SMS, RCS or
     applications like WhatsApp or Facebook Messenger.  These chat apps
     provide a variety of content types, including text, images,
     carousels, links, videos, and interactive html cards.  The
     interaction could be via video as well.  Often video communications
     are one way, from the user to the AI agent, to facilitate "see what I
     see" interactions.  Or, it can be two way, in which case the user
     might see an avatar of the AI agent.

     The communications could also be multi-modal.  User A1 could be
     talking to AI Agent 1 using voice, while at the same time, receiving
     texts from the AI Agent with information or links.  User A1 could be
     using voice and video concurrently.  User A could be using a web
     widget for chat and multimedia content, while using a phone call to
     communicate with the same agent.

     In all of these cases, User A has a relationship with AI Agent 1
     (typically by being a user of the domain or site in which it
     resides).  This is why the user is shown within the domain boundary
     in the picture.

     The protocols and technologies used for this communication are well
     established today, and it is not apparent that there is any
     additional standards work required to support AI agents.  Indeed,
     users are already able to communicate with AI agents over these
     channels today.




  Rosenberg & Jennings     Expires 6 November 2025                [Page 6]


  Internet-Draft                AI Protocols                      May 2025


  2.1.2.  AI Agent Initiated

     In some cases, AI agent 1 may find that - in order to do its job - it
     needs to communicate with another human user.

     As one example, User A may be interacting with an AI agent providing
     loans.  The user might have a request for a lowered loan rate based
     on their holdings with the bank.  The AI agent could be programmed to
     always reach out to a human in order to approve reduced load rates.
     When the conversation between User A and the loan AI agent reaches
     this point, the AI agent needs to communicate with the human
     supervisor to gain this approval.  This is User S in the diagram
     above.

     In the most common use cases, the human user would be in the same
     domain as the AI agent.  This is the case for our loan example above.
     In these cases, the AI agent could use email, voice, chat or other
     communications techniques which are known to be used by User B.
     Often, User B would be a contact center agent connected to the same
     platform facilitating operation of the agent.  In other cases, they
     are on separate communications systems.  The administrators of domain
     A would be required to configure the systems to communicate with each
     other using standard protocols ala SIP or SMTP.  It may also be the
     case that the communications system user by User S exposes APIs that
     enable sending of messages, in which case the interface actually
     looks like one between an AI agent and an API.

     It could be the case that the human user is in another administrative
     domain entirely.  In this case, AI agent may only have an email
     address or phone number for the user to contact, and not have further
     information about their capabilities.  This is the case for AI Agent
     A communicating with User B.

  2.2.  AI Agent to API

     For AI Agent A to do its job, it will require access to APIs.  Those
     APIs can provide read-only information - for example a product
     catalog or list of hotel properties.  The API could take actions, for
     example an API to book a flight, create a case, or start a product
     return.  These APIs could be intra-domain or inter-domain.

     In the intra-domain case, the APIs are administered by the same
     organizational entity that is providing the agent.  For example, a
     travel booking site might run an AI agent for such bookings.  The
     site has microservices which have APIs for retrieving travel
     destinations and airports, booking flights, or creating trip records.
     In these cases, the APIs are intradomain.




  Rosenberg & Jennings     Expires 6 November 2025                [Page 7]


  Internet-Draft                AI Protocols                      May 2025


     Alternatively, the APIs could reside outside of domain A.  Once
     again, using the travel booking example, the travel booking site
     might invoke APIs offered by partner airlines to book the flights.
     In the case of inter-domain APIs, there are two sub-cases.  In one
     case, it is domain A which has the relationship with domain B, and
     the APIs are invoked using service accounts that are not specific to
     User A.  That said, they could be operating on behalf of user A and
     thus be limited or constrained based on User A's data and
     permissions.  In the second sub-case, the AI Agent is operating
     directly on behalf of User A, using a token granted to the AI agent
     by an OAuth flow performed by user A.  This could happen in cases
     where there is not necessarily a business relationship between domain
     A and domain B, but instead a relationship between user A and domain
     B.  Again using the travel booking agent as an example, User A might
     have accounts with United Airlines and Delta Airlines, both of which
     expose APIs for booking flights, obtaining flight information, and
     accessing frequent flier information.  User A could authorize AI
     Agent A to access both United and Delta on his behalf.  The AI Agent
     could then retrieve information from both, compare flight options and
     costs, and then execute flight bookings.  In this case, the AI agent
     has no advanced knowledge of the APIs offered by United or Delta, and
     needs to learn what they are and have enough information to know how
     to use them appropriately.

  2.3.  AI Agent to AI Agent

     The final piece of the framework is AI agent to AI Agent.  This is
     perhaps the most interesting of these communications protocols.  As
     with most of the other protocols, they can be intra-domain or inter-
     domain.

     For an intra-domain example, consider a bank with several lines of
     business.  They have a loan department, a wealth management
     department, a private equity investment department, and a personal
     banking department.  A particular user - perhaps a customer of the
     personal banking department - has an account with the bank.  While
     chatting with the personal banking agent, the user inquires about
     loans.  In this case, the banking agent recognizes that it does not
     have the required expertise, and connects the user with the loan AI
     agent (agent Z in the diagram above).

     In a similar use case, User A is communicating with the personal
     banking agent, and requests to close out all of their accounts and
     have a check issued to them.  The bank has employed a different AI
     agent - the "closure agent" which runs through a complex workflow
     required to close down a customer account.  This agent might invoke
     several APIs to close accounts, update databases, and send out emails
     and texts to the user.  In this case, User A doesn't actually chat



  Rosenberg & Jennings     Expires 6 November 2025                [Page 8]


  Internet-Draft                AI Protocols                      May 2025


     with the closure agent.  The closure agent instead executes a complex
     task which involves reasoning, API invocation and possible
     communications with humans.

     Both of these are intra-domain cases.  Inter-domain cases are
     similar.  If we once again consider the travel AI Agent A, that AI
     agent might assist the user in selecting travel destinations and pick
     dates.  To actually book flights, the travel AI Agent A might connect
     the user to the flight AI Agent B within the airline.  Like the API
     case, there are two distinct relationships that are possible.  Domain
     A might have the relationship with domain B, in which case the
     authorization tokens used between them are service accounts and not
     specific to User A.  Alternatively, it is user A which might have the
     relationship with domain B and its AI Agent.  In that case, User A
     would need to grant domain A access to the AI Agent in domain B,
     giving it permissions to communicate and take certain actions.

     So far, we've been vague about the notion of how user A - having
     started is communications with AI Agent A - is connected to AI Agents
     Z or B.  We can envision a finite set of techniques, which mirror how
     this would work when transferred a user between human agents in a
     contact center:

     1.  Blind Transfer: In this case, User A is literally redirected from
         AI Agent A to the receiving agent, AI Agent Z.  In a blind
         transfer, AI Agent A is not a participant in, and has no access
         to, the communications with AI Agent Z after the transfer.
         However, there could be contextual information transferred from
         AI Agent A to AI Agent Z.  This could be transcript history, API
         requests and resulting data, and any other context which had
         previously been known to AI Agent A.

     2.  Supervised Transfer: In this case, User A is told by AI Agent A
         that they will be connected to AI Agent Z.  TO do that, AI agent
         A "conferences" in AI Agent Z, so that now all three are together
         in a group conversation.  AI Agent A would communicate with agent
         Z - in a format comprehensible to user A - that a transfer is
         taking place.  This aspect of the supervised transfer is for the
         benefit of the end user, giving them comfort that a transfer is
         happening and making sure they know that the receiving AI Agent
         has context.  Of course, there may additionally be transfer of
         programmatic information in the same way described for the blind
         transfer case.  Once the introduction has completed, AI Agent A
         drops and now the user is talking solely to agent Z.

     3.  Sidebar: In this case, AI agent A "talks" to AI Agent Z, but none
         of that communications is shown to User A.  Instead, it is purely
         to provide AI agent A information it requires in order to



  Rosenberg & Jennings     Expires 6 November 2025                [Page 9]


  Internet-Draft                AI Protocols                      May 2025


         continue handling user A.  As an example, we return to our travel
         booking AI agent.  User A asks it, "What are the most popular
         travel destinations for a spring beach vacation?".  AI Agent may
         not have the context to answer this question.  So, it instead
         connects to a travel blog AI Agent, and - in this case - makes
         the same inquiry to it, adding however additional context about
         User A.  It asks the travel blog agent, "For people living in New
         York, what are the most popular travel destinations for a spring
         beach vacation?  Please format your response in JSON."  When the
         results come back - here in structured data format - AI Agent A
         (the travel booking agent) might lookup each city in a database
         to retrieve a photo, and then render a photo carousel to the user
         with the three top cities.  In this example, the sidebar is a
         single back and forth.  There can be more complex cases where
         multiple back and forths are required to provide AI Agent A the
         information it needs.

     4.  Conference: In this case, AI agent A has AI agent Z join a group
         conversation, which then involves User A, AI Agent A and AI Agent
         Z.  The three of them converse together.  Both AI agent A and AI
         Agent Z are able to see all messages.  The agents would need to
         be programmed (via their prompting) to try and determine whether
         each user utterance is directed at them, or the other AI agent.
         Similarly, it would need to know whether it is required to
         respond to, or just add to its context, utterances sent by the
         other AI Agent.

     5.  Passthrough: In this case, User A connects to AI Agent A, which
         then realizes it wants to connect the user to AI Agent Z.  To do
         that, it acts as a proxy, relaying content from AI Agent Z to
         User A, and relaying content from User A to AI Agent Z.  The AI
         Agent doesn't take action on the content, but it might store it
         for contextual history.  In SIP terminology, this can be
         considered a "B2BUA".

     It is worth noting that these variations are all also possible in the
     case where it is User S is being added to the conversation, and not
     AI Agent Z.  This has implications on the AI agent to Ai agent
     protocols, as noted in the discussions below.

     We refer to the AI agent which makes the decision to involve a second
     AI Agent as the invoking AI agent.  The AI agent which is then
     brought into the conversation using one of the topologies above, is
     called the invoked AI Agent.







  Rosenberg & Jennings     Expires 6 November 2025               [Page 10]


  Internet-Draft                AI Protocols                      May 2025


  3.  Protocol Requirements and Considerations

     Each of these three areas of protocol - user to AI agent, AI Agent to
     API and AI Agent to AI Agent, have considerations and requirements
     that are important for standardization.

  3.1.  User to AI Agent

     As noted above, for the most part, this aspect of communication is
     well covered by industry standards, and is often done via proprietary
     means when the user and AI agent are within the same administrative
     domain.

  3.1.1.  Authentication

     One area of particular interest is user authentication.  For many use
     cases, the AI Agent will need to know who the user is.  For a web
     chat bot on a web page, the identity is easily known if the user has
     already logged into the web page.  However, there are many other
     communications channels where the user identity is not so easily
     known.  For example, if the user initiates communications over SMS,
     the AI agent has only the phone number of the originator.  Similarly,
     if it is via a voice call on the PSTN, there is nothing but the
     caller ID.  Even for web chat, the hosting web site might not support
     authentication.  A great example of this are websites for services
     like plumbing or home repair.  Users might be customers of these
     providers, but the website doesn't have traditional authentication
     techniques.

     In all of these cases, authentication needs to take place through the
     communications channel, often with proof of knowledge demonstrations
     by the end user.  This is how it is done when the agent is an actual
     human and not an AI.  When a user calls their plumber, the user
     provides their account number, or even just their name and address.
     For other services, such as a bank or healthcare provider, more
     complex authentication is required.  Usually, multiple pieces of
     personally identifying information are required.  When calling a
     doctor, the patient's zip code, name, and date of birth may all be
     required.

     These forms of authentication introduce additional complexity for the
     AI agent to API and AI agent to AI Agent communications.  This
     authenticated identity needs to be communicated.  This is noted in
     sections below.







  Rosenberg & Jennings     Expires 6 November 2025               [Page 11]


  Internet-Draft                AI Protocols                      May 2025


  3.2.  AI Agent to API

     The first question everyone asks when considering this area is - do
     we need new standards at all?

     After all, there are already standards for APIs, primarily using
     REST.  Standards exist for describing REST APIs, and indeed they
     contain descriptive information which can be consumed by an LLM to
     determine how to invoke the API.  Indeed, early versions of AI agents
     have been built by just pointing them at (or uploading) OpenAPI yaml
     specifications, resulting in functional AI Agents.  However, when the
     fuller scope of use cases are considered, several additional
     considerations come to light.

  3.2.1.  Discovery

     Initial versions of AI agents required manual upload of OpenAPI
     specifications.  This can be improved through discovery techniques
     which allow AI agents to quickly find and utilize such
     specifications.

     Discovery can happen for intra-domain cases - where it is simpler -
     or for inter-domain cases.  For inter-domain cases, a primary
     consideration is one of authentication and access.  An AI agent won't
     in general just be allowed to invoke any public API it discovers on
     the Internet.  This might be the case for general public read-only
     services, such as weather or maps.  However, in general, APIs will
     require authentication and authorization, and thus require some pre-
     established relationship.  This means discovery for most APIs is more
     of an issue of well-known locations for openAPI specifications.

  3.2.2.  AuthN and AuthZ on APIs

     A significant security consideration is around user authentication
     and authorization.  There are many use cases.

  3.2.2.1.  Intra-Domain Service to Service

     In this use case, AI Agent A performs the authentication of the user
     somehow.  As noted above, this may even involve exchange of proof-of-
     knowledge information over a communications channel, in which case
     there is no traditional access or bearer token generated for the end
     user.








  Rosenberg & Jennings     Expires 6 November 2025               [Page 12]


  Internet-Draft                AI Protocols                      May 2025


     AI Agent A, once it has determined the identity of user A, invokes
     APIs within its own domain.  It invokes these APIs using a service
     account, representing itself as the AI Agent.  The APIs allow the AI
     agent to take action on behalf of any end user within the domain.
     The APIs themselves would need to just contain user identifiers
     embedded with the API operations.

     This use case - which is largely how AI agents work today - requires
     no specific protocol standardization beyond what is possible today.

  3.2.2.2.  Intra-Domain OBO

     A significant drawback of the technique in the previous section is
     that it requires the AI agent to have very high privilege access to
     APIs within the domain.  This is perhaps not a major concern for
     prior generates of AI agents whose behaviours were programmed, and
     therefore the risk of malicious users or inaccurate AI was much less.

     But, with AI agents, there are real risks that users could
     maliciously (through prompt injection attacks for example) direct an
     AI agent to invoke APIs affecting other users.  Or, it could
     manipulate the APIs being invoked to do something different than what
     is expected.  Even without malicious intent, an AI agent might make a
     mistake and invoke the wrong API, causing damage to the enterprise.

     A way to address these is to have the AI Agent operate using a lower
     privilege access token - one specifically scoped to the user which
     has been authenticated.  This would prevent against many
     hallucination or prompt injection cases.  In essence, we want to have
     the AI Agent obtain a bearer token which lets them operate on-behalf-
     of (OBO) the end user it is serving.

     This is relatively straightforward when the user has performed normal
     authentication on a web chat bot, and is anyway passing a user token
     to the AI Agent.  The AI Agent can just use that same token for
     invoking downstream APIs, or else use that token to obtain other,
     scope limited tokens from a central authentication service.  However,
     things are more complicated when the user was authenticated using
     proof-of-knowledge via communication channels.  In this case, there
     was never a user token to begin with!











  Rosenberg & Jennings     Expires 6 November 2025               [Page 13]


  Internet-Draft                AI Protocols                      May 2025


     To support such cases, it is necessary for the AI Agent to obtain a
     token for the user.  To do so, it would ideally communicate with some
     kind of central identity service, providing the information offered
     by the end user (the date of birth, address, and name in the example
     above), and then obtain a token representing that user.  The
     resulting tokens would ideally contain programmatic representations
     of the techniques by which the user was authenticated.  This would
     allow APIs which accept these tokens to perhaps decide that
     additional levels of authentication are required.

     This is common today when dealing with human agents.  A user calling
     their bank to check on open hours may not require any authentication
     at all.  Once the user asks for an account balance, the human agent
     will perform an authentication step by requesting identification
     information from the user.  Account status can then be provided.
     Finally, if the user then asks for a wire transfer, the human agent
     may ask for further authentication, including perhaps having the end
     user receive a text at their mobile number and real a one-time code.

     To support equivalent security, this needs to manifest within
     protocols.  If an AI Agent attempts to invoke an API for which the
     token has insufficient strength of authentication, the API request
     needs to be rejected, and then the AI agent needs to communicate with
     the user to obtain further identification information, and obtain a
     new token with higher privilege.

     Additionally, the meta-data describing the APIs would specify the
     required level of identity verification required to invoke them, so
     that the AI agent can request the information from the user and
     obtain a new token, rather than trying and failing on the prior,
     lower privilege token.

     Could these tokens also be used for inter-domain use cases?  Perhaps.

  3.2.2.3.  Inter-Domain OAuth

     Consider User A talking to AI Agent A which is accessing APIs in
     domain B.  In the case where User A has the relationship with domain
     B, the user will grant permissions to AI Agent A with a given scope.
     That scope will restrict the set of APIs which the AI agent is
     allowed to use.  For the AI Agent to operate effectively, it will
     need to know which APIs are accessible for a given scope.  This needs
     to be via both natural language, and likely programmatic
     descriptions.  This would allow the AI Agent behaviour to adjust
     based on what access the user has.






  Rosenberg & Jennings     Expires 6 November 2025               [Page 14]


  Internet-Draft                AI Protocols                      May 2025


     To give a concrete example, consider again the travel booking AI
     agent.  User A has executed an OAuth grant flow, and granted the AI
     Agent access to look up trips and frequent flier status, but not to
     book trips or modify reservations.  The user might ask the AI Agent,
     "can I change my reservation?" and we want the AI Agent A to be able
     to respond, "I'm sorry, I dont have sufficient permission to perform
     that operation.  I can initiate a flow by which you'll log into the
     airline and grant me that permission.  Would you like me to do that?"
     And then the user response, "what exactly would granting this
     permission do?" and we want the AI to be able to respond along the
     lines of, "The permission I will request - change reservations -
     grants me the ability to modify your reservations on your behalf."
     The user might ask, "are you also allowed to delete them?" and it
     would respond, "Yes, the scope I would request grants me permission
     to delete your reservations.".  The user could even respond, "I don't
     want that.  I want to make sure you cannot delete my reservations".
     If the airline offered a scope which excluded deletions, it could
     respond with, "OK, I'll request permissions only to modify and not
     delete.  Are you ready to grant me those permissions?".  At that
     point, the user would get an OAuth popup asking for modification
     permissions.

     Once those permissions are granted, the AI Agent would need to then
     know the specific APIs available to it at the granted scope.  Indeed,
     as a matter of privacy, domain B might not want AI Agent A to know
     ALL of the APIs it has, it may want to restrict it to just those
     associated with the scopes that its users have granted.  This
     reduction in the amount of detail offered to the AI Agent can also
     help improve AI accuracy, by reducing the amount of extraneous
     information it has access to.

     For this to work as described, we need additional standardization
     allowing natural language descriptions of API scopes to be produced
     by one domain, read by the AI agent in another, and then allow API
     specifications to be conveyed based on granted scopes.

  3.2.3.  User Confirmation

     When APIs are for read only, there is low risk of the AI doing the
     wrong thing.  If a user requests information about their flight to
     New York and the AI instead returns the flight to York, this is
     frustrating for the user but not dangerous.  This is not the case for
     APIs that have side effects, including creation, update and delete
     operations on RESTful objects.  For these operations, there is a real
     risk that the AI Agent invokes the wrong API, or invokes it with the
     wrong data.  To reduce this risk, it is important that the user
     provides confirmation, and that this confirmation happen
     programatically, outside of the LLM prompt inference.



  Rosenberg & Jennings     Expires 6 November 2025               [Page 15]


  Internet-Draft                AI Protocols                      May 2025


     To do that, it will be necessary for the AI Agent system to know
     which APIs require user confirmation, and which do not.  This is a
     decision which can only be made by the API owner.  Consequently,
     there is a need to annotate the APIs with ones that require
     confirmation.  But, it goes beyond this.  Users cannot be expected to
     view a JSON object and confirm its accuracy.  Consequently, for each
     operation that has side effects, the API needs to be adorned with
     user visible names and descriptions of attributes which require
     confirmation, and then a mapping of those into the JSON payloads.
     This would allow the AI model to know that it needs to collect a set
     of data, and then once collected, the AI agent - not the LLM, but
     something programmatic - can render this information to the user, get
     their confirmation, map it into the API, invoke the API and then feed
     the results into the LLM.  This provides 100% guarantee that the
     system is doing what the user wants, and not something else.  All of
     this requires additional protocol machinery to convey this
     information and mappings, and is not covered today by typical API
     specifications.

  3.2.4.  API Customization for AI Agents

     REST APIs today are crafted by humans, meant to be understood by
     humans and then implemented by humans into code that exercises them.
     Consequently, they are often highly complex, with many parameters and
     variations.  Using those APIs - and their corresponding
     specifications - introduces a problem.  While AIs can understand
     them, they may contain more information than is strictly needed,
     increasing the risk of inaccuracy or hallucination.  An alternative
     model is to have simplified APIs - ones better aligned to the
     information that the AI Agent needs to collect from the humans in the
     conversation.

     These specifications will also require descriptions that are consumed
     by the LLM to understand how to use them.  Typically, content and
     prompts are ideally tuned to a specific model for optimal outcomes.
     One could imagine that API provider B might have several variations
     of the API specifications and descriptions optimized for different
     models.  Consequently, the protocol for retrieving them would need to
     communicate the LLM models used by domain A to retrieve the optimal
     descriptions.

     It is not entirely clear this level of customization is needed, but
     it is worth calling out as something unique for AI Agents.

  3.3.  AI Agent to AI Agent

     There are many considerations for standardization in this area.




  Rosenberg & Jennings     Expires 6 November 2025               [Page 16]


  Internet-Draft                AI Protocols                      May 2025


  3.3.1.  Discovery

     One possible area for standardization is discovery - how do agents
     discover the availability of other agents.  Discovery is often not
     needed however.  For intra-domain cases, most of the agents are well
     known to administrators, and they can be configured into the system.
     For inter-domain cases, discovery is more interesting.  However, as
     with AI Agent to API discovery, it is usually constrained by the
     requirements for authentication and access control.  AI Agent A
     cannot communicate with other agents without a prior established
     security relationship, in which case discovery is less of a
     consideration.

     Indeed, a high level of trust is required for one AI agent to talk to
     another one.  A malicious AI agent that is discovered and used, could
     perform prompt injection attacks, possibly granting it access to the
     APIs that the other agent has access to.  It could inject malicious
     or unwanted content that is passed on to the end user.

  3.3.2.  Routing and Connection

     For one AI Agent to communicate with another one, it needs to know
     when to route communications to that agent.  This requires
     information to be communicated from the agent being invoked, to the
     invoking agent.  This information needs to be sufficient for
     ingestion by a LLM to make a routing decision, and likely requires
     text in natural language format to be communicated.  This also raises
     considerations around languages.  One can imagine that AI Agent A
     operates in Spanish, and would prefer to receive information to
     facilitate routing in Spanish as well.

     Capabilities are also relevant for routing.  One important area of
     capability discovery is channel capability.  If AI Agent A is
     communicating with a user using voice from a web page, and AI Agent A
     wishes to engage AI Agent B using passthrough mode, or even transfer,
     it will need to know whether or not possible agents support voice.
     As with other areas of capabilities, there is a possibility for
     negotiation.  For example, AI Agent A might currently be serving user
     A using voice chat on a web page, but it can also support web chat.
     If AI Agent Z supports only web chat, it can be utilized and the
     communications session downgraded to web chat.










  Rosenberg & Jennings     Expires 6 November 2025               [Page 17]


  Internet-Draft                AI Protocols                      May 2025


     Each of these channels will come with their own parameters defining
     capabilities which need to be considered when both selecting the
     agent, and connecting to it.  If User A is connecting to AI Agent A
     using web chat, the web chat widget might support images, carousels
     and links, but might not support embedded videos.  When AI Agent Z is
     connected, it needs to know that it cannot send embedded videos.
     Furthermore, that agent cannot process images uploaded by users, that
     feature needs to be disabled from the UI used by the agent.

  3.3.3.  Lifecycle Management

     A key functional component of the inter-agent protocol is agent
     lifecycle.  The connection with AI Agent A will go through states,
     initiated when the connection is first made, and then eventually
     terminate once the task for which it was engaged has been completed.
     There may be intermediate states as well.  For example, if the
     downstream agent needs to perform tasks which have asynchronous
     components, the agent may need to go into a suspended mode while it
     waits for a response.  This needs to be passed upstream to the
     invoking agent, so that it can take the appropriate action.  It may
     elect to suspend itself as well, or may choose to retake control and
     engage with the user in other conversations while the other AI Agent
     works to complete its tasks.

     There will need to be functionality in the protocol allowing the
     invoking agent to terminate communications with the target agent,
     either at the behest of the end user or under its own control.

     Different agents may also support different types of lifecycles,
     which needs to be communicated.  For example, AI agents can have
     different properties:

     1.  Transactional vs. Conversational: A transactional AI agent
         receives an instruction in natural language format that requests
         a task to be performed.  Once it performs it, the response comes
         back.  There is no back-and-forth with the requester of the task.
         As an example, an AI agent may provide transactional capabilities
         for image creation, sending a request along the lines of "Create
         an image of a solar system with three green planets orbiting a
         red sun, taken from above".  The response that comes back is the
         requested image.  An AI Agent might support transactional
         interactions, allowing back and forth with the end user.  This is
         possible with the image generation example, where the user could
         receive the resulting image and then request modifications.

     2.  Synchronous vs. Asynchronous: A Synchronous AI agent executes
         communications sessions with a discrete begin and end,
         interacting back and forth with the invoker.  There may be



  Rosenberg & Jennings     Expires 6 November 2025               [Page 18]


  Internet-Draft                AI Protocols                      May 2025


         timeouts if there is inactivity.  For these type of agents, all
         of the work performed by the AI Agent occurs in real-time and can
         happen during the lifetime of the session.  The image generation
         agent is a good example of it.  An AI Agent that is asynchronous
         needs to perform actions which have a lengthy or even potentially
         unbounded amount of time to complete.  This can happen when tasks
         take significant computation (for example, a research AI Agent
         which analyzes documents and prepares a summary, which can take
         several hours).  This can also happen when an AI Agent needs to
         engage with a human.  Using our loan example, AI Agent Z may be a
         loan approval AI Agent, and depending on the requested loan, may
         require approval from a human.  If the request is made off-hours,
         a human may not be available until the next morning to service
         the request.

     These two properties are orthogonal.  An AI Agent can be
     transactional and synchronous - our AI image generation example
     above.  But it can also be transactional and asynchronous.  A good
     example of such an AI agent is an HR AI Agent used to approve a hire.
     This AI Agent would take a simple transactional request - "Obtain
     approval or disapproval to extend an offer to candidate Bharathi
     Ramachandran".  This requires the AI Agent to gather data by invoking
     APIs and may require human approval from the head of HR.  This can
     take potentially an unbounded amount of time.

     For inter AI agents to work, these characteristics need to be
     transferred programatically from one agent to another, which then
     guides its operation.

     Support for asynchronous AI Agents in particular requires additional
     protocol machinery.  There is a need for some kind of callback, in
     which AI Agent Z can reconnect to AI Agent A.  The end user may have
     also disconnected, requiring a reconnection.  Whether such
     reconnection is possible or not depends on the communications
     channels and user configuration.  For example, if User A was
     communicating with AI Agent A - an internal IT bot supporting a wide
     range of employee needs - using SMS, and user A asks AI Agent A to
     approve the hire, this might trigger AI Agent A to reach out to the
     HR AI Agent noted above.  Once approval is obtain, AI Agent Z needs
     to re-initiate messaging backwards towards AI Agent A.  AI Agent A
     then needs to send an SMS back to the end user.  If, on the other
     hand, user A was connected to AI Agent A using web chat, reconnection
     to user A may not be possible.  This could perhaps mean that the HR
     agent cannot be invoked at all, and an error needs to be returned to
     the user.  Or, the HR AI Agent may support a modality wherein it
     emails the employee with the approval decision.  These constraints
     and possibilities must be negotiated between agents to drive
     appropriate behavior.



  Rosenberg & Jennings     Expires 6 November 2025               [Page 19]


  Internet-Draft                AI Protocols                      May 2025


     Asynchronous agents might also support polling for state updates,
     wherein the end user can request updates on progress.  This will
     require protocol machinery.  Polling for updates could happen several
     different ways.  During an active synchronous session between user A
     and AI Agent A, the user can request an operation that triggers a
     transactional async task to be sent to AI Agent Z (again the HR
     approval agent in our use case).  The end user might continue its
     dialog with AI Agent A (the IT AI Agent) inquiring about an open
     ticket for a computer problem.  During that chat, the user might ask
     for an update.  For example, "Has the HR approval been completed yet
     by the way?".  AI Agent A needs to then poll for an update from AI
     Agent Z so it can return the result.  In this case, the interaction
     between AI Agent A and Z is more like an API.  AI Agent A may not
     even remember (due to a failure or reconnection) that it has
     outstanding tasks with AI Agent Z.  This requires API support for
     enumeration of pending tasks on downstream agents.

  3.3.4.  Data Transferrance

     During the lifetime of the interconnection between agents,
     information will need to be transferred back and forth.  The protocol
     will need to allow for this.

     One dimension of protocol requirements are related to capabilities,
     already noted in the section above.

  3.3.4.1.  Context Transfer

     Another aspect of data transferrance is context transfer.  When AI
     Agent A first connects to AI Agent Z, it will likely want to transfer
     context about the user, about the conversation, about itself, and
     about the task that was requested by the end user.  This information
     will be necessary for the invoked agent to be effective.  Coming back
     to our travel use case, when the travel AI Agent invokes the flight
     booking agent, the flight booking agent will need to know:

     1.  The name and other contact information for the end user (see
         discussion below on authentication and authorization),

     2.  The name and description of the invoking AI agent, so that the
         flight booking agent can greet appropriately.  For example, "Hi
         Alice, I'm the United Airlines agent.  I understand that you've
         been booking a trip with Expedia and need a flight?"

     3.  The transcript of the conversation to date.  For example, if the
         user had been debating a few options for departure cities and
         finally settled on New York to LA (instead of Philadelphia to LA)
         this could be relevant for the booking agent to convey additional



  Rosenberg & Jennings     Expires 6 November 2025               [Page 20]


  Internet-Draft                AI Protocols                      May 2025


         information not known to the travel agent.  For example, "Hi
         Alice, I can help book your flight from New York to LA.  However,
         you may not have been aware that flight costs departing from New
         York are higher in the summer, and you'd probably be better off
         traveling from Philadelphia on that day."

     To facilitate context transfer, the receiving AI Agent may want to
     convey, programmatically, to the invoking AI Agent, the set of
     contextual information it is prepared to process.  It might want to
     only see the conversation transcript.  Or, it might want user
     background.  There may be syntactic constraints, such as context
     length and character sets.  Context transfer also introduces security
     considerations, as noted below.

  3.3.4.2.  Mid-Session Data Transfer

     For conversational sessions, messages will be sent back and forth
     amongst the participants (user A, AI Agent A and AI Agent Z).  The
     end user will originate new text messages, images or other user
     provided content, which are in essence targeted at the invoked AI
     agent, Agent Z.  The invoked AI Agent will similarly wish to transfer
     messages back to the end user.  In the case where AI Agent A is in a
     conference with AI Agent Z and the end user - or when it is operating
     in passthrough mode - these messages need to be tagged as being sent
     by the user, or targeted to the user, so that they do not trigger
     responses from AI Agent A.  However, there will be meta-data that
     needs to be communicated as well.  AI Agent Z, when it completes its
     task, needs to convey this information back towards AI Agent A.  This
     is meta-data and not meant to be rendered to the end user.
     Similarly, if AI Agent Z is asked to perform a task whose output is
     programmatic and meant to be consumed by AI Agent A, then it needs to
     be tagged in this way.  As an example, when the flight booking AI
     Agent has completed its flight booking, it needs to pass information
     back to the travel AI Agent containing the flight number, origin and
     destination airport, booking code, and so on.  This information might
     need to be stored or processed in a programmatic fashion by AI Agent
     A.  AI Agent A may then take this information and turn it into a
     piece of rendered web content which can be shown to the user.  In
     this case, the result of the flight booking is meta-data, and needs
     to be sent by AI Agent Z, targeted towards AI Agent A.

     These use cases require protocol machinery to facilitate data typing,
     data source and destination identification, and up front negotiation
     on what is permitted and what is not.







  Rosenberg & Jennings     Expires 6 November 2025               [Page 21]


  Internet-Draft                AI Protocols                      May 2025


  3.3.5.  Authentication and Authorization

     AuthN and AuthZ are significant considerations for inter-agent
     communications.

     In many cases, the behaviours taken by the invoked AI Agent depend on
     the identity of the user that connected to the invoking agent.  How
     does the invoked agent determine this identity reliably?  There are,
     broadly speaking, two approaches:

     1.  Conveyed Identity: The invoking AI agent authenticates the end
         user, and passes this identity in a secure fashion to the invoked
         AI Agent

     2.  Re-Authentication: The invoked AI Agent separately authenticates
         the end user

     In the case of conveyed identity, standards are needed for how the
     identity is communicated to the invoked AI agent.  This undoubtedly
     involves the transferrance of the token.  That transferrance itself
     needs to be secured.  This is of particular concern in inter-domain
     use cases, to be sure that the token is only accessible by the AI
     Agent to which it is destined.  Invoked AI Agents may have
     requirements about the strength of the authentication that has been
     performed.  For example, if the invoking AI Agent authenticated the
     user via proof of knowledge techniques as discussed in Section XX, an
     invoked AI Agent may require stronger authentication of the user
     before proceeding.

     In the case of re-authentication, standards are also required that
     allow for such authentication to occur.  In the simplest case, the
     user has credentials with domain B, and meta-data needs to be pushed
     to the user to trigger an authentication flow, ideally with a web
     popup.  Things are even more complicated when the user doesn't hold
     credentials with domain B, and authentication is done via proof-of-
     knowledge of PII over the communications channel.  If AI Agent A is
     party to these communications, it could reveal PII to AI Agent A
     which it should no be privy to.  In such cases, there would need to
     be a way for the communication to be encrypted e2e between AI Agent B
     and the user, or else a way for the authentication to happen out of
     band without the involvement of AI Agent A.

     Authorization is similarly complex.  The core objective is that the
     end user have the ability to control - with certainty (not subject to
     hallucination error), the actions that the invoked AI Agent can take.
     This is similar to the core requirement given an AI agent permission
     to access APIs, where the authorization can be controlled via
     traditional OAuth grant flows, as described in Section XX.  This is



  Rosenberg & Jennings     Expires 6 November 2025               [Page 22]


  Internet-Draft                AI Protocols                      May 2025


     more complex in he case of AI Agents.  The whole idea of an AI Agent
     is that it can perform a wide range of tasks - many of which are not
     predetermined.  How then can a user grant permissions to an AI Agent
     to limit what tasks it can perform, when those tasks are not simply
     an enumerated set of APIs within a specific scope?  This would need
     to be sorted out.

  3.3.6.  User Confirmation

     The same requirements for user confirmation as discussed in
     Section XX for AI agent to API actions, apply to AI agent to AI Agent
     communication to.  When the invoked AI Agent is about to perform an
     action by invoking APIs with side effect, a confirmation must be
     generated by the invoked AI Agent, passed back to the invoking AI
     Agent and then communicated to the end user.  The user confirmation
     is then passed back to the invoked AI Agent.  The inter-agent aspect
     of this confirmation raises additional security considerations.  How
     can the invoked AI agent trust that the confirmation actually came
     from the end user, and is not instead a hallucination generated by
     the invoking AI Agent?  This will also require protocol machinery to
     provider cryptographic assurances.

  3.3.7.  Prompt Injection Attacks

     The communications between AI agents introduces additional concerns
     around prompt injection attacks.  Specifically, it introduces a new
     threat vector.  A malicious user A, while communicating with AI Agent
     A, can request services of a third AI Agent, AI Agent Z (the invoked
     AI Agent).  User A can then send malicious messages, which are
     conveyed through AI Agent A to AI Agent Z, in an attempt to cause it
     to perform unanticipated actions with the APIs it has access to.  The
     cascading of AI Agents also introduces another possibility - that
     user A induces a prompt injection attack against AI Agent A, in an
     attempt to get it to generate malicious content towards AI Agent Z.

     Prompt injection attacks are notoriously difficult to prevent.  But,
     the protocol needs to consider these cases and introduce techniques
     to aid in diagnoses, logging and attribution.

  4.  Analysis of Existing Protocols

     This section briefly introduces the Model Context Protocol (MCP), the
     Agent-to-Agent Protocol (A2A) and the Agntcy Framework, and maps them
     into the framework described in this document.







  Rosenberg & Jennings     Expires 6 November 2025               [Page 23]


  Internet-Draft                AI Protocols                      May 2025


  4.1.  MCP

     The Model Context Protocol (ref) enables operations between a client
     - typically an AI Agent acting on the user's behalf - to access
     services provided by servers running on the same local host as the
     client.  MCP defines three distinct services that servers can offer,
     which are:

     1.  Resources: These are files, DB records, log files, and other
         forms of static content.

     2.  Prompts: These are AI prompts, which can perform a transactional
         operation, taking input and returning an output

     3.  Tools: There are APIs, which provide programmatic functions on a
         set of given inputs, providing a specified output.  An example is
         a shell command on a terminal.

     MCP provides a way for clients to enumerate these services, obtain
     descriptions of them, and then access them.

     Though MCP is targeted for operation within a single host and not
     over the Internet, we can extrapolate its usage over the Internet and
     map it into the framework here.  In this framework, MCP covers AI
     Agent to API communications.  Because it is meant for intra-host
     communication, it does not address many of the use cases around
     intra-domain and inter-domain security discussed in this framework.

  4.2.  A2A

     The Agent-to-Agent (A2A) protocol focuses on - as the name implies -
     communications between agents.  It specifies an "agent card" which is
     a programmatic definition of an AI agent which can be discovered by
     other AI Agents.  It provides a protocol offer JSON-RPC for one AI
     Agent to invoke a task on another agent.  If offers protocol
     machinery for lifecycle management of the task, including completing
     it and passing back artifacts.  It facilitates messages between users
     and the invoked AI agent.  It provides for synchronous and
     asynchronous invocations.












  Rosenberg & Jennings     Expires 6 November 2025               [Page 24]


  Internet-Draft                AI Protocols                      May 2025


     As the name implies, A2A fits within this framework as an agent to
     agent protocol.  It provides for some of the functional requirements
     outlined in this framework, most notably lifecycle management, data
     and meta-data passing.  It also offers discovery.  It does not
     address the channel capability use cases discussed in Section XX.  It
     does offer authentication and authorization, largely off-the-shelf
     OAuth using OpenAPI's authentication flows.  It does not cover the
     use cases identified in Section XX.  It doesn't provide the user
     confirmation functionality described in Section XX.

  4.3.  Agntcy

     Agntcy is a framework, not a protocol per se.  Like A2A, if focuses
     on agent to agent communications.  It discusses discovery,
     hypothesizing the use of a DHT for discovery of agents.  It makes use
     of the Open Agentic Schema Framework (OASF) to provide a standardized
     way for agents to declare their skills and be discoverable based on
     searches for those skills.  It enables the transferrance of an agent
     manifest which describes the agent and how to connect to it.  It
     considers cases where the agent is downloaded and run as a docker
     image or langchain library, in addition to being access over the
     Internet.  It discusses an Agent Connect Protocol (ACP) which is
     similar in concept to Googles A2A protocol, enabling agents to talk
     to each other.  Each agent declares, through meta-data, the
     configuration and invocation techniques it supports, including sync
     and async techniques.

     Agntcy is similar to Google A2A and fits into this framework as an AI
     Agent to AI Agent Protocol.  It covers discovery, which is a heavy
     focus of the framework.  Its manifests meet some of the requirements
     around routing, focusing on skills.  It does not address the
     capability considerations discussed in Section XX.  The ACP protocol
     provides basic invocations but does not address the full scope of
     lifecycle management discussed here.  It facilitates data
     transferrance but doesn't address the full set of use cases described
     in Section YY.  It doesn't address AuthN or AuthZ and doesn't have
     any explicit support for user confirmations.

  5.  Conclusions

     In conclusion, the framework described in this document covers a
     range of use cases and requirements for AI Agent interconnection.
     Many of the use cases and requirements cannot be satisfied with
     existing protocols and standards, leaving ample room for additional
     standards activity to be undertaken.  Existing standards work, done
     outside of the IETF, covers some but not all of the use cases and
     requirements defined in this framework.




  Rosenberg & Jennings     Expires 6 November 2025               [Page 25]


  Internet-Draft                AI Protocols                      May 2025


  6.  Informative References

     [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                DOI 10.17487/RFC3261, June 2002,
                <https://www.rfc-editor.org/info/rfc3261>.

     [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
                July 2003, <https://www.rfc-editor.org/info/rfc3550>.

     [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                DOI 10.17487/RFC0768, August 1980,
                <https://www.rfc-editor.org/info/rfc768>.

     [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/info/rfc791>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/info/rfc9000>.

     [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
                June 2022, <https://www.rfc-editor.org/info/rfc9114>.

     [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
                STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
                <https://www.rfc-editor.org/info/rfc9293>.

  Authors' Addresses

     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Cullen Jennings
     Cisco
     Email: fluffy@cisco.com








  Rosenberg & Jennings     Expires 6 November 2025               [Page 26]


name: draft-patwhite-aauth
rev: 00
title: AAuth - Agentic Authorization OAuth 2.1 Extension
time: 2025-05-13T14:16:42Z
group_uri: /api/v1/group/group/1027/
expires: 2025-11-14T14:16:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:07.578595+00:00
source: ietf
abstract:
  This document defines the *Agent Authorization Grant*, an OAuth 2.1
     extension for *confidential agent clients*—software or AI agents with
     long-lived identities—to request end-user consent and obtain access
     tokens via HTTP polling, Server-Sent Events (SSE), or WebSocket.  It
     is heavily inspired by the core dance of the OAuth 2.0 Device
     Authorization Grant (RFC 8628) but is tailored for agents either long
     lived identities, and introduces scoped, natural-language
     descriptions and a reason parameter provided by the agent.

full_text:
  Network Working Group                                           P. White
  Internet-Draft                                               13 May 2025
  Intended status: Informational                                          
  Expires: 14 November 2025


             AAuth - Agentic Authorization OAuth 2.1 Extension
                          draft-patwhite-aauth-00

  Abstract

     This document defines the *Agent Authorization Grant*, an OAuth 2.1
     extension for *confidential agent clients*—software or AI agents with
     long-lived identities—to request end-user consent and obtain access
     tokens via HTTP polling, Server-Sent Events (SSE), or WebSocket.  It
     is heavily inspired by the core dance of the OAuth 2.0 Device
     Authorization Grant (RFC 8628) but is tailored for agents either long
     lived identities, and introduces scoped, natural-language
     descriptions and a reason parameter provided by the 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).  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 14 November 2025.

  Copyright Notice

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










  White                   Expires 14 November 2025                [Page 1]


  Internet-Draft                    AAuth                         May 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.  Conventions and Requirements Language . . . . . . . . . . . .   2
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.  Agent Authorization Grant . . . . . . . . . . . . . . . . . .   3
       4.1.  Agent Authorization Request . . . . . . . . . . . . . . .   3
       4.2.  User Approval User Approval . . . . . . . . . . . . . . .   4
       4.3.  Token Retrieval . . . . . . . . . . . . . . . . . . . . .   4
       4.4.  Error Handling & Back-Off . . . . . . . . . . . . . . . .   5
     5.  Security Considerations.  Security Considerations . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     OAuth 2.1 provides a framework for delegated access via bearer
     tokens.  In modern AI architectures, *agents*—autonomous software
     processes—act on behalf of users or other agents.  This extension
     defines the *Agent Authorization Grant*, enabling agents with long
     lived identities to request a delegated token with human-in-the-loop
     consent, and to receive tokens asynchronously via polling, SSE, or
     WebSocket, while leveraging natural-language scope descriptions
     published by resource servers.

  2.  Conventions and Requirements Language

     The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHOULD”,
     “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be
     interpreted as described in [RFC2119].

  3.  Terminology

     *  *Agent*: A confidential client (software or AI) with a stable,
        long-lived identity (client_id).
     *  *Authorization Server (AS)*: Issues request_code handles, manages
        user consent, and issues access tokens.




  White                   Expires 14 November 2025                [Page 2]


  Internet-Draft                    AAuth                         May 2025


     *  *Resource Server (RS)*: API server that protects resources via
        OAuth tokens and publishes human-readable scope descriptions at
        /.well-known/aauth.json.
     *  *request_code*: Opaque handle returned by the AS to correlate an
        agent’s request with subsequent token retrieval.
     *  *reason*: Human-readable explanation provided by the agent, shown
        to the user during consent.
     *  *scope_descriptions*: Natural-language text for each requested
        scope, fetched from the RS’s discovery document.

  4.  Agent Authorization Grant

     |  This flow is modeled on the OAuth 2.0 Device Authorization Grant
     |  (RFC 8628) but is tailored for *confidential agent clients* with
     |  long-lived identities, and optimized for performant delivery of
     |  tokens to the agent.

  4.1.  Agent Authorization Request

     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.
     2.  *Fetches* each scope’s description from the target RS’s
         https://{rs}/.well-known/aauth.json#scope_descriptions.
     3.  *Returns:*








  White                   Expires 14 November 2025                [Page 3]


  Internet-Draft                    AAuth                         May 2025


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

  4.2.  User Approval User Approval

     The AS is fully responsible for user 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.

  4.3.  Token Retrieval

     After user approval, the agent obtains its access token via one of:

     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.

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



  White                   Expires 14 November 2025                [Page 4]


  Internet-Draft                    AAuth                         May 2025


     On approval:

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

     3.  *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:

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

  4.4.  Error Handling & Back-Off

  *  *HTTP Polling*: MUST honor error="slow_down" with Retry-After
     headers; return standard OAuth error codes such as
     authorization_pending, access_denied, or expired_token.

  *  *Server-Sent Events (SSE)*:

     -  On token response:

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

     -  On user rejection:

  event: error
  data: {"error":"access_denied","error_description":"The user denied the request."}

     -  On request expiration:

  event: error
  data: {"error":"expired_token","error_description":"The request_code has expired."}

  *  *WebSocket*:




  White                   Expires 14 November 2025                [Page 5]


  Internet-Draft                    AAuth                         May 2025


     -  On token response:

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

     -  On user rejection or expiration:

     {"type":"error","error":"access_denied","error_description":"The user denied the request."}

     {"type":"error","error":"expired_token","error_description":"The request_code has expired."}

  *  *Security*: All endpoints SHOULD enforce TLS and require client
     authentication.

  5.  Security Considerations.  Security Considerations

     *  Agents MUST protect their long-lived credentials.
     *  Short-lived request_code and tokens limit replay risk.
     *  RS scope descriptions should not expose sensitive system details.
     *  Implement rate-limiting on polling and push channels to prevent
        abuse.

  6.  IANA Considerations

     This document registers the following new OAuth grant type:

     urn:ietf:params:oauth:grant-type:agent_authorization

  7.  References

  7.1.  Normative References

     *  [RFC2119] Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119.
     *  [RFC8628] Wahl, "OAuth 2.0 Device Authorization Grant", RFC 8628.
     *  [RFC8693] Jones & Campbell, "OAuth 2.0 Token Exchange", RFC 8693.
















  White                   Expires 14 November 2025                [Page 6]


name: draft-lkspa-wimse-verifiable-geo-fence
rev: 04
title: Privacy Preserving Verifiable Geofencing with Residency Proofs for Sovereign Workloads
time: 2026-03-02T03:05:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T03:05:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.773808+00:00
source: ietf
abstract:
  Modern cloud and distributed computing rely heavily on software-only
     identities and bearer tokens that are easily stolen, replayed, or
     used from unauthorized locations.  Furthermore, traditional methods
     of location verification - such as IP-address-based geolocation - are
     easily spoofed via VPNs or proxies and significantly compromise
     infrastructure security and privacy for *Sovereign Workloads* and
     high-assurance environments.  This document defines a *High-Assurance
     Profile* designed to solve these challenges through hardware-rooted
     cryptographic verifiability.

     A host machine runs a workload identity agent for managing the
     workload identities on that platform.  This proposal replaces
     implicit trust and spoofable indicators with cryptographically
     verifiable hardware-rooted evidence of integrity and location for
     this agent.  Critically, this framework prioritizes *Location
     Privacy* by utilizing Zero-Knowledge Proofs (ZKP), allowing a
     workload to prove it is within a compliant "Sovereign Zone" without
     disclosing precise coordinates that could be used for tracking or
     exploitation.

     By binding software identities to persistent silicon identities and
     verified physical residency, this solution establishes a "Silicon-to-
     Workload" chain of trust.  It ensures that sensitive operations are
     only performed by authorized workloads running on untampered hardware
     in cryptographically verified, privacy-preserving geographic
     boundaries, fulfilling the high-assurance requirements of the *WIMSE
     Architecture* [[I-D.ietf-wimse-architecture]].

full_text:
  RATS                                                         R. Krishnan
  Internet-Draft                                      JPMorgan Chase & Co.
  Intended status: Informational                                  N. Smith
  Expires: 2 September 2026                                          Intel
                                                                  D. Lopez
                                                                Telefonica
                                                                 A. Prasad
                                                                    Oracle
                                                              S. Addepalli
                                                                    Aryaka
                                                              1 March 2026


     Privacy Preserving Verifiable Geofencing with Residency Proofs for
                            Sovereign Workloads
                 draft-lkspa-wimse-verifiable-geo-fence-04

  Abstract

     Modern cloud and distributed computing rely heavily on software-only
     identities and bearer tokens that are easily stolen, replayed, or
     used from unauthorized locations.  Furthermore, traditional methods
     of location verification - such as IP-address-based geolocation - are
     easily spoofed via VPNs or proxies and significantly compromise
     infrastructure security and privacy for *Sovereign Workloads* and
     high-assurance environments.  This document defines a *High-Assurance
     Profile* designed to solve these challenges through hardware-rooted
     cryptographic verifiability.

     A host machine runs a workload identity agent for managing the
     workload identities on that platform.  This proposal replaces
     implicit trust and spoofable indicators with cryptographically
     verifiable hardware-rooted evidence of integrity and location for
     this agent.  Critically, this framework prioritizes *Location
     Privacy* by utilizing Zero-Knowledge Proofs (ZKP), allowing a
     workload to prove it is within a compliant "Sovereign Zone" without
     disclosing precise coordinates that could be used for tracking or
     exploitation.

     By binding software identities to persistent silicon identities and
     verified physical residency, this solution establishes a "Silicon-to-
     Workload" chain of trust.  It ensures that sensitive operations are
     only performed by authorized workloads running on untampered hardware
     in cryptographically verified, privacy-preserving geographic
     boundaries, fulfilling the high-assurance requirements of the *WIMSE
     Architecture* [[I-D.ietf-wimse-architecture]].





  Krishnan, et al.        Expires 2 September 2026                [Page 1]


  Internet-Draft                    V-GAP                       March 2026


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

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
       2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Server-centric Enforcement  . . . . . . . . . . . . . . .   6
       4.2.  User-centric Enforcement  . . . . . . . . . . . . . . . .   6
       4.3.  Compliance and Risk Reduction . . . . . . . . . . . . . .   7
     5.  Motivation and Gaps . . . . . . . . . . . . . . . . . . . . .   7
     6.  What This Profile Provides  . . . . . . . . . . . . . . . . .   7
     7.  Composition with Transitive Attestation and WIMSE . . . . . .   8
     8.  Operational Use: Gating Credentials on Verified Evidence  . .   9
     9.  High-Assurance Profile: Verifiable Geofencing Attestation
             Profile (V-GAP) . . . . . . . . . . . . . . . . . . . . .   9
       9.1.  LAH-Bundle: Location Anchor Host Evidence Structure . . .   9



  Krishnan, et al.        Expires 2 September 2026                [Page 2]


  Internet-Draft                    V-GAP                       March 2026


         9.1.1.  Top-Level Structure . . . . . . . . . . . . . . . . .   9
         9.1.2.  lah-bundle Fields . . . . . . . . . . . . . . . . . .  10
         9.1.3.  geolocation-payload Variants  . . . . . . . . . . . .  12
         9.1.4.  mno-endorsement (Optional, Top-Level Sibling) . . . .  13
         9.1.5.  workload (Top-Level Sibling)  . . . . . . . . . . . .  13
         9.1.6.  Sensor Type Input Recipes (Opaque to Verifier)  . . .  14
         9.1.7.  TPM Quote Verification Procedure  . . . . . . . . . .  14
         9.1.8.  Example Instance (privacy-technique = "zkp")  . . . .  14
         9.1.9.  Nonce Chain and Merkle Audit Log  . . . . . . . . . .  15
       9.2.  Scalable Fleet Management . . . . . . . . . . . . . . . .  16
       9.3.  Key Registry and Synchronization  . . . . . . . . . . . .  16
       9.4.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  16
         9.4.1.  Example Rotation Proof (Informative)  . . . . . . . .  16
       9.5.  Credential Activation and Re-Verification . . . . . . . .  16
       9.6.  Revocation and Health Signals . . . . . . . . . . . . . .  17
       9.7.  Disconnected Operation (Leased Identity)  . . . . . . . .  17
       9.8.  Deployment Patterns (Informative) . . . . . . . . . . . .  17
     10. Operational Considerations  . . . . . . . . . . . . . . . . .  18
       10.1.  Distributed Identity Issuance and Scaling  . . . . . . .  18
       10.2.  Mobility and Sovereign Handover (Informative)  . . . . .  18
       10.3.  Location Anchor Hosts (Informative)  . . . . . . . . . .  19
     11. Policy Use (Informative)  . . . . . . . . . . . . . . . . . .  19
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  19
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     14. Appendix: Open Issues . . . . . . . . . . . . . . . . . . . .  20
       14.1.  IMA Restart Behavior . . . . . . . . . . . . . . . . . .  20
       14.2.  Location Privacy Options . . . . . . . . . . . . . . . .  21
       14.3.  Proximity Profiles . . . . . . . . . . . . . . . . . . .  21
       14.4.  Geotagging Textual Data  . . . . . . . . . . . . . . . .  21
       14.5.  Attesting Geotags  . . . . . . . . . . . . . . . . . . .  21
     15. Appendix: Public References for Strict Data Residency
             Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     The *Workload Identity Agent* (e.g., SPIRE Agent) acts as the local-
     on-host intermediary responsible for managing and issuing identities
     to workloads.  It serves as a vetting mechanism, ensuring that a
     workload's execution environment meets required security and
     residency policies before granting it the cryptographic credentials
     necessary for network communication.  This High-Assurance Profile (a
     specialized RATS Profile) provides the technical mechanics to
     cryptographically bind this agent to the underlying hardware-verified
     platform and its privacy-preserving physical location.






  Krishnan, et al.        Expires 2 September 2026                [Page 3]


  Internet-Draft                    V-GAP                       March 2026


     The architecture follows the RATS Architecture [[RFC9334]], defining
     the interactions between Provers, Verifiers, and Relying Parties to
     generate and validate high-confidence evidence regarding the Workload
     Identity Agent's status.  It provides the hardware-rooted evidence
     layer required by the WIMSE Architecture [[I-D.ietf-wimse-
     architecture]], establishing a "Silicon-to-Workload" chain of trust
     that ensures sensitive data is only processed by authorized workloads
     in approved, measured environments.

     To maintain location privacy while providing cryptographic
     verifiability, this profile leverages Transparent Zero-Knowledge
     Proofs (ZKPs).  Unlike traditional ZKP systems, transparent ZKPs
     require no trusted third party or complex trusted setup phase.  They
     achieve mathematical transparency through non-interactive, hash-based
     protocols, allowing a platform to prove it is resident within an
     approved geographic boundary without disclosing the exact coordinates
     of the underlying hardware.

  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.

  2.1.  Abbreviations

     *  *AK*: Attestation Key
     *  *BMC*: Baseboard Management Controller
     *  *DAA*: Direct Anonymous Attestation
     *  *EAT*: Entity Attestation Token
     *  *EK*: Endorsement Key
     *  *GNSS*: Global Navigation Satellite System
     *  *IMA*: Integrity Measurement Architecture
     *  *IMEI*: International Mobile Equipment Identity
     *  *IMSI*: International Mobile Subscriber Identity
     *  *LAH*: Location Anchor Host
     *  *OOB*: Out-of-Band
     *  *PCR*: Platform Configuration Register
     *  *PoR*: Proof of Residency
     *  *SPDM*: Security Protocol and Data Model
     *  *STARK*: Scalable Transparent ARgument of Knowledge
     *  *SVID*: SPIFFE Verifiable Identity Document
     *  *TEE*: Trusted Execution Environment
     *  *TPM*: Trusted Platform Module
     *  *V-GAP*: Verifiable Geofencing Attestation Profile
     *  *ZKP*: Zero-Knowledge Proof



  Krishnan, et al.        Expires 2 September 2026                [Page 4]


  Internet-Draft                    V-GAP                       March 2026


  3.  Key Terms

     Data Residency:  Requirement that data processing and storage remain
        within an approved geographic boundary.
     Geofencing:  Enforcement that workloads execute only on approved
        hosts within an approved geographic boundary.
     Workload Identity Agent:  On-host component that issues workload
        identities (for example, SVIDs) to local workloads, subject to
        verifier-approved evidence.
     Location Anchor Host (LAH):  Trusted host or device that produces
        location evidence used to establish residency within a geofence.
     Workload Host:  Physical or virtual machine running the Workload
        Identity Agent and workloads; produces platform evidence.  Unless
        otherwise stated, this document assumes the unified deployment
        model in which the Workload Host and the Location Anchor Host
        (LAH) are the same machine.
     Composite Geolocation:  Location estimate fused from multiple sources
        and accompanied by a quality indicator.
     Proof of Residency (PoR) / Co-location:  Evidence that binds a
        workload (or Workload Host) to an approved local environment and
        geofence for a specific attestation interval.
     Silicon Root of Trust:  Hardware trust anchor that supports measured
        boot and protects attestation keys.
     Transparent Zero-Knowledge Proof:  ZKP that does not require a
        trusted setup; used to prove "inside an approved zone" without
        revealing precise coordinates.
     Workload Identity Management Plane:  Issues and validates workload
        identities and trust bundles based on verifier results and policy.
     Host Identity Management Plane:  Verifies platform integrity and
        residency evidence, and manages attestation key registration and
        platform health state (often via OOB paths).
     V-GAP (Verifiable Geofencing Attestation Profile):  Nested evidence
        format defined in this document for binding identity to verified
        platform integrity and verified residency.
     N_fusion (Workload Fusion Nonce):  Fresh nonce used to bind identity
        issuance to a specific attestation interval, delivered by the
        Workload Identity Management Plane.  Corresponds to the nonce
        field in the lah-bundle.

  4.  Use Cases

     This profile supports attested data residency and geofencing for
     workloads and (optionally) users.  Common use cases fall into:
     server-centric enforcement, user-centric enforcement, and compliance
     and risk reduction.






  Krishnan, et al.        Expires 2 September 2026                [Page 5]


  Internet-Draft                    V-GAP                       March 2026


  4.1.  Server-centric Enforcement

     Enterprises need cryptographic proof that workloads run only on
     approved hosts within an approved geographic boundary, and that data
     flows only between approved boundaries.

     *  *Workload-to-workload (general):* Relying parties accept workload
        identities only when the issuing host attests platform integrity
        and "in-zone" residency, preventing credentials from being used
        outside the approved boundary.

     *  *Agentic AI workloads:* An AI agent may access sensitive data or
        perform sensitive actions only when its Workload Identity Agent
        presents hardware-rooted integrity evidence and a verifiable "in-
        zone" proof (optionally privacy-preserving), binding identity to
        both platform state and residency.

     *  *Federated / edge AI (key or model release):* High-value artifacts
        (e.g., decryption keys or model weights in federated learning) are
        released only when the partner/edge host attests it is integral
        and resident within the required boundary.  This is useful for
        intermittently connected sites.

     *  *User-to-server:* Clients validate that the server endpoint is
        operating within an approved boundary (e.g., by policy tied to the
        server's attested identity and residency evidence).

  4.2.  User-centric Enforcement

     Enterprises may also need trustworthy location signals for user-
     facing access decisions.

     *  *Geofenced access control:* User access is permitted only when the
        user (or user device) proves it is within an allowed boundary,
        ideally without requiring precise location disclosure.

     *  *On-premises boundaries:* Customer-premises equipment can define
        an enterprise boundary, with a network or enterprise
        infrastructure providing supporting evidence for policy
        enforcement.

     *  *Restricted support geographies:* Administrative or support
        actions can be allowed only when the operator proves presence
        within allowed geographies, reducing policy and insider-risk
        exposure.






  Krishnan, et al.        Expires 2 September 2026                [Page 6]


  Internet-Draft                    V-GAP                       March 2026


  4.3.  Compliance and Risk Reduction

     Geofence attestation provides audit-ready evidence to support data
     residency and sovereignty controls, and it can also reduce non-
     compliance risk from misconfiguration or spoofable signals.  Even
     when not mandated, "in-zone" proofs help address: configuration
     drift, edge relocation/proxying, contractual residency requirements,
     and location-privacy minimization (proving "inside the zone" without
     storing coordinates).

  5.  Motivation and Gaps

     Operators need to enforce _where_ sensitive workloads run without
     relying on signals that are easy to spoof (IP geolocation, region
     labels) or credentials that are easy to steal (bearer tokens).  In
     many systems today, platform integrity and residency are inferred
     from configuration and control-plane metadata rather than verified
     with cryptographic evidence.

     Key gaps include:

     *  *Unverifiable location metadata (data-at-rest / data-generation):*
        Location tags for arbitrary data objects are not standardized and
        are typically unsigned, making provenance and integrity difficult
        to validate.
     *  *Token theft and replay (data-in-use):* Bearer tokens can be
        copied and replayed from unauthorized hosts or locations; stronger
        mechanisms exist but are not consistently deployed and can add
        operational overhead.
     *  *Implicit trust in “region” and transit:* A relying party often
        cannot cryptographically verify a server’s physical residency, and
        requests may traverse intermediaries (e.g., proxies) that expand
        the effective trust boundary.

  6.  What This Profile Provides

     This document defines a High-Assurance Profile (a specialized RATS
     profile) that makes *platform integrity* and *geofence residency*
     verifiable inputs to authorization and credential issuance, while
     supporting privacy-preserving “in-zone” proofs where available.

     At a high level, the profile enables a relying party (or identity
     issuer) to require evidence that: 1. the Workload Identity Agent is
     running on an approved, measured platform; and 2. that platform is
     resident within an approved geographic boundary (optionally without
     revealing coordinates).





  Krishnan, et al.        Expires 2 September 2026                [Page 7]


  Internet-Draft                    V-GAP                       March 2026


  7.  Composition with Transitive Attestation and WIMSE

     This profile is designed to compose with [[I-D.mw-wimse-transitive-
     attestation]] and the *WIMSE Architecture* [[I-D.ietf-wimse-
     architecture]].

     *  *[I-D.mw-wimse-transitive-attestation] (Layer 1):* Binds a
        workload to a _local_ Workload Identity Agent (co-location / PoR),
        treating the agent as a trust anchor.
     *  *This document (Layers 2 and 3):* Defines how that Workload
        Identity Agent is itself verified:
        -  *Layer 2 — Platform integrity:* Hardware-rooted evidence of the
           host state (e.g., TPM-based attestation).
        -  *Layer 3 — Residency:* Cryptographically verifiable proof the
           attested host is inside an approved boundary (optionally
           privacy-preserving).

     +======+=========================================+==================+
     |Layer | Document                                | Responsibility   |
     +======+=========================================+==================+
     |*Layer| [[I-D.mw-wimse-transitive-attestation]] | Bind workload    |
     |1*    |                                         | to a local       |
     |      |                                         | Workload         |
     |      |                                         | Identity Agent   |
     |      |                                         | (co-location /   |
     |      |                                         | PoR).            |
     +------+-----------------------------------------+------------------+
     |*Layer| This document                           | Verify Workload  |
     |2*    |                                         | Host integrity   |
     |      |                                         | for the          |
     |      |                                         | Workload         |
     |      |                                         | Identity Agent   |
     |      |                                         | (platform        |
     |      |                                         | evidence).       |
     +------+-----------------------------------------+------------------+
     |*Layer| This document                           | Verify Workload  |
     |3*    |                                         | Host residency   |
     |      |                                         | within an        |
     |      |                                         | approved         |
     |      |                                         | boundary         |
     |      |                                         | (location        |
     |      |                                         | evidence).       |
     +------+-----------------------------------------+------------------+

                                    Table 1






  Krishnan, et al.        Expires 2 September 2026                [Page 8]


  Internet-Draft                    V-GAP                       March 2026


  8.  Operational Use: Gating Credentials on Verified Evidence

     This profile assumes two cooperating control planes:

     *  *Host Identity Management Plane:* Verifies platform integrity and
        residency evidence and produces an attestation result.
     *  *Workload Identity Management Plane:* Issues or renews workload
        identities (e.g., SVIDs) only when the attestation result
        satisfies policy.

     To prevent mix-and-match and replay, attestation results SHOULD be
     fresh and SHOULD be bound to the identity issuance event (e.g., by
     cryptographically binding freshness values used for platform quotes
     and workload credential issuance within the verifier result).

     Where policy requires it, the verifier can additionally require that
     an agent software measurement (e.g., image digest) is covered by
     validated platform evidence, reducing the risk that a modified or
     unauthorized agent obtains credentials.

     In intermittently connected edge deployments, local operation can
     continue during outages, while centralized policy can be enforced on
     renewal and on release of high-value secrets once connectivity is
     available.

  9.  High-Assurance Profile: Verifiable Geofencing Attestation Profile
      (V-GAP)

     V-GAP is a RATS/WIMSE attestation profile that binds a *Workload
     Identity Agent* to (1) hardware-rooted host integrity and (2)
     verified residency within a configured geofence.  It does this with
     an evidence bundle from a *Location Anchor Host (LAH)*.

  9.1.  LAH-Bundle: Location Anchor Host Evidence Structure

     The lah-bundle is a hardware-sealed evidence structure embedded as an
     X.509 extension (OID 1.3.6.1.4.1.55744.1.1) in a SPIRE SVID.  It
     binds a workload identity to physically verifiable claims — TPM
     hardware identity, privacy-preserving geolocation, and agent binary
     integrity — without exposing PII.

  9.1.1.  Top-Level Structure

     {
       "lah-bundle": { },
       "mno-endorsement": { },
       "workload": { }
     }



  Krishnan, et al.        Expires 2 September 2026                [Page 9]


  Internet-Draft                    V-GAP                       March 2026


  9.1.2.  lah-bundle Fields

      +==============+=============+==========+=========================+
      | Field        | Type        | Required | Description             |
      +==============+=============+==========+=========================+
      | tpm-ak       | string      |   Yes    | TPM Attestation Key     |
      |              | (Base64URL) |          | public key (PEM-        |
      |              |             |          | encoded).  Hardware     |
      |              |             |          | identity anchor.  The   |
      |              |             |          | TPM enforces that only  |
      |              |             |          | this key can produce    |
      |              |             |          | tpm-quote-seal —        |
      |              |             |          | proving co-residency.   |
      +--------------+-------------+----------+-------------------------+
      | geolocation- | string      |   Yes    | SHA-256(tpm-ak-bytes).  |
      | id-hash      | (Base64URL) |          | Binds TPM identity to   |
      |              |             |          | sensor identity -       |
      |              |             |          | assumption is sensor    |
      |              |             |          | integrity is handled by |
      |              |             |          | OOB host management     |
      |              |             |          | plane                   |
      +--------------+-------------+----------+-------------------------+
      | geolocation- | string      |   Yes    | SHA-256 commitment over |
      | proof-hash   | (Base64URL) |          | geolocation-payload.    |
      |              |             |          | Required in both        |
      |              |             |          | privacy modes.  When    |
      |              |             |          | privacy-technique=zkp:  |
      |              |             |          | SHA-256(zkp-proof-      |
      |              |             |          | bytes).  When privacy-  |
      |              |             |          | technique=none: SHA-    |
      |              |             |          | 256(JCS({lat, lon,      |
      |              |             |          | accuracy})).            |
      +--------------+-------------+----------+-------------------------+
      | privacy-     | string enum |   Yes    | "none" = raw lat/lon/   |
      | technique    |             |          | accuracy in payload.    |
      |              |             |          | "zkp" = zero-knowledge  |
      |              |             |          | proof URI in payload.   |
      |              |             |          | Controls location       |
      |              |             |          | privacy only; device    |
      |              |             |          | identity privacy is     |
      |              |             |          | always protected via    |
      |              |             |          | geolocation-id-hash.    |
      +--------------+-------------+----------+-------------------------+
      | geolocation- | object      |   Yes    | Inner location data.    |
      | payload      |             |          | Structure depends on    |
      |              |             |          | privacy-technique (see  |
      |              |             |          | Payload Variants        |
      |              |             |          | below).  Committed to   |



  Krishnan, et al.        Expires 2 September 2026               [Page 10]


  Internet-Draft                    V-GAP                       March 2026


      |              |             |          | by geolocation-proof-   |
      |              |             |          | hash and optionally     |
      |              |             |          | signed by mno-          |
      |              |             |          | endorsement.mno-sig.    |
      +--------------+-------------+----------+-------------------------+
      | nonce        | string      |   Yes    | N_fusion freshness      |
      |              | (Base64URL) |          | nonce issued by the     |
      |              |             |          | Workload Identity       |
      |              |             |          | Management Plane.       |
      |              |             |          | Chained: HMAC(secret, n |
      |              |             |          | \|\| chain[n-1]).       |
      |              |             |          | Detects skipped/        |
      |              |             |          | reordered attestations. |
      +--------------+-------------+----------+-------------------------+
      | timestamp    | integer     |   Yes    | Unix epoch seconds.     |
      |              | (int64)     |          | Set by the LAH agent at |
      |              |             |          | bundle construction     |
      |              |             |          | time.                   |
      +--------------+-------------+----------+-------------------------+
      | tpm-quote-   | string      |   Yes    | TPM2_Quote produced by  |
      | seal         | (Base64URL) |          | the AK in tpm-ak.       |
      |              |             |          | Qualifying data = SHA-  |
      |              |             |          | 256(JCS({tpm-ak,        |
      |              |             |          | geolocation-id-hash,    |
      |              |             |          | geolocation-proof-hash, |
      |              |             |          | privacy-technique,      |
      |              |             |          | nonce, timestamp,       |
      |              |             |          | workload-identity-      |
      |              |             |          | agent-image-digest})).  |
      |              |             |          | Binds all fields into a |
      |              |             |          | single hardware-sealed  |
      |              |             |          | statement.              |
      +--------------+-------------+----------+-------------------------+
      | workload-    | string (hex |   Yes    | SHA-256 digest of the   |
      | identity-    | SHA-256)    |          | Workload Identity Agent |
      | agent-image- |             |          | (SPIRE agent) binary,   |
      | digest       |             |          | measured at attestation |
      |              |             |          | time by the Host        |
      |              |             |          | Identity Manager        |
      |              |             |          | (Keylime).  Detects     |
      |              |             |          | agent binary compromise |
      |              |             |          | on every renewal cycle. |
      +--------------+-------------+----------+-------------------------+

                                    Table 2






  Krishnan, et al.        Expires 2 September 2026               [Page 11]


  Internet-Draft                    V-GAP                       March 2026


  9.1.3.  geolocation-payload Variants

     *When privacy-technique = "none" (raw coordinates):*

        +==========+==================+==========+===================+
        | Field    | Type             | Required | Description       |
        +==========+==================+==========+===================+
        | lat      | number (float64) |   Yes    | Latitude, WGS-84  |
        |          |                  |          | decimal degrees   |
        +----------+------------------+----------+-------------------+
        | lon      | number (float64) |   Yes    | Longitude, WGS-84 |
        |          |                  |          | decimal degrees   |
        +----------+------------------+----------+-------------------+
        | accuracy | number (float64) |   Yes    | Accuracy radius   |
        |          |                  |          | in meters         |
        +----------+------------------+----------+-------------------+

                                   Table 3

     geolocation-proof-hash = Base64URL(SHA-256(JCS({lat, lon,
     accuracy})))

     *When privacy-technique = "zkp" (zero-knowledge proof):*

     +===============+========+==========+==============================+
     | Field         | Type   | Required | Description                  |
     +===============+========+==========+==============================+
     | zkp-proof-uri | string |   Yes    | URI to fetch full ZKP proof  |
     |               | (URI)  |          | bytes from the proof         |
     |               |        |          | depository.  Verifier        |
     |               |        |          | fetches bytes, computes SHA- |
     |               |        |          | 256(bytes), checks against   |
     |               |        |          | geolocation-proof-hash.      |
     +---------------+--------+----------+------------------------------+
     | zkp-format    | string |   Yes    | ZKP proof system.            |
     |               | enum   |          | Currently: "plonky2".        |
     +---------------+--------+----------+------------------------------+

                                   Table 4

     geolocation-proof-hash = Base64URL(SHA-256(zkp-proof-bytes))










  Krishnan, et al.        Expires 2 September 2026               [Page 12]


  Internet-Draft                    V-GAP                       March 2026


  9.1.4.  mno-endorsement (Optional, Top-Level Sibling)

     +==============+=============+==========+==========================+
     | Field        | Type        | Required | Description              |
     +==============+=============+==========+==========================+
     | mno-key-cert | string      |   Yes    | MNO signing certificate. |
     |              | (Base64URL  |          | Verifiers SHOULD         |
     |              | DER)        |          | validate this            |
     |              |             |          | certificate chains to a  |
     |              |             |          | known MNO root before    |
     |              |             |          | accepting the            |
     |              |             |          | endorsement.             |
     +--------------+-------------+----------+--------------------------+
     | mno-sig      | string      |   Yes    | ECDSA/EdDSA signature    |
     |              | (Base64URL) |          | over JCS(geolocation-    |
     |              |             |          | payload) only.  The MNO  |
     |              |             |          | attests location within  |
     |              |             |          | carrier visibility —     |
     |              |             |          | does not sign host       |
     |              |             |          | fields (tpm-ak, nonce,   |
     |              |             |          | tpm-quote-seal).         |
     +--------------+-------------+----------+--------------------------+

                                   Table 5

  9.1.5.  workload (Top-Level Sibling)

      +=============+=========+==========+==============================+
      | Field       | Type    | Required | Description                  |
      +=============+=========+==========+==============================+
      | workload-id | string  |   Yes    | The workload's SPIFFE        |
      |             | (SPIFFE |          | identity URI (e.g.,          |
      |             | ID)     |          | spiffe://example.org/python- |
      |             |         |          | app).                        |
      +-------------+---------+----------+------------------------------+
      | key-source  | string  |   Yes    | Origin of the workload's key |
      |             |         |          | material (e.g., "tpm-app-    |
      |             |         |          | key").  The value is         |
      |             |         |          | implementer-defined;         |
      |             |         |          | verifiers SHOULD treat       |
      |             |         |          | unrecognized values as       |
      |             |         |          | opaque strings unless policy |
      |             |         |          | requires specific values.    |
      +-------------+---------+----------+------------------------------+

                                    Table 6





  Krishnan, et al.        Expires 2 September 2026               [Page 13]


  Internet-Draft                    V-GAP                       March 2026


  9.1.6.  Sensor Type Input Recipes (Opaque to Verifier)

        +=================+==========================================+
        | Sensor Type     | geolocation-id-hash Input                |
        +=================+==========================================+
        | Mobile (CAMARA) | SHA-256(tpm-ak-bytes \|\| IMEI-bytes     |
        |                 | \|\| IMSI-bytes)                         |
        +-----------------+------------------------------------------+
        | GNSS receiver   | SHA-256(tpm-ak-bytes \|\| sensor-serial- |
        |                 | bytes \|\| sensor-class-id-bytes)        |
        +-----------------+------------------------------------------+

                                   Table 7

     The verifier sees only the opaque hash — never the raw identifiers.

  9.1.7.  TPM Quote Verification Procedure

     1.  Decode tpm-quote-seal (Base64URL → bytes)
     2.  Parse TPMS_ATTEST structure
     3.  Assert TPMS_ATTEST.type == TPM_ST_ATTEST_QUOTE
     4.  Compute expected_qd = SHA-256(JCS({tpm-ak, geolocation-id-hash,
         geolocation-proof-hash, privacy-technique, nonce, timestamp,
         workload-identity-agent-image-digest}))
     5.  Assert TPMS_ATTEST.qualifyingData == expected_qd
     6.  Verify signature over TPMS_ATTEST bytes using tpm-ak public key
         (RSASSA-PKCS1-v1_5 or ECDSA)

  9.1.8.  Example Instance (privacy-technique = "zkp")






















  Krishnan, et al.        Expires 2 September 2026               [Page 14]


  Internet-Draft                    V-GAP                       March 2026


     {
       "lah-bundle": {
         "tpm-ak": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG...\n-----END PUBLIC KEY-----",
         "geolocation-id-hash": "7f4a2c1b9e3d8f0a6b5c4d2e1f0a9b8c...",
         "geolocation-proof-hash": "c8bc2ed62a7a650d99e0884197cdf345...",
         "privacy-technique": "zkp",
         "geolocation-payload": {
           "zkp-proof-uri": "https://verifier.example/v1/proof/c8bc2ed6...",
           "zkp-format": "plonky2"
         },
         "nonce": "ZmUyZjdmMzlmZGVlZWQxOTM1YjY0Mjk0...",
         "timestamp": 1740693456,
         "tpm-quote-seal": "ARoAAQALAAUACwEA...",
         "workload-identity-agent-image-digest": "a1b2c3d4e5f6...64-char-hex-sha256"
       },
       "mno-endorsement": {
         "mno-key-cert": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
         "mno-sig": "MEYCIQDx9z2k..."
       },
       "workload": {
         "workload-id": "spiffe://example.org/python-app",
         "key-source": "tpm-app-key"
       }
     }

  9.1.9.  Nonce Chain and Merkle Audit Log

     Where bundle[n] denotes the JCS-canonicalized lah-bundle object at
     attestation interval n:

     chain[n] = SHA-256(chain[n-1] || SHA-256(JCS(bundle[n])))
     nonce[n]  = HMAC(secret, n || chain[n-1])

      +===========+=====================================================+
      | Mechanism | Role                                                |
      +===========+=====================================================+
      | Chained   | Input control — agent cannot submit without         |
      | nonce     | responding to the management plane's current state. |
      +-----------+-----------------------------------------------------+
      | Merkle    | Audit output — proves inclusion of past bundles,    |
      | chain     | detects gaps, and enables regulatory audit.         |
      +-----------+-----------------------------------------------------+

                                    Table 8







  Krishnan, et al.        Expires 2 September 2026               [Page 15]


  Internet-Draft                    V-GAP                       March 2026


  9.2.  Scalable Fleet Management

     Large deployments need lifecycle management for the attestation keys
     referenced by V-GAP (for example, tpm-ak) and for the policies that
     authorize them.

  9.3.  Key Registry and Synchronization

     *  A Cloud (central) Host Identity Management Plane maintains a
        registry of accepted AK public keys and associated metadata (e.g.,
        EK certificate chain, hardware identity, and status).
     *  An Edge Host Identity Management Plane MAY maintain a local
        registry to support disconnected operation and periodically
        synchronizes updates to the central registry.

  9.4.  Key Rotation

     To prevent rogue key injection during rotation:

     *  The central registry MUST accept a new AK only if the edge plane
        provides a rotation proof that chains the new AK to previously
        accepted state.
     *  A rotation proof MUST be a JCS-canonicalized object signed by the
        previously accepted AK (or, if available, validated by a fresh
        hardware-rooted OOB quote).

  9.4.1.  Example Rotation Proof (Informative)

     {
      "new-ak-pub": "Base64URL_Encoded_Public_Key",
      "serial-number": "AK_Serial_XYZ",
      "timestamp": 1708845600,
      "hardware-uuid": "Host_Hardware_UUID",
      "signature": "Base64URL_Signature_from_Previous_AK"
     }

  9.5.  Credential Activation and Re-Verification

     Credential activation (e.g., TPM2_MakeCredential) is expensive to run
     on every request.  Verifiers SHOULD perform it on events such as:

     *  Initial onboarding
     *  Reboot / reset detection (e.g., TPM clock/reset counters)
     *  Policy violations or drift signals (e.g., firmware or inventory
        changes)
     *  Failure of location evidence checks
     *  Explicit elevation to higher assurance policy




  Krishnan, et al.        Expires 2 September 2026               [Page 16]


  Internet-Draft                    V-GAP                       March 2026


     Between full activations, verifiers MAY accept fresh quotes from
     registered AKs as proof of continued compliance, subject to policy.

  9.6.  Revocation and Health Signals

     *  The edge plane SHOULD maintain a per-node health signal (e.g.,
        tamper, firmware policy violations).
     *  On severe health signals, the verifier MUST revoke the relevant
        AK(s) and reject identities derived from them according to policy.

  9.7.  Disconnected Operation (Leased Identity)

     For intermittent connectivity, the verifier MAY issue identities with
     extended validity (a lease) under policy.  If a lease is used:

     *  The edge plane MUST revoke or refuse renewal locally on tamper/
        drift signals.
     *  The workload MUST re-attest and satisfy current policy on
        reconnection before renewal or release of high-value secrets.

  9.8.  Deployment Patterns (Informative)

     Implementations commonly fall into the following patterns, differing
     in how platform integrity evidence and the tpm-quote-seal are
     collected:

     *  *In-band host attestation*: Evidence collected by host software
        (for example, Keylime-style deployments).  In this pattern, the
        Workload Identity Management Plane (for example, SPIRE Server)
        generates N_fusion and shares it with the Host Identity Management
        Plane (for example, the Keylime Verifier) over a server-to-server
        channel.  The Keylime Verifier then delivers N_fusion to the
        Keylime Agent running on the host, which collects TPM and
        geolocation evidence, assembles the lah-bundle, and returns it via
        the host-side channel.  This pattern is well-suited to commodity
        servers and cloud VMs where a BMC path is not available or not
        required.














  Krishnan, et al.        Expires 2 September 2026               [Page 17]


  Internet-Draft                    V-GAP                       March 2026


     *  *Out-of-band management*: Evidence collected via a management
        controller / BMC path (for example, iLO-class OOB management such
        as HPE OneView).  In this pattern, the Workload Identity
        Management Plane (for example, SPIRE Server) generates N_fusion
        and shares it with the Host Identity Management Plane (for
        example, HPE OneView) over a server-to-server channel.  The Host
        Identity Management Plane then delivers N_fusion to the host via
        the BMC / OOB path — bypassing the host OS entirely.  The host TPM
        seals the lah-bundle with that nonce, and the sealed bundle is
        returned via the same OOB path.  This pattern is recommended for
        high-assurance environments where the host OS is part of the
        threat model.

     *  *Cloud-hosted attestation environments*: Provider mechanisms
        exposing measured boot and TPM-backed claims (for example, Nitro-
        class enclaves or shielded VM instances).  The cloud provider
        supplies a hardware-rooted quote that can serve as the tpm-quote-
        seal; the geolocation claim is typically derived from the
        provider's zone or region attestation.  Implementations SHOULD
        verify that the provider's attestation scope satisfies the
        geofence policy.

  10.  Operational Considerations

  10.1.  Distributed Identity Issuance and Scaling

     To support edge deployments and intermittent connectivity, identity
     issuance may be distributed within a sovereign boundary.

     *  *Edge issuance*: Workload identities (for example, SVIDs) MAY be
        issued by an issuer deployed within the same boundary as the
        workloads.
     *  *Scoping*: Issued identities SHOULD be scoped so they are not
        accepted outside the intended deployment boundary (for example,
        via trust bundle partitioning and policy).
     *  *Renewal gating*: Issuers SHOULD renew short-lived identities only
        when the verifier result for integrity and residency is valid for
        the requested freshness window.

  10.2.  Mobility and Sovereign Handover (Informative)

     When a workload moves between anchors or boundaries, the Workload
     Identity Agent MUST obtain a new V-GAP bundle that reflects the new
     LAH and current residency.

     Verifiers SHOULD treat this as a normal re-attestation event: -
     platform integrity continuity can remain stable, but - residency
     checks MUST be re-evaluated for the new anchor/boundary.



  Krishnan, et al.        Expires 2 September 2026               [Page 18]


  Internet-Draft                    V-GAP                       March 2026


  10.3.  Location Anchor Hosts (Informative)

     To scale location sensing, a deployment may use dedicated anchors:

     *  *End-user anchors*: A user device (for example, a phone) can serve
        as an LAH for a nearby client device.  The mechanism by which the
        anchor establishes its own location (and any proximity evidence it
        may provide) is out of scope for this document.
     *  *Data center anchors*: A small set of hosts can act as LAHs for a
        cluster.  Timing-based mechanisms (for example, PTP-derived) may
        assist in establishing relative location; protocol details are
        deferred to future profiling work (see [[I-D.ramki-ptp-hardware-
        rooted-attestation]]).

  11.  Policy Use (Informative)

     Relying parties and identity issuers can use V-GAP results as inputs
     to authorization.

     *  *ABAC*: Residency and integrity can be mandatory claims for
        sensitive operations.
     *  *KMS gatekeeping*: Release of high-value assets (for example,
        decryption keys) SHOULD depend on a recent successful verification
        result.
     *  *Fail closed*: If V-GAP evidence is carried in an X.509 extension
        and marked CRITICAL, any implementation that does not understand
        the extension will reject the credential.

  12.  Security Considerations

     V-GAP reduces reliance on spoofable location signals and stolen
     tokens by making integrity and residency cryptographically
     verifiable.  Implementers still need to address the following
     threats:

     *  *Replay and mix-and-match*: Use nonces and evidence stapling so
        that old location evidence cannot be combined with a fresh
        platform quote (or vice versa).
     *  *Location spoofing*: Treat sensor and network inputs as
        adversarial.  Prefer multiple, corroborating sources where
        feasible, and apply conservative policy when evidence quality
        degrades.
     *  *Relay and displacement*: When proximity mechanisms are introduced
        in future profiles, implementers should be aware that they are
        vulnerable to relay attacks and anchor displacement.  Mitigations
        (such as tight RTT-based acceptance windows and anchor health
        attestation) are deferred to those future profiles.




  Krishnan, et al.        Expires 2 September 2026               [Page 19]


  Internet-Draft                    V-GAP                       March 2026


     *  *Management plane compromise*: OOB paths reduce dependence on the
        host OS but introduce dependence on the management controller and
        its network.  Protect this plane with secure boot, authenticated
        updates, strong access controls, network segmentation, and audit
        logging.
     *  *Time and freshness*: Verifiers MUST enforce bounded freshness
        windows and MUST define recovery behavior (re-attestation,
        quarantine, or revocation) when clocks drift or evidence becomes
        stale.
     *  *Registry and allowlist integrity*: Protect key registries and
        policy stores against tampering; treat them as high-value
        privileged assets.
     *  *Privacy*: Avoid unnecessary collection or retention of precise
        location data.  Prefer "in-zone" proofs (ZKP) where policy
        permits.

  13.  IANA Considerations

     IANA is requested to register the following Object Identifier (OID)
     in the "SMI Numbers" registry under the "SMI Private Enterprise
     Numbers" (1.3.6.1.4.1) branch, or as appropriate for the V-GAP
     profile.

     *Mandatory Criticality:* Implementations of this profile MUST mark
     the X.509 extension containing the V-GAP Evidence Bundle as
     *CRITICAL*. This ensures that non-compliant gateways fail closed
     rather than granting access to residency-constrained workloads.

     *  *OID*: 1.3.6.1.4.1.55744.1.1
     *  *Description*: Verifiable Geofencing Attestation Profile (V-GAP)
        Evidence Bundle
     *  *Reference*: This document.

  14.  Appendix: Open Issues

     The following items are unresolved and are tracked for future
     revisions of this document.

  14.1.  IMA Restart Behavior

     Define an interoperable way to detect and handle Workload Identity
     Agent restarts without requiring a full host reboot, while preserving
     measurement integrity.








  Krishnan, et al.        Expires 2 September 2026               [Page 20]


  Internet-Draft                    V-GAP                       March 2026


  14.2.  Location Privacy Options

     Clarify the complete set of supported privacy techniques and define
     the policy logic for selecting between precise location disclosure,
     coarse location, and ZKP-based "in-zone" proofs.

  14.3.  Proximity Profiles

     This document defers proximity proof mechanisms to future profiling
     work.  Open items include:

     *  Defining one or more proximity evidence profiles (for example,
        PTP-derived, BLE/UWB ranging, or network-RTT-based) as separate
        documents.
     *  Specifying how proximity evidence is represented and bound to the
        V-GAP bundle (for example, as an additional hash field).
     *  Addressing relay and displacement threats, including RTT-based
        acceptance windows, anchor health attestation, and disagreement
        policies for multi-anchor deployments.
     *  Profiling the use of CAMARA-style MNO location signals as a
        proximity corroboration mechanism.

  14.4.  Geotagging Textual Data

     There is no widely deployed standard for geotagging arbitrary textual
     data objects.

  14.5.  Attesting Geotags

     There is no widely deployed standard for cryptographically signing
     geotags to prevent manipulation.

  15.  Appendix: Public References for Strict Data Residency Rules

     India -- Reserve Bank of India (RBI): Payment System Data
     Localization (2018): From RBI Circular RBI/2017-18/153 (April 6,
     2018): "All system providers shall ensure that the entire data
     relating to payment systems operated by them are stored in a system
     only in India.  This data should include the full end-to-end
     transaction details / information collected / carried / processed as
     part of the message / payment instruction."

     South Korea's Data Localization Regulations -- Geospatial Information
     Management Act (Spatial Data Act): Article 16, Paragraph 1: Prohibits
     the export of state-led survey data.

  Authors' Addresses




  Krishnan, et al.        Expires 2 September 2026               [Page 21]


  Internet-Draft                    V-GAP                       March 2026


     Ram Krishnan
     JPMorgan Chase & Co.
     Email: ramkri123@gmail.com


     Ned Smith
     Intel
     Email: ned.smith@intel.com


     Diego R. Lopez
     Telefonica
     Email: diego.r.lopez@telefonica.com


     A Prasad
     Oracle
     Email: a.prasad@oracle.com


     Srinivasa Addepalli
     Aryaka
     Email: srinivasa.addepalli@aryaka.com




























  Krishnan, et al.        Expires 2 September 2026               [Page 22]


name: draft-allman-tcp-early-rexmt
rev: 07
title: Early Retransmit for TCP and SCTP
time: 2024-12-18T18:43:40Z
group_uri: /api/v1/group/group/1324/
expires: 2008-12-28T01:45:36Z
ad: /api/v1/person/person/112773/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:11.565598+00:00
source: ietf
abstract:
  This document proposes a new mechanism for TCP and SCTP that can be
      used to recover lost segments when a connection's congestion window
      is small.  The "Early Retransmit" mechanism allows the transport to
      reduce, in certain special circumstances, the number of duplicate
      acknowledgments required to trigger a fast retransmission.  This
      allows the transport to use fast retransmit to recover packet losses
      that would otherwise require a lengthy retransmission timeout.

full_text:
  Internet Engineering Task Force                              Mark Allman 
  INTERNET DRAFT                                                      ICSI 
  File: draft-allman-tcp-early-rexmt-07.txt         Konstantin Avrachenkov
                                                                     INRIA
                                                              Urtzi Ayesta
                                                                 LAAS-CNRS
                                                              Josh Blanton
                                                           Ohio University
                                                                Per Hurtig
                                                       Karlstad University
                                                                 June 2008
                                                    Expires: December 2008


                     Early Retransmit for TCP and SCTP

  Status of this Memo

      By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of 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.

  Copyright Notice

      Copyright (C) The IETF Trust (2008).

  Abstract

      This document proposes a new mechanism for TCP and SCTP that can be
      used to recover lost segments when a connection's congestion window
      is small.  The "Early Retransmit" mechanism allows the transport to
      reduce, in certain special circumstances, the number of duplicate
      acknowledgments required to trigger a fast retransmission.  This
      allows the transport to use fast retransmit to recover packet losses
      that would otherwise require a lengthy retransmission timeout.

  Terminology


  Expires: December 2008                                          [Page 1]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119 [RFC2119].

  1   Introduction

      Many researchers have studied problems with TCP [RFC793,RFC2581]
      when the congestion window is small and have outlined possible
      mechanisms to mitigate these problems
      [Mor97,BPS+98,Bal98,LK98,RFC3150,AA02].  SCTP's [RFC4960] loss
      recovery and congestion control mechanisms are based on TCP and
      therefore the same problems impact the performance of SCTP
      connections.  When the transport detects a missing segment, the
      connection enters a loss recovery phase.  There are several variants
      of the loss recovery phase depending on a TCP's version.  TCP can
      use slow start based recovery or Fast Recovery [RFC2581], NewReno
      [RFC2582], and loss recovery based on selective acknowledgments
      (SACKs) [RFC2018,FF96,RFC3517].  SCTP's loss recovery is not as
      varied due to the built-in selective acknowledgments.

      All the above variants have two methods for invoking loss recovery.
      First, if an acknowledgment (ACK) for a given segment is not
      received in a certain amount of time a retransmission timer fires
      and the segment is resent [RFC2988,RFC4960].  Second, the ``Fast
      Retransmit'' algorithm resends a segment when three duplicate ACKs
      arrive at the sender [Jac88,RFC2581].  Duplicate ACKs are triggered
      by out-of-order arrivals at the receiver.  However, because
      duplicate ACKs from the receiver are triggered by both packet loss
      and packet reordering in the network path, the sender waits for
      three duplicate ACKs in an attempt to disambiguate packet loss from
      packet reordering.  When using small congestion windows it may not
      be possible to generate the required number of duplicate ACKs to
      trigger Fast Retransmit when a loss does happen.

      Small windows can occur in a number of situations, such as:

      (1) The connection is constrained by end-to-end congestion control
          when the connection's share of the path is small, the path has a
          small bandwidth-delay product or the transport is ascertaining
          the available bandwidth in the first few round-trip times of
          slow start.

      (2) The connection is "application limited" and has only a limited
          amount of data to send.  This can happen any time the
          application does not produce enough data to fill the congestion
          window.  A particular case when all connections become
          application limited is as the connection ends.

      (3) The connection is limited by the receiver's advertised window.

      The transport's retransmission timeout (RTO) is based on measured
      round-trip times (RTT) between the sender and receiver, as specified
      in [RFC2988] (for TCP) and [RFC4960] (for SCTP).  To prevent
      spurious retransmissions of segments that are only delayed and not

  Expires: December 2008                                          [Page 2]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      lost, the minimum RTO is conservatively chosen to be 1 second.  
      Therefore, it behooves TCP senders to detect and recover from as
      many losses as possible without incurring a lengthy timeout during
      which the connection remains idle.  However, if not enough duplicate
      ACKs arrive from the receiver, the Fast Retransmit algorithm is
      never triggered---this situation occurs when the congestion window
      is small, if a large number of segments in a window are lost or at
      the end of a transfer as data drains from the network.  For
      instance, consider a congestion window (cwnd) of three segments.  If
      one segment is dropped by the network, then at most two duplicate
      ACKs will arrive at the sender, assuming no ACK loss.  Since three
      duplicate ACKs are required to trigger Fast Retransmit, a timeout
      will be required to resend the dropped packet.

      [BPS+98] shows that roughly 56% of retransmissions sent by a busy
      web server are sent after the RTO timer expires, while only 44% are
      handled by Fast Retransmit.  In addition, only 4% of the RTO
      timer-based retransmissions could have been avoided with SACK, which
      has to continue to disambiguate reordering from genuine loss.
      Furthermore, [All00] shows that for one particular web server the
      median transfer size is less than four segments, indicating that
      more than half of the connections will be forced to rely on the RTO
      timer to recover from any losses that occur.  Thus, loss recovery
      that does not rely on the conservative RTO is likely to be
      beneficial for short TCP transfers.

      The Limited Transmit mechanism introduced in [RFC3042] allows a TCP
      sender to transmit previously unsent data upon the reception of each
      of the two duplicate ACKs that precede a Fast Retransmit.  SCTP
      [RFC4960] uses SACK information to calculate the number of
      outstanding segments in the network.  Hence, when the first two
      duplicate ACKs arrive at the sender they will indicate that data has
      left the network and allow the sender to transmit new data (if
      available) similar to TCP's Limited Transmit algorithm.  In the
      remainder of this document we use "Limited Transmit" to include both
      TCP and SCTP mechanisms for sending in response to the first two
      duplicate ACKs.  By sending these two new segments the TCP sender is
      attempting to induce additional duplicate ACKs (if appropriate) so
      that Fast Retransmit will be triggered before the retransmission
      timeout expires.  The "Early Retransmit" mechanism outlined in this
      document covers the case when previously unsent data is not
      available for transmission or cannot be transmitted due to an
      advertised window limitation.

  2   Early Retransmit Algorithm

      The Early Retransmit algorithm calls for lowering the threshold for
      triggering Fast Retransmit when the amount of outstanding data is
      small and when no previously unsent data can be transmitted (such
      that Limited Transmit could be used).  Duplicate ACKs are triggered
      by each arriving out-of-order segment.  Therefore, Fast Retransmit
      will not be invoked when there are less than four outstanding
      segments (assuming only one segment loss in the window).  However,
      TCP and SCTP are not required to track the number of outstanding

  Expires: December 2008                                          [Page 3]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      segments, but rather the number of outstanding bytes or messages.
      Therefore, applying the intuitive notion of a transport with less
      than four segments outstanding is more complicated than it first
      appears.  In section 2.1 we describe a "byte-based" variant of Early
      Retransmit that attempts to roughly map the number of outstanding
      bytes to a number of outstanding packets that is then used when
      deciding whether to trigger Early Retransmit.  In section 2.2 we
      describe a "packet-based" variant that represents a more precise
      algorithm for triggering Early Retransmit.  The precision comes at
      the cost of requiring additional state to be kept by the TCP sender.
      In both cases we described SACK-based and non-SACK-based versions of
      the scheme (of course, the non-SACK version will not apply to SCTP).

  2.1 Byte-based Early Retransmit

      A TCP or SCTP sender MAY use byte-based Early Retransmit.  

      A sender employing byte-based Early Retransmit MUST use the
      following two conditions to determine when an Early Retransmit is
      sent:

      (2.a) The amount of outstanding data (ownd)---data sent but not yet
            acknowledged---is less than 4*SMSS bytes.
      
      (2.b) There is either no unsent data ready for transmission at the
            sender or the advertised window does not permit new segments
            to be transmitted.

      When the above two conditions hold and the connection does not
      support SACK the duplicate ACK threshold used to trigger a
      retransmission MUST be reduced to:

                    ER_thresh = ceiling (ownd/SMSS) - 1                 (1)

      duplicate ACKs, where ownd is in terms of bytes.

      When conditions (2.a) and (2.b) hold and the connection does support
      SACK, Early Retransmit MUST be used only when "ownd - SMSS" bytes
      have been SACKed.

      When conditions (2.a) and (2.b) do not hold, the transport MUST NOT
      use Early Retransmit, but rather prefer the standard mechanisms,
      including Limited Transmit.
      
      As noted above, the drawback of this byte-based variant is
      precision [HB07].  We illustrate this with two examples:

        + Consider a non-SACK TCP sender that uses an SMSS of 1460 bytes 
          and transmits three segments each with 400 bytes of payload.
          This is clearly a case where Early Retransmit could aid loss
          recovery if one segment is lost.  However, in this case
          ER_thresh will become zero, per equation (1), because the number
          of outstanding bytes is a poor estimate of the number of
          outstanding packets.  A similar problem occurs for senders that

  Expires: December 2008                                          [Page 4]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

          employ SACK as the expression "ownd - SMSS" will become
          negative.

        + Next, consider a non-SACK TCP sender that uses an SMSS of 1460
          bytes and transmits 10 segments each with 400 bytes of payload.
          In this case ER_thresh will be two, per equation (1).  Thus,
          even though there are enough segments outstanding to trigger
          Fast Retransmit with the standard duplicate ACK threshold Early
          Retransmit will be triggered.  This could cause or exacerbate
          performance problems caused by packet reordering in the network.

  2.2 Packet-based Early Retransmit

      A TCP or SCTP sender MAY use packet-based Early Retransmit.  

      A sender employing packet-based Early Retransmit MUST use the
      following two conditions to determine when an Early Retransmit is
      sent:

      (3.a) The number of outstanding segments (oseg)---segments sent but
            not yet acknowledged---is less than four.

      (3.b) There is either no unsent data ready for transmission at the
            sender or the advertised window does not permit new segments
            to be transmitted.

      When the above two conditions hold and the connection does not
      support SACK the duplicate ACK threshold used to trigger a
      retransmission MUST be reduced to:

                      ER_thresh = oseg - 1                              (2)

      duplicate ACKs, where oseg represents the number of outstanding
      segments.  (We discuss tracking the number of outstanding segments
      below.) 

      When conditions (3.a) and (3.b) hold and the connection does support
      SACK, Early Retransmit MUST be used only when "oseg - 1" segments
      have been SACKed.

      When conditions (3.a) and (3.b) do not hold, the transport MUST NOT
      use Early Retransmit, but rather prefer the standard mechanisms,
      including Limited Transmit.

      This version of Early Retransmit solves the precision issues
      discussed in the previous section.  As noted previously, the cost is
      that the implementation will have to track packet boundaries to form
      an understanding as to how many actual segments have been
      transmitted, but not acknowledged.  This can be done by tracking the
      boundaries of the three segments on the right side of the current
      window (which involves tracking four sequence numbers in TCP).  This
      could be done by keeping a circular list of the packet boundaries,
      for instance.  Cumulative ACKs that do not fall within this region
      indicate that at least four segments are outstanding and therefore

  Expires: December 2008                                          [Page 5]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      Early Retransmit MUST NOT be used.  When the outstanding window
      becomes small enough that Early Retransmit can be invoked, a full
      understanding of the number of outstanding packets will be
      available. 

  3   Discussion

      The SACK variant of the Early Retransmit algorithm is preferred to
      the non-SACK variant due to its robustness in the face of ACK loss
      (since SACKs are sent redundantly) and due to interactions with the
      delayed ACK timer.  Consider a flight of three segments, S1...S3,
      with S2 being dropped by the network.  When S1 arrives it is
      in-order and so the receiver may or may not delay the ACK, leading
      to two scenarios:

      (A) The ACK for S1 is delayed: In this case the arrival of S3 will
          trigger an ACK to be transmitted covering segment S1 (which was
          previously unacknowledged).  In this case Early Retransmit
          without SACK will not prevent an RTO because no duplicate ACKs
          will arrive.  However, with SACK the ACK for S1 will also
          include SACK information indicating that S3 has arrived at the
          receiver.  The sender can then invoke Fast Retransmit on this
          ACK because ownd - SMSS bytes have been SACKed when the ACK
          arrives.

      (B) The ACK for S1 is not delayed: In this case the arrival of S1
          triggers an ACK of previously unacknowledged data.  The arrival
          of S3 triggers a duplicate ACK (because it is out-of-order).
          Both ACKs will cover the same segment (S1).  Therefore,
          regardless of whether SACK is used Early Retransmit can be
          performed by the sender (assuming no ACK loss).

      Early Retransmit is less robust in the face of reordered segments
      than when using the standard Fast Retransmit threshold.  Research
      shows that a general reduction in the number of duplicate ACKs
      required to trigger Fast Retransmit to two (rather than three) leads
      to a reduction in the ratio of good to bad retransmits by a factor
      of three [Pax97].  However, this analysis did not include the
      additional conditioning on the event that the ownd was smaller than
      4 segments and that no new data was available for transmission.

      A number of studies have shown that network reordering is not a rare
      event across some network paths.  Various measurement studies have
      shown that reordering along most paths is negligible, but along
      certain paths can be quite prevalent [Pax97,BPS99,BS02,Pir05].
      Evaluating Early Retransmit in the face of real packet reordering is
      part of the experiment we hope to instigate with this document.

      Next, we note two "worst case" scenarios for Early Retransmit:

      (1) Persistent reordering of segments coupled with an application
          that does not constantly send data can result in large numbers
          of needless retransmissions when using Early Retransmit.  For
          instance, consider an application that sends data two segments

  Expires: December 2008                                          [Page 6]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

          at a time, followed by an idle period when no data is queued for
          delivery.  If the network consistently reorders the two
          segments, the sender will needlessly retransmit one out of every
          two unique segments transmitted when using the above algorithm
          (meaning that one-third of all segments sent are needless
          retransmissions).  However, this would only be a problem for
          long-lived connections from applications that transmit in
          spurts.

      (2) Similar to the above, consider the case of 2 segment transfers
          that always experience reordering.  Just as in (1) above, one
          out of every two unique data segments will be retransmitted
          needlessly, therefore one-third of the traffic will be spurious.

      Currently this document offers no suggestion on how to mitigate the
      above problems.  However, the worst cases are likely pathological
      and part of the experiments that this document hopes to trigger
      would involve better understanding of whether such theoretical worst
      case scenarios are prevalent in the network and in general to
      explore the tradeoff between spurious fast retransmits and the delay
      imposed by the RTO.  Appendix A does offer a survey of possible
      mitigations call for curtailing the use of Early Retransmit when it
      is making poor retransmission decisions.

  4   Related Work

      Deployment of Explicit Congestion Notification (ECN) [Flo94,RFC3168]
      may benefit connections with small congestion window sizes
      [RFC2884].  ECN provides a method for indicating congestion to the
      end-host without dropping segments.  While some segment drops may
      still occur, ECN may allow a transport to perform better with small
      cwnd sizes because the sender will be required to detect less
      segment loss [RFC2884].

      [Bal98] outlines another solution to the problem of having no new
      segments to transmit into the network when the first two duplicate
      ACKs arrive.  In response to these duplicate ACKs, a TCP sender
      transmits zero-byte segments to induce additional duplicate ACKs.
      This method preserves the robustness of the standard Fast Retransmit
      algorithm at the cost of injecting segments into the network that do
      not deliver any data (and, therefore are potentially wasting network
      resources).

  5   Security Considerations

      The security considerations found in [RFC2581] apply to this
      document.  No additional security problems have been identified with
      Early Retransmit at this time.

  Acknowledgments

      We thank Sally Floyd for her feedback in discussions about Early
      Retransmit.  The notion of Early Transmit was originally sketched in
      an Internet-Draft co-authored by Sally Floyd and Hari Balakrishnan.

  Expires: December 2008                                          [Page 7]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      Armando Caro and many members of the TSVWG and TCPM working groups
      provided good discussions that helped shape this document.  Our
      thanks to all!

  Normative References

      [RFC793] Jon Postel.  Transmission Control Protocol.  Std 7, RFC
          793.  September 1981.

      [RFC2018] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow.
          TCP Selective Acknowledgement Options.  RFC 2018, October 1996.

      [RFC2581] Mark Allman, Vern Paxson, W. Richard Stevens.  TCP
          Congestion Control.  RFC 2581, April 1999.

      [RFC2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matt Podolsky.
          An Extension to the Selective Acknowledgement (SACK) Option for
          TCP.  RFC 2883, July 2000.

      [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission
          Timer.  RFC 2988, April 2000.

      [RFC3042] Mark Allman, Hari Balakrishnan, Sally Floyd.  Enhancing
          TCP's Loss Recovery Using Limited Transmit.  RFC 3042, January
          2001.

      [RFC3522] Reiner Ludwig, Michael Meyer.  The Eifel Detection
          Algorithm for TCP.  RFC 3522, April 2003.

      [RFC4960] R. Stewart.  Stream Control Transmission Protocol.
          September 2007.

  Informative References

      [AA02] Urtzi Ayesta, Konstantin Avrachenkov, "The Effect of the
          Initial Window Size and Limited Transmit Algorithm on the
          Transient Behavior of TCP Transfers", In Proc. of the 15th ITC
          Internet Specialist Seminar, Wurzburg, July 2002.

      [All00] Mark Allman.  A Server-Side View of WWW Characteristics.
          ACM Computer Communications Review, October 2000.

      [Bal98] Hari Balakrishnan.  Challenges to Reliable Data Transport
          over Heterogeneous Wireless Networks.  Ph.D. Thesis, University
          of California at Berkeley, August 1998.

      [BPS+98] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan,
          Mark Stemm, and Randy Katz.  TCP Behavior of a Busy Web Server:
          Analysis and Improvements.  Proc. IEEE INFOCOM Conf., San
          Francisco, CA, March 1998.

      [BS02] John Bellardo, Stefan Savage.  Measuring Packet Reordering,
          ACM/USENIX Internet Measurement Workshop, November 2002.


  Expires: December 2008                                          [Page 8]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      [FF96] Kevin Fall, Sally Floyd.  Simulation-based Comparisons of
          Tahoe, Reno, and SACK TCP.  ACM Computer Communication Review,
          July 1996.

      [Flo94] Sally Floyd.  TCP and Explicit Congestion Notification.  ACM
          Computer Communication Review, October 1994.

      [HB07] Per Hurtig, Anna Brunstrom. Packet Loss Recovery of Signaling
          Traffic in SCTP. In Proc. of the International Symposium of Computer
          and Telecommunications Systems (SPECTS '07), San Diego, California,
          July, 2007.

      [Jac88] Van Jacobson.  Congestion Avoidance and Control.  ACM
          SIGCOMM 1988.

      [LK98] Dong Lin, H.T. Kung.  TCP Fast Recovery Strategies: Analysis
          and Improvements.  Proceedings of InfoCom, March 1998.

      [Mor97] Robert Morris.  TCP Behavior with Many Flows.  Proceedings
          of the Fifth IEEE International Conference on Network Protocols.
          October 1997.

      [Pax97] Vern Paxson.  End-to-End Internet Packet Dynamics.  ACM
          SIGCOMM, September 1997.

      [Pir05] N. M. Piratla, "A Theoretical Foundation, Metrics and
          Modeling of Packet Reordering and Methodology of Delay Modeling
          using Inter-packet Gaps," Ph.D. Dissertation, Department of
          Electrical and Computer Engineering, Colorado State University,
          Fort Collins, CO, Fall 2005.

      [RFC2582] Sally Floyd, Tom Henderson.  The NewReno Modification to
          TCP's Fast Recovery Algorithm.  RFC 2582, April 1999.

      [RFC2884] Jamal Hadi Salim and Uvaiz Ahmed. Performance Evaluation
          of Explicit Congestion Notification (ECN) in IP Networks.  RFC
          2884, July 2000.

      [RFC3150] Spencer Dawkins, Gabriel Montenegro, Markku Kojo, Vincent
          Magret.  End-to-end Performance Implications of Slow Links.  RFC
          3150, July 2001.

      [RFC3168] K. K. Ramakrishnan, Sally Floyd, David Black.  The
          Addition of Explicit Congestion Notification (ECN) to IP.  RFC
          3168, September 2001.

      [RFC3517] Ethan Blanton, Mark Allman, Kevin Fall, Lili Wang.  A
          Conservative Selective Acknowledgment (SACK)-based Loss Recovery
          Algorithm for TCP.  RFC 3517, April 2003.

  Author's Addresses:

      Mark Allman
      International Computer Science Institute

  Expires: December 2008                                          [Page 9]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      1947 Center Street, Suite 600
      Berkeley, CA 94704-1198
      Phone: 440-235-1792
      mallman@icir.org
      http://www.icir.org/mallman/

      Konstantin Avrachenkov
      INRIA
      2004 route des Lucioles, B.P.93
      06902, Sophia Antipolis
      France
      Phone: 00 33 492 38 7751
      k.avrachenkov@sophia.inria.fr
      http://www.inria.fr/mistral/personnel/K.Avrachenkov/moi.html

      Urtzi Ayesta
      LAAS-CNRS
      7 Avenue Colonel Roche
      31077 Toulouse
      France
      urtzi@laas.fr
      http://www.laas.fr/~urtzi

      Josh Blanton
      Ohio University
      301 Stocker Center
      Athens, OH  45701
      jblanton@irg.cs.ohiou.edu

      Per Hurtig
      Karlstad University
      Department of Computer Science
      Universitetsgatan 2 651 88
      Karlstad Sweden
      per.hurtig@kau.se

  Appendix A: Research Issues in Adjusting the Duplicate ACK Threshold

      Decreasing the number of duplicate ACKs required to trigger Fast
      Retransmit, as suggested in section 2, has the drawback of making
      Fast Retransmit less robust in the face of minor network reordering.
      Two egregious examples of problems caused by reordering are given in
      section 3.  This appendix outlines several schemes that have been
      suggested to mitigate the problems caused by Early Retransmit in the
      face of packet reordering.  These methods need further research
      before they are suggested for general use (and, current consensus is
      that the cases that make Early Retransmit unnecessarily retransmit a
      large amount of data are pathological and therefore these
      mitigations are not generally required).

      MITIGATION A.1: Allow a connection to use Early Retransmit as long
          as the algorithm is not injecting "too much" spurious data into
          the network.  For instance, using the information provided by
          TCP's DSACK option [RFC2883] or SCTP's Duplicate-TSN

  Expires: December 2008                                         [Page 10]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

          notification, a sender can determine when segments sent via
          Early Retransmit are needless.  Likewise, using Eifel [RFC3522]
          the sender can detect spurious Early Retransmits.  Once spurious
          Early Retransmits are detected the sender can either eliminate
          the use of Early Retransmit or limit the use of the algorithm to
          ensure that an acceptably small fraction of the connection's
          transmissions are not spurious.  For example, a connection could
          stop using Early Retransmit after the first spurious retransmit
          is detected.

      MITIGATION A.2: If a sender cannot reliably determine if an Early
          Retransmitted segment is spurious or not the sender could simply
          limit Early Retransmits either to some fixed number per
          connection (e.g., Early Retransmit is allowed only once per
          connection) or to some small percentage of the total traffic
          being transmitted.

      MITIGATION A.3: Allow a connection to trigger Early Retransmit using
          the criteria given in section 2, in addition to a "small"
          timeout [Pax97].  For instance, a sender may have to wait for 2
          duplicate ACKs and then T msec before Early Retransmit is
          invoked.  The added time gives reordered acknowledgments time to
          arrive at the sender and avoid a needless retransmit.  Designing
          a method for choosing an appropriate timeout is part of the
          research that would need to be involved in this scheme.

  Intellectual Property Statement

      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights.
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

      The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      ietf-ipr@ietf.org.

  Disclaimer of Validity

      This document and the information contained herein are provided on
      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE

  Expires: December 2008                                         [Page 11]


  draft-allman-tcp-early-rexmt-07.txt                            June 2008

      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE.

  Copyright Statement

      Copyright (C) The IETF Trust (2008).  This document is subject
      to the rights, licenses and restrictions contained in BCP 78, and
      except as set forth therein, the authors retain all their rights.

  Acknowledgment

      Funding for the RFC Editor function is currently provided by the
      Internet Society.






































  Expires: December 2008                                         [Page 12]


name: draft-allman-tcpx2-hack
rev: 00
title: TCPx2: Don't Fence Me In
time: 2024-12-18T18:43:49Z
group_uri: /api/v1/group/group/1324/
expires: 2006-11-09T08:00:00Z
ad: /api/v1/person/person/112773/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:11.565604+00:00
source: ietf
abstract:
  In this document we aim to solve several problems caused by TCP's
      lack of header space for certain values by increasing the size of
      header without changing the semantics of the protocol.

full_text:
  Network Working Group                                          M. Allman
  Internet-Draft                                                      ICSI
  Expires: November 2006                                          May 2006


                          TCPx2: Don't Fence Me In
                       draft-allman-tcpx2-hack-00.txt

  Status of this Memo

      By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of 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.

  Copyright Notice

      Copyright (C) The Internet Society (2006).

  Abstract
      
      In this document we aim to solve several problems caused by TCP's
      lack of header space for certain values by increasing the size of
      header without changing the semantics of the protocol.

  1.  Introduction

          "Oh, give me land, lots of land under starry skies above" 
                                                         -- Bing Crosby
      
      TCP [RFC793] has proven itself to be quite robust and useful across
      a wide range of applications.  However, as the Internet has evolved
      the range of values that can be held in various TCP header fields
      have become increasingly anemic.  A number of suggestions and
      specifications have been put forth to mitigate particular issues.
      In this document, we do not address any one particular issue, but
      rather attempt to provide more head room in all of TCP's header
      fields.


  Expires: November 2006                                          [Page 1]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

      The most prominent example of the size of a TCP header value being a
      limitation is the case of the advertised window.  [RFC793] provides
      16 bits for the advertised window, which provides for a window of up
      to 64KB.  As detailed in [RFC1323] this limit has proved too small
      and causes severely limited performance as the capacity of networks
      has increased.  [RFC1323] provides the "Window Scale" (WS) option to
      address the standard limitation.  The WS option is a shift value
      that is negotiated during TCP's three-way handshake.  On incoming
      segments the advertised window value in the packet is left shifted
      by the negotiated number of bits, while on outgoing packets the
      advertised window is right shifted by the number of negotiated bits
      such that it fits in the alloted 16 bits.  A recent study shows that
      roughly 27% of observed web connections use window scaling [MAF05].
      Anecdotes indicate that all major operating system TCP
      implementations support window scaling (but, clearly many do not use
      the WS option by default).

      Increasing the size of the advertised window, in turn, means that
      TCP can chew through the sequence space more rapidly.  Therefore,
      the timestamp (TS) option and the PAWS algorithm were also specified
      in [RFC1323] to protect the TCP sender against wrapping the sequence
      space too quickly and not being able to discern this case from the
      case of old segments arriving.

      Another case where the standard TCP header is running out of room is
      in the "reserved bits" area.  Originally, TCP had 6 reserved bits
      adjacent to the "flags" field.  Explicit Congestion Notification
      (ECN) [RFC3168] and the ECN Nonce [RFC3540] consume 3 of these
      bits, leaving 3 unallocated bits.  Whether this is a problem is
      debatable.  On the one hand, only half the original reserved bits
      have been consumed in 25 years of TCP use and so one possible
      viewpoint is that having only 3 bits remaining is not a problem.  On
      the other hand, it may be beneficial to be a little less
      conservative with bit allocations (e.g., on a "retransmit" bit as
      outlined in [LK00]) and therefore more bits would be useful.

      As has been discussed on the IETF discussion list [IETF05], some
      larger servers may be running out of port numbers due to the way
      port numbers are used by applications.  [She04] offers one possible
      mechanism for starting a connection on a well-known port and then
      migrating it to an ephemeral port, which could be a useful technique
      in more fully utilizing the available port space.  Others have
      (privately - as far as we know) suggested putting larger port
      numbers or connection identifiers in TCP's option space.  Finally,
      [Tou06b] specifies a "portnames" option for TCP whereby a string in
      the option space of a TCP SYN is used for demultiplexing, rather
      than depending on a well-known port number.  One of the benefits of
      this mechanism is to allow for the port space to be more fully
      utilized.

      Finally, two proposals have noted that TCP's option space may be
      dwindling---especially with regards to further evolution.  The
      header length encoded in TCP's standard header is a 4-bit field.
      The value carried in this field is the number of 32-bit words in

  Expires: November 2006                                          [Page 2]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

      TCP's header (standard + options).  Therefore, the maximum size of a
      TCP header is 60 bytes (20 bytes of standard header and a maximum of
      40 bytes of options).  [Edd05] suggests negotiating the use of the
      first option as a larger replacement for the standard header length
      (with the standard field then being abandoned).  [Koh05] proposes
      using the unused code-points in the current header length field
      (because the minimum size of the TCP header is 20 bytes) to indicate
      larger headers (e.g., a length of "2" indicates a header size of 148
      bytes, 20 bytes of standard header and 128 bytes of option space).

      The proposal in this document is to allocate a new IP protocol
      number for a new version of TCP that is essentially the same as the
      current version [RFC793] except that the size of each standard field
      in the TCP header is doubled.  While the size of the header is
      changed, TCP's semantics are not changed.  The expectation is that
      current TCP implementations that process current 20-byte TCP headers
      will be able to process new 40-byte headers with only minimal
      changes to deal with the new size of each value.  The protocol
      logic, however, will remain identical.
      
      This document is not about specifying a "TCPng".  The functionality
      (or lack thereof) of TCP is not changed.  The intention is to simply
      give TCP some possibly breathing room.  The proposal is for
      pragmatic evolution, rather than principled engineering.

      Note: This document is clearly nowhere near as fully fleshed out as
      it would need to be to be published as an RFC.  Rather, this
      document is meant to capture the big picture idea to seed
      discussion.

      
























  Expires: November 2006                                          [Page 3]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

  2.  Specification

      A new IP protocol number, TCP-NEW, will indicate that TCP with a
      larger header will be used.  TCP stacks can then encode and decode
      the headers per this document or [RFC793] accordingly.  In the
      remainder of this document we will use "TCP" to refer to the
      [RFC793] standardized version of TCP and "TCPx2" to refer to the
      proposed new protocol.  The TCPx2 header is:

       0               1               2               3               
       0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Source Port Number (32 bits)                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Destination Port Number (32 bits)                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sequence Number (64 bits)                                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Acknowledgment Number (64 bits)                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | HLen (8 bits) | Reserved1 (15 bits)         |N C E|U A P R S F|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Window Size (32 bits)                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved2 (16 bits)           | Checksum (16 bits)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Urgent Pointer (32 bits)                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
      The fields all have the same meaning as defined in [RFC793],
      [RFC3168] (for the "C" and "E" ECN flags) and [RFC3540] (for the "N"
      ECN nonce bit).

      The "Reserved1" is the larger version of TCP's traditional reserved
      bits field.  In addition, we have added one additional field to the
      header, denoted "Reserved2" above.  The standard 16-bit Internet
      checksum is still used with TCPx2 and therefore the extra space
      derived from doubling the TCP header is reserved for future use.
      Reserved2 could possibly be for a second 16-bit checksum or a new
      32-bit checksum that encompasses both the Checksum and the Reserved2
      fields.

      To Do: TCP's SACK option [RFC2018] will need extended such that it
          holds larger sequence numbers.

      To Think About: Whether there are other options that need altered to
          take into account the larger header fields.

  3.  Advantages
      
      The main advantage of the proposal outlined above is that it is a
      straightforward change that addresses a myriad of issues that have

  Expires: November 2006                                          [Page 4]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

      or may confront TCP.  This change does not represent a high-minded
      engineering design, but rather a pragmatic evolution of a widely
      used and entrenched protocol.

      The proposal in this document mitigates all the issues discussed in
      Section 1.

      In addition, a simple doubling of the size of the TCP header will
      mitigate TCP's susceptibility to blind attacks [Tou06a] by making it
      more difficult for an attacker to guess valid port and sequence
      numbers to insert valid control or data packets into the stream.
      Note that this is a mitigation at best in that doubling the field
      sizes simply reduces the probabilities that any given blind attack
      packet will be considered valid and increases the amount of brute
      force needed to ensure a blind attack packet will succeed.  The
      proposal in this document neither aids nor hurts the security of TCP
      if an attacker can observe a connection.

      All fields in the header can revert to being self-described.  That
      is, previous knowledge is not required to interpret a given field's
      value.  This is in contrast to extensions like the Window Scale
      option whereby the negotiated scale factor is required to interpret
      every packet in the connection.

      Finally, this proposal keeps all TCP's standard information in a
      standard place in the header field, in contrast to extending fields
      using options.  This allows a TCP implementation (or middlebox,
      intrusion detection system (IDS), firewall, etc.) to quickly parse
      packets for needed information without digging through options to
      find key information.  For instance, a firewall attempting to match
      a port number or an IDS attempting to reassemble all packets from a
      given stream on-the-fly.
      
  4.  Drawbacks

      Naturally, this proposal has drawbacks.  First, TCP implementations
      will have to be changed to understand TCPx2.  While we expect that
      this is straightforward, it will clearly take effort.  Second, for
      many common cases, TCP's current header is sufficient and using
      TCPx2 would simply use more overhead for the same work.  That said,
      the overhead of a 1500 byte IPv4/TCP packet with no TCP options is
      2.7%, while the overhead of an IPv4/TCPx2 packet is 4%---hardly a
      dramatic increase.  Finally, middleboxes such as firewalls would
      have to be updated to understand TCPx2 and to implement the desired
      local policy before the protocol would be viable for use.

  5.  Transition

      Since hosts are simply augmenting current TCP implementations with
      TCPx2 the transition procedure is fairly straightforward.  A TCP
      that wishes to use TCPx2 simply sends the SYN in an IP packet with a
      TCPx2 header.  If that segment is not acknowledged with a SYN+ACK
      within a specified time period then the SYN is retransmitted using a
      standard TCP header (adjusting aspects of the SYN as necessary ---

  Expires: November 2006                                          [Page 5]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

      e.g., reducing the initial sequence number from 64-bits to 32-bits).

      The timeout does not have to be based on the default RTO (3 seconds,
      from [RFC2988]).  As long as the host transmits a TCPx2 SYN and
      retransmits a TCP SYN, the retransmit is not taken as an indication
      of congestion and therefore the interval between the original and
      this single retransmission is not of large concern from a congestion
      control standpoint since this is a single retransmission.  Further,
      the retransmission is (at least in the near-term) more likely to be
      caused by a firewall, middlebox or host that does not understand
      TCPx2 than actual network congestion.  Note that subsequent
      retransmissions would be done using TCP with the default RTO and
      backoff as specified in [RFC2988].  Finally, we note that while
      waiting for 3 seconds to retransmit a TCPx2 SYN is likely
      unreasonable, implementers and operators should not make the
      interval too short such that the TCPx2's SYN and SYN+ACK are not
      given a chance to propagate across the network before
      retransmission.

      ICMP messages indicating TCPx2 is not supported can also be used to
      trigger an immediate retransmit of the SYN with TCP and without any
      congestion control action.

  6.  Discussion    
      
      In discussions about this idea, some have suggested that rather than
      blindly doubling each header field, we carefully construct a new
      header format based on the needs of each header field.  Of
      particular note is that the doubling of the Window Size field (to 32
      bits) is not an actual doubling of the usable window given the
      wide-scale deployment of [RFC1323] which provides for 30-bit window
      sizes.  

      The notion presented in this document is admittedly a sleazy hack,
      as opposed to proper engineering.  However, it is *one* sleazy hack
      that copes with a number of disparate issues that will otherwise
      require multiple techniques to mitigate.  Therefore, it may be the
      pragmatic path to evolving a heavily used protocol.
      
  7.  Security Considerations

      TCPx2 does not introduce any new security concerns to TCP since the
      protocol semantics remain unchanged.  As discussed in Section 3,
      TCPx2 can provide for a mild increase in the robustness to blind
      attacks.

      TCPx2 may allow traffic to circumvent firewalls that pass unknown
      protocols, but allow only specific uses of TCP.  Arguably, undefined
      protocols should not be passed and therefore this is not viewed as a
      large concern.

      

      

  Expires: November 2006                                          [Page 6]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

  8.  IANA Considerations

      The proposal in this document calls for IANA to allocate a new IP
      protocol number for TCPx2.

  Acknowledgments
      
      This document was fueled by fumes from Sherwin-Williams.  The author
      benefited from useful discussions with Sally Floyd, Janardhan
      Iyengar, Mike O'Dell, Shawn Ostermann, Vern Paxson and Scott
      Shenker.

  Normative References

      [RFC793] J. Postel, Transmission Control Protocol, RFC 793,
          September 1981.

      [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. TCP Selective
          Acknowledgment Options, RFC 2018, October 1996.

      [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black.  The Addition
          of Explicit Congestion Notification (ECN) to IP, RFC 3168,
          September 2001.
      
      [RFC3540] N. Spring, D. Wetherall, and D. Ely.  Robust Explicit
          Congestion Notification (ECN) Signaling with Nonces, RFC 3540,
          June 2003.

  Informative References
      
      [Edd05] W. Eddy.  Extending the Space Available for TCP Options, May
          2005.  Internet-Draft draft-eddy-tcp-loo-03.txt (expired, cited
          for acknowledgment purposes).

      [IETF05] Email thread "Port numbers and IPv6" on IETF discussion
          list, July 2005.

      [Koh04] E. Kohler.  Extended Option Space for TCP, September 2004.
          Internet-Draft draft-kohler-tcpm-extopt-00.txt (expired, cited
          for acknowledgment purposes).

      [LK00] R. Ludwig, R. H. Katz.  The Eifel Algorithm: Making TCP
          Robust Against Spurious Retransmissions.  ACM Computer
          Communication Review, 30(1), January 2000.
      
      [MAF05] A. Medina, M. Allman, S. Floyd.  Measuring the Evolution of
          Transport Protocols in the Internet. ACM Computer Communication
          Review, 35(2), April 2005.

      [RFC1323] V. Jacobson, R. Braden, D. Borman.  TCP Extensions for
          High Performance, RFC 1323, May 1992.

      [RFC2988] V. Paxson, M. Allman. Computing TCP's Retransmission
          Timer, RFC 2988, November 2000.

  Expires: November 2006                                          [Page 7]


  draft-allman-tcpx2-hack-00.txt                                  May 2006


      [She04] T. Shepard.  Reassign Port Number Option for TCP, July 2004.
          Internet-Draft draft-shepard-tcp-reassign-port-number-00.txt
          (expired, cited for acknowledgment purposes).

      [Tou06a] J. Touch.  Defending TCP Against Spoofing Attacks, February
          2006.  Internet-Draft draft-ietf-tcpm-tcp-antispoof-03.txt (work
          in progress).

      [Tou06b] J. Touch.  A TCP Option for Port Names, April 2006.
          Internet-Draft draft-touch-tcp-portnames-00.txt (work in
          progress).

  Authors' Addresses

      Mark Allman
      ICIR / ICSI
      1947 Center Street
      Suite 600
      Berkeley, CA 94704-1198
      Phone: +1 440 235 1792
      EMail: mallman@icir.org
      http://www.icir.org/mallman/

  Intellectual Property Statement

      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights.
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

      The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      ietf-ipr@ietf.org.

  Disclaimer of Validity

      This document and the information contained herein are provided on
      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
      INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR

  Expires: November 2006                                          [Page 8]


  draft-allman-tcpx2-hack-00.txt                                  May 2006

      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  Copyright Statement

      Copyright (C) The Internet Society (2006).  This document is subject
      to the rights, licenses and restrictions contained in BCP 78, and
      except as set forth therein, the authors retain all their rights.

  Acknowledgment

      Funding for the RFC Editor function is currently provided by the
      Internet Society.









































  Expires: November 2006                                          [Page 9]



name: draft-mandel-lamps-rfc5274bis
rev: 02
title: Certificate Management Messages over CMS (CMC): Compliance Requirements
time: 2024-09-05T07:05:58Z
group_uri: /api/v1/group/group/2164/
expires: 2024-09-05T22:57:15Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081793+00:00
source: ietf
abstract:
  This document provides a set of compliance statements about the CMC
     (Certificate Management over CMS) enrollment protocol.  The ASN.1
     structures and the transport mechanisms for the CMC enrollment
     protocol are covered in other documents.  This document provides the
     information needed to make a compliant version of CMC.

     This document obsoletes RFCs 5274 and 6402.

full_text:
  LAMPS Working Group                                        J. Mandel, Ed
  Internet-Draft                                              AKAYLA, Inc.
  Obsoletes: 5274, 6402 (if approved)                        S. Turner, Ed
  Intended status: Standards Track                                   sn3rd
  Expires: 5 September 2024                                   4 March 2024


  Certificate Management Messages over CMS (CMC): Compliance Requirements
                    draft-mandel-lamps-rfc5274bis-02

  Abstract

     This document provides a set of compliance statements about the CMC
     (Certificate Management over CMS) enrollment protocol.  The ASN.1
     structures and the transport mechanisms for the CMC enrollment
     protocol are covered in other documents.  This document provides the
     information needed to make a compliant version of CMC.

     This document obsoletes RFCs 5274 and 6402.

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-mandel-lamps-rfc5274bis/.

     Discussion of this document takes place on the WG LAMPS 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://github.com/TBD.

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







  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 1]


  Internet-Draft               CMC: Compliance                  March 2024


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

     This Internet-Draft will expire on 5 September 2024.

  Copyright Notice

     Copyright (c) 2024 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Requirements Terminology  . . . . . . . . . . . . . . . . . .   4
     4.  Changes since RFC 5274 and 6402 . . . . . . . . . . . . . . .   5
     5.  Requirements for All Entities . . . . . . . . . . . . . . . .   5
       5.1.  Cryptographic Algorithm Requirements  . . . . . . . . . .   6
       5.2.  Controls  . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.3.  CRMF Feature Requirements . . . . . . . . . . . . . . . .   9
     6.  Requirements for Clients  . . . . . . . . . . . . . . . . . .  10
     7.  Requirements for Servers  . . . . . . . . . . . . . . . . . .  10
     8.  Requirements for EEs  . . . . . . . . . . . . . . . . . . . .  10
     9.  Requirements for RAs  . . . . . . . . . . . . . . . . . . . .  10
     10. Requirements for CAs  . . . . . . . . . . . . . . . . . . . .  10
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
       12.2.  Informative References . . . . . . . . . . . . . . . . .  13
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14








  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 2]


  Internet-Draft               CMC: Compliance                  March 2024


  1.  Introduction

     The CMC (Certificate Management over CMS) protocol is designed in
     terms of a client/server relationship.  In the simplest case, the
     client is the requestor of the certificate (i.e., the End Entity
     (EE)) and the server is the issuer of the certificate (i.e., the
     Certification Authority (CA)).  The introduction of a Registration
     Authority (RA) into the set of agents complicates the picture only
     slightly.  The RA becomes the server with respect to the certificate
     requestor, and it becomes the client with respect to the certificate
     issuer.  Any number of RAs can be inserted into the picture in this
     manner.

     The RAs may serve specialized purposes that are not currently covered
     by this document.  One such purpose would be a Key Escrow agent.  As
     such, all certificate requests for encryption keys would be directed
     through this RA and it would take appropriate action to do the key
     archival.  Key recovery requests could be defined in the CMC
     methodology allowing for the Key Escrow agent to perform that
     operation acting as the final server in the chain of agents.

     If there are multiple RAs in the system, it is considered normal that
     not all RAs will see all certificate requests.  The routing between
     the RAs may be dependent on the content of the certificate requests
     involved.

     This document is divided into six sections, each section specifying
     the requirements that are specific to a class of agents in the CMC
     model.  These are 1) all Entities, 2) all Servers, 3) all Clients, 4)
     all End-Entities, 5) all Registration Authorities, 6) all
     Certification Authorities.

     This document obsoletes [CMC-COMPv1] and [CMC-Updates].

  2.  Terminology

     There are several different terms, abbreviations, and acronyms used
     in this document that we define here for convenience and consistency
     of usage:

     End-Entity (EE):  Refers to the entity that owns a key pair and for
        whom a certificate is issued.

     Registration Authority (RA) or Local RA (LRA):  Refers to an entity







  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 3]


  Internet-Draft               CMC: Compliance                  March 2024


        that acts as an intermediary between the EE and the CA.  Multiple
        RAs can exist between the End-Entity and the Certification
        Authority.  RAs may perform additional services such as key
        generation or key archival.  This document uses the term RA for
        both RA and LRA.

     Certification Authority (CA):  Refers to the entity that issues
        certificates.

     Client:  Refers to an entity that creates a PKI Request.  In this
        document, both RAs and EEs can be clients.

     Server:  Refers to the entities that process PKI Requests and create
        PKI Responses.  In this document both CAs and RAs can be servers.

     PKCS #10:  Refers to the Public Key Cryptography Standard #10
        [PKCS10], which defines a certification request syntax.

     CRMF:  Refers to the Certificate Request Message Format RFC [CRMF].
        CMC uses this certification request syntax defined in this
        document as part of the protocol.

     CMS:  Refers to the Cryptographic Message Syntax RFC [CMS].  This
        document provides for basic cryptographic services including
        encryption and signing with and without key management.

     PKI Request/Response:  Refers to the requests/responses described in
        this document.  PKI Requests include certification requests,
        revocation requests, etc.  PKI Responses include certs-only
        messages, failure messages, etc.

     Proof-of-Identity:  Refers to the client proving they are who they
        say that they are to the server.

     Proof-of-Possession (POP):  Refers to a value that can be used to
        prove that the private key corresponding to a public key is in the
        possession and can be used by an end-entity.

     Transport wrapper:  Refers to the outermost CMS wrapping layer.

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




  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 4]


  Internet-Draft               CMC: Compliance                  March 2024


  4.  Changes since RFC 5274 and 6402

        |  Note: For now, this section will be list of the changes
        |  introduced by each version.  After WGLC, this section will be
        |  finalized.

     TODO for -03:

     *  Update cryptographic algorithm requirements

     -02 version changes:

     *  Updated text in intro

     *  Changed "all agents" to "all entities" in overview

     *  Updated section header numbering

     -01 version changes:

     *  Changed RFC 5272 references to draft-mandel-lamps-rfc5272bis

     *  Changed RFC 5273 references to draft-mandel-lamps-rfc5273bis

     -00 version changes:

     *  Added "Changes Since 5274 and 6402" section

     *  Updated references

     *  Merged [CMC-Updates] text

     *  Updated and moved Acknowledgments

  5.  Requirements for All Entities

     All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be
     adhered to unless specifically stated otherwise in this document.

     All entities MUST support Full PKI Requests, Simple PKI Responses,
     and Full PKI Responses.  Servers SHOULD support Simple PKI Requests.

     All entities MUST support the use of the CRMF syntax for
     certification requests.  Support for the PKCS #10 syntax for
     certification requests SHOULD be implemented by servers.






  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 5]


  Internet-Draft               CMC: Compliance                  March 2024


     The extendedFailInfo field SHOULD NOT be populated in the
     CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay
     this information.  If the extendedFailInfo field is used, it is
     suggested that an additional CMCStatusInfoV2 item exist for the same
     body part with a failInfo field.

     All entities MUST implement the HTTP transport mechanism as defined
     in [CMC-TRANS].  Other transport mechanisms MAY be implemented.

  5.1.  Cryptographic Algorithm Requirements

     All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in
     SignedData (see [CMS-ALG]).  Entities MAY verify other signature
     algorithms.  It is strongly suggested that RSA-PSS with SHA-1 be
     verified (see [CMS-RSA-PSS]).  It is strongly suggested that SHA-256
     using RSA and RSA-PSS be verified (see [RSA-256]).

     All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for
     SignedData (see [CMS-ALG]).  Other signatures algorithms MAY be used
     for generation.

     All entities MUST support Advanced Encryption Standard (AES) as the
     content encryption algorithm for EnvelopedData (see [CMS-AES]).
     Other content encryption algorithms MAY be implemented.

     All entities MUST support RSA as a key transport algorithm for
     EnvelopedData (see [CMS-ALG]).  All entities SHOULD support RSA-OAEP
     (see [CMS-RSA-OAEP]) as a key transport algorithm.  Other key
     transport algorithms MAY be implemented.

     If an entity supports key agreement for EnvelopedData, it MUST
     support Diffie-Hellman (see [CMS-DH]).

     If an entity supports PasswordRecipientInfo for EnvelopedData or
     AuthenticatedData, it MUST support PBKDF2 [PBKDF2] for key derivation
     algorithms.  It MUST support AES key wrap (see [AES-WRAP] as the key
     encryption algorithm.

     If AuthenticatedData is supported, PasswordRecipientInfo MUST be
     supported.

     Algorithm requirements for the Identity Proof Version 2 control
     Section 6.2.1 of [CMC-STRUCT] are: SHA-1 MUST be implemented for
     hashAlgId.  SHA-256 SHOULD be implemented for hashAlgId.  HMAC-SHA1
     MUST be implemented for macAlgId.  HMAC-SHA256 SHOULD be implemented
     for macAlgId.





  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 6]


  Internet-Draft               CMC: Compliance                  March 2024


     Algorithm requirements for the Pop Link Witness Version 2 control
     Section 6.3.1 of [CMC-STRUCT] are: SHA-1 MUST be implemented for
     keyGenAlgorithm.  SHA-256 SHOULD be implemented for keyGenAlgorithm.
     PBKDF2 [PBKDF2] MAY be implemented for keyGenAlgorithm.  HMAC-SHA1
     MUST be implemented for macAlgorithm.  HMAC-SHA256 SHOULD be
     implemented for macAlgorithm.

     Algorithm requirements for the Encrypted POP and Decrypted POP
     controls Section 6.7 of [CMC-STRUCT] are: SHA-1 MUST be implemented
     for witnessAlgID.  SHA-256 SHOULD be implemented for witnessAlgID.
     HMAC-SHA1 MUST be implemented for thePOPAlgID.  HMAC-SHA256 SHOULD be
     implemented for thePOPAlgID.

     Algorithm requirements for Publish Trust Anchors control Section 6.15
     of [CMC-STRUCT] are: SHA-1 MUST be implemented for hashAlgorithm.
     SHA-256 SHOULD be implemented for hashAlgorithm.

     If an EE generates DH keys for certification, it MUST support
     Section 4 of [DH-POP].  EEs MAY support Section 3 of [DH-POP].  CAs
     and RAs that do POP verification MUST support Section 4 of [DH-POP]
     and SHOULD support Section 3 of [DH-POP].

     EEs that need to use a signature algorithm for keys that cannot
     produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST
     support the Encrypted/Decrypted POP controls.  CAs and RAs that do
     POP verification MUST support this signature algorithm and MUST
     support the Encrypted/Decrypted POP controls.

  5.2.  Controls

     The following table lists the name and level of support required for
     each control.

        +============================+==========+==========+==========+
        | Control                    | EE       | RA       | CA       |
        +============================+==========+==========+==========+
        | Extended CMC Status Info   | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | CMC Status Info            | SHOULD   | SHOULD   | SHOULD   |
        +----------------------------+----------+----------+----------+
        | Identity Proof Version 2   | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Identity Proof             | SHOULD   | SHOULD   | SHOULD   |
        +----------------------------+----------+----------+----------+
        | Identification             | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | POP Link Random            | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+



  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 7]


  Internet-Draft               CMC: Compliance                  March 2024


        | POP Link Witness Version 2 | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | POP Link Witness           | SHOULD   | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Data Return                | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Modify Cert Request        | N/A      | MUST     | (2)      |
        +----------------------------+----------+----------+----------+
        | Add Extensions             | N/A      | MAY      | (1)      |
        +----------------------------+----------+----------+----------+
        | Transaction ID             | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Sender Nonce               | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Recipient Nonce            | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Encrypted POP              | (4)      | (5)      | SHOULD   |
        +----------------------------+----------+----------+----------+
        | Decrypted POP              | (4)      | (5)      | SHOULD   |
        +----------------------------+----------+----------+----------+
        | RA POP Witness             | N/A      | SHOULD   | (1)      |
        +----------------------------+----------+----------+----------+
        | Get Certificate            | optional | optional | optional |
        +----------------------------+----------+----------+----------+
        | Get CRL                    | optional | optional | optional |
        +----------------------------+----------+----------+----------+
        | Revocation Request         | SHOULD   | SHOULD   | MUST     |
        +----------------------------+----------+----------+----------+
        | Registration Info          | SHOULD   | SHOULD   | SHOULD   |
        +----------------------------+----------+----------+----------+
        | Response Information       | SHOULD   | SHOULD   | SHOULD   |
        +----------------------------+----------+----------+----------+
        | Query Pending              | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Confirm Cert.  Acceptance  | MUST     | MUST     | MUST     |
        +----------------------------+----------+----------+----------+
        | Publish Trust Anchors      | (3)      | (3)      | (3)      |
        +----------------------------+----------+----------+----------+
        | Authenticate Data          | (3)      | (3)      | (3)      |
        +----------------------------+----------+----------+----------+
        | Batch Request              | N/A      | MUST     | (2)      |
        +----------------------------+----------+----------+----------+
        | Batch Responses            | N/A      | MUST     | (2)      |
        +----------------------------+----------+----------+----------+
        | Publication Information    | optional | optional | optional |
        +----------------------------+----------+----------+----------+
        | Control Processed          | N/A      | MUST     | (2)      |
        +----------------------------+----------+----------+----------+



  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 8]


  Internet-Draft               CMC: Compliance                  March 2024


        | RA Identity Proof Witness  | N/A      | MUST     | (2)      |
        +----------------------------+----------+----------+----------+
        | Response Body              | (6)      | (6)      | N/A.     |
        +----------------------------+----------+----------+----------+

                        Table 1: CMC Control Attributes

     Notes:

     1.  CAs SHOULD implement this control if designed to work with RAs.

     2.  CAs MUST implement this control if designed to work with RAs.

     3.  Implementation is optional for these controls.  We strongly
         suggest that they be implemented in order to populate client
         trust anchors.

     4.  EEs only need to implement this if (a) they support key agreement
         algorithms or (b) they need to operate in environments where the
         hardware keys cannot provide POP.

     5.  RAs SHOULD implement this if they implement RA POP Witness.

     6.  EE's SHOULD implement if designed to work with RAs and MUST
         implement if intended to be used in environments where RAs are
         used for identity validation or key generation.  RAs SHOULD
         implement and validate responses for consistency.

     Strong consideration should be given to implementing the Authenticate
     Data and Publish Trust Anchors controls as this gives a simple method
     for distributing trust anchors into clients without user
     intervention.

  5.3.  CRMF Feature Requirements

     The following additional restrictions are placed on CRMF features:

     The registration control tokens id-regCtrl-regToken and id-regCtrl-
     authToken MUST NOT be used.  No specific CMC feature is used to
     replace these items, but generally the CMC controls identification
     and identityProof will perform the same service and are more
     specifically defined.

     The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be
     supported.  An alternative method is under development to provide
     this functionality.





  Mandel, Ed & Turner, Ed Expires 5 September 2024                [Page 9]


  Internet-Draft               CMC: Compliance                  March 2024


     The behavior of id-regCtrl-oldCertID is not presently used.  It is
     replaced by issuing the new certificate and using the id-cmc-
     publishCert to remove the old certificate from publication.  This
     operation would not normally be accompanied by an immediate
     revocation of the old certificate; however, that can be accomplished
     by the id-cmc-revokeRequest control.

     The id-regCtrl-protocolEncrKey is not used.

  6.  Requirements for Clients

     There are no additional requirements.

  7.  Requirements for Servers

     There are no additional requirements.

  8.  Requirements for EEs

     If an entity implements Diffie-Hellman, it MUST implement either the
     DH-POP Proof-of-Possession as defined in Section 4 of [DH-POP] or the
     challenge-response POP controls id-cmc-encryptedPOP and id-cmc-
     decryptedPOP.

  9.  Requirements for RAs

     RAs SHOULD be able to do delegated POP.  RAs implementing this
     feature MUST implement the id-cmc-lraPOPWitness control.

     All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as
     covered in Section 3.2.3 of [CMC-STRUCT].

  10.  Requirements for CAs

     Providing for CAs to work in an environment with RAs is strongly
     suggested.  Implementation of such support is strongly suggested as
     this permits the delegation of substantial administrative interaction
     onto an RA rather than at the CA.

     CAs MUST perform at least minimal checks on all public keys before
     issuing a certificate.  At a minimum, a check for syntax would occur
     with the POP operation.  Additionally, CAs SHOULD perform simple
     checks for known bad keys such as small subgroups for DSA-SHA1 and DH
     keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys.







  Mandel, Ed & Turner, Ed Expires 5 September 2024               [Page 10]


  Internet-Draft               CMC: Compliance                  March 2024


     CAs MUST enforce POP checking before issuing any certificate.  CAs
     MAY delegate the POP operation to an RA for those cases where 1) a
     challenge/response message pair must be used, 2) an RA performs
     escrow of a key and checks for POP in that manner, or 3) an unusual
     algorithm is used and that validation is done at the RA.

     CAs SHOULD implement both the DH-POP Proof-of-Possession as defined
     in Section 4 of [DH-POP] and the challenge-response POP controls id-
     cmc-encryptedPOP and id-cmc-decryptedPOP.

  11.  Security Considerations

     This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to
     this document.  The security sections of those two documents are
     included by reference.

     Knowledge of how an entity is expected to operate is vital in
     determining which sections of requirements are applicable to that
     entity.  Care needs to be taken in determining which sections apply
     and fully implementing the necessary code.

     Cryptographic algorithms have and will be broken or weakened.
     Implementers and users need to check that the cryptographic
     algorithms listed in this document make sense from a security level.
     The IETF from time to time may issue documents dealing with the
     current state of the art.  Two examples of such documents are
     [SMALL-SUB-GROUP] and [HASH-ATTACKS].

  12.  References

  12.1.  Normative References

     [AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard
                (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
                September 2002, <https://www.rfc-editor.org/rfc/rfc3394>.

     [CMC-STRUCT]
                Mandel, J. and S. Turner, "Certificate Management over CMS
                (CMC)", Work in Progress, Internet-Draft, draft-mandel-
                lamps-rfc5272bis-01, 8 January 2024,
                <https://datatracker.ietf.org/doc/html/draft-mandel-lamps-
                rfc5272bis-01>.









  Mandel, Ed & Turner, Ed Expires 5 September 2024               [Page 11]


  Internet-Draft               CMC: Compliance                  March 2024


     [CMC-TRANS]
                Mandel, J. and S. Turner, "Certificate Management over CMS
                (CMC): Transport Protocols", Work in Progress, Internet-
                Draft, draft-mandel-lamps-rfc5273bis-01, 8 January 2024,
                <https://datatracker.ietf.org/doc/html/draft-mandel-lamps-
                rfc5273bis-01>.

     [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.

     [CMS-AES]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
                Encryption Algorithm in Cryptographic Message Syntax
                (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
                <https://www.rfc-editor.org/rfc/rfc3565>.

     [CMS-ALG]  Housley, R., "Cryptographic Message Syntax (CMS)
                Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
                <https://www.rfc-editor.org/rfc/rfc3370>.

     [CMS-DH]   Rescorla, E., "Diffie-Hellman Key Agreement Method",
                RFC 2631, DOI 10.17487/RFC2631, June 1999,
                <https://www.rfc-editor.org/rfc/rfc2631>.

     [CMS-RSA-OAEP]
                Housley, R., "Use of the RSAES-OAEP Key Transport
                Algorithm in Cryptographic Message Syntax (CMS)",
                RFC 3560, DOI 10.17487/RFC3560, July 2003,
                <https://www.rfc-editor.org/rfc/rfc3560>.

     [CMS-RSA-PSS]
                Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
                Cryptographic Message Syntax (CMS)", RFC 4056,
                DOI 10.17487/RFC4056, June 2005,
                <https://www.rfc-editor.org/rfc/rfc4056>.

     [CRMF]     Schaad, J., "Internet X.509 Public Key Infrastructure
                Certificate Request Message Format (CRMF)", RFC 4211,
                DOI 10.17487/RFC4211, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4211>.

     [DH-POP]   Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
                of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
                May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.







  Mandel, Ed & Turner, Ed Expires 5 September 2024               [Page 12]


  Internet-Draft               CMC: Compliance                  March 2024


     [PBKDF2]   Kaliski, B., "PKCS #5: Password-Based Cryptography
                Specification Version 2.0", RFC 2898,
                DOI 10.17487/RFC2898, September 2000,
                <https://www.rfc-editor.org/rfc/rfc2898>.

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

     [RSA-256]  Schaad, J., Kaliski, B., and R. Housley, "Additional
                Algorithms and Identifiers for RSA Cryptography for use in
                the Internet X.509 Public Key Infrastructure Certificate
                and Certificate Revocation List (CRL) Profile", RFC 4055,
                DOI 10.17487/RFC4055, June 2005,
                <https://www.rfc-editor.org/rfc/rfc4055>.

  12.2.  Informative References

     [CMC-COMPv1]
                Mandel, J. and S. Turner, "Certificate Management Messages
                over CMS (CMC): Compliance Requirements", Work in
                Progress, Internet-Draft, draft-mandel-lamps-rfc5274bis-
                01, 8 January 2024,
                <https://datatracker.ietf.org/doc/html/draft-mandel-lamps-
                rfc5274bis-01>.

     [CMC-Updates]
                Schaad, J., "Certificate Management over CMS (CMC)
                Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
                <https://www.rfc-editor.org/rfc/rfc6402>.

     [HASH-ATTACKS]
                Hoffman, P. and B. Schneier, "Attacks on Cryptographic
                Hashes in Internet Protocols", RFC 4270,
                DOI 10.17487/RFC4270, November 2005,
                <https://www.rfc-editor.org/rfc/rfc4270>.

     [PKCS10]   Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.





  Mandel, Ed & Turner, Ed Expires 5 September 2024               [Page 13]


  Internet-Draft               CMC: Compliance                  March 2024


     [SMALL-SUB-GROUP]
                Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
                Attacks on the Diffie-Hellman Key Agreement Method for S/
                MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
                <https://www.rfc-editor.org/rfc/rfc2785>.

  Acknowledgements

     Obviously, the authors of this version of the document would like to
     thank Jim Schaad and Michael Myers for their work on the previous
     version of this document.

     The acknowledgment from the previous version of this document
     follows:

     The authors and the PKIX Working Group are grateful for the
     participation of Xiaoyi Liu and Jeff Weinstein in helping to author
     the original versions of this document.

     The authors would like to thank Brian LaMacchia for his work in
     developing and writing up many of the concepts presented in this
     document.  The authors would also like to thank Alex Deacon and Barb
     Fox for their contributions.

  Contributors

     Jim Schaad
     August Cellars


     Michael Myers
     TraceRoute Security, Inc.


  Authors' Addresses

     Joseph Mandel
     AKAYLA, Inc.
     Email: joe@akyala.com


     Sean Turner
     sn3rd
     Email: sean@sn3rd.com







  Mandel, Ed & Turner, Ed Expires 5 September 2024               [Page 14]


