]> Nokia

India kondtir@gmail.com

University of the Bundeswehr Munich

Neubiberg Bavaria Germany hannes.tschofenig@unibw.de

Applications and Real-Time Workload Identity in Multi System Environments aggregate signatures signature stripping workload identity PQC This document profiles the WIMSE HTTP Message Signatures mechanism () to protect a request that passes through a chain of workloads. In the base mechanism each workload signs independently: an intermediary can remove a signature undetected, and the signatures accumulate on every hop. This document combines the workloads' signatures into one aggregate signature. Removal of a signature becomes detectable, and the signature material no longer grows with the length of the chain, a significant saving for post-quantum signature algorithms, whose signatures are large. The mechanism works with any aggregate signature scheme. About This Document Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The WIMSE architecture () authenticates a workload with a Workload Identity Token (WIT) (), a credential that identifies the workload. On its own a WIT is a bearer credential: any party that obtains it could present it as its own. The WIMSE HTTP Message Signatures mechanism () binds the WIT to a specific HTTP message. The sending workload signs the message with the key bound to its WIT. This proves the sender holds the WIT's key, and it protects the message from modification in transit, including by intermediaries that terminate TLS. A request may pass through several workloads before reaching its destination. This forms a chain, and each workload in the chain signs the message. The destination needs assurance about the whole chain, not only the last workload it received the message from. In the base mechanism each workload signs independently. This creates two problems in a chain. First, the signatures can be stripped. A workload on the path can delete another workload's signature, and the shorter chain still verifies. The destination cannot tell that a workload was removed. Second, the signatures accumulate. Every hop adds a full signature, so the total size grows with the length of the chain. This becomes particularly problematic with post-quantum signatures, which are large, often several kilobytes. A chain of even a few workloads then carries tens of kilobytes of signatures, which can exceed HTTP header size limits. This document addresses both problems in two layers. First, each hop records a digest of the request it received and the request it forwards (), giving a verifiable record of how the request was transformed. This alone detects removal of any hop that changed the request, because the recorded digests no longer line up. Second, the hops' signatures are combined into a single aggregate signature (). The aggregate detects removal of a hop even when it did not change the request, and keeps the signature material close to the size of one signature regardless of the length of the chain. The mechanism works with any aggregate signature scheme, including post-quantum schemes as they mature.

Delegation in Agentic Systems An AI agent is a workload and is authenticated by a WIT like any other workload. Agentic systems are a primary motivation for this document because they produce delegation chains with two properties that highlight the problems described in . The path is dynamic. An agent decides at processing time which downstream agent to delegate a sub-task to, so the chain is not fixed by configuration and is not known to the destination in advance. The destination therefore cannot check the chain against an expected path; it can only rely on what the chain itself proves. This is why silent removal of a hop must be detectable from the signatures alone. The request is transformed at each hop. Unlike a forwarding proxy, an agent changes the content it passes on: the sub-task given to a downstream agent differs from the task the agent received. Each transformation must be cryptographically attributable to the agent that performed it.

Scope This document addresses workload identity and message integrity for delegation chains. Authorization is out of scope. Scoped delegation and transferable authorization credentials are a separate problem, addressed by other mechanisms discussed in OAUTH WG.

Goals For a delegation chain, this document aims to:

• preserve the identity of the originating workload across all hops;
• let a receiving party verify that the chain traces back to the originator; and
• produce a signed, attributable record of each hop's transformation of the request.

Terminology and Conventions 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 when, and only when, they appear in all capitals, as shown here. This document uses the terms from , , and . Aggregation is used as defined in : given a list of signatures for a list of messages and public keys, an aggregation algorithm produces one signature that authenticates the same list of messages and public keys. This document additionally uses:

Hop:

A workload that signs the request as it passes along the chain.

Delegation Chain:

The ordered sequence of hops that sign the request, from the initiator (H_1) to the last hop (H_N).

Initiator:

The first hop (H_1), which originates the request.

Destination:

The party (H_{N+1}) that receives the request from the last hop and verifies the chain.

How Aggregate Signatures Work An aggregate signature scheme combines several signatures, each produced by a different signer over a different message, into a single value. A verifier checks that one value against the whole set of signer public keys and messages (). The values are:

• k_i: the public key of hop i, obtained from its WIT.
• m_i: the message signed by hop i. It consists of the request components and parameters listed in that hop's Signature-Input (), including the WIMSE parameters (). The signature algorithm hashes m_i when producing the signature.
• s_i: the signature of hop i over m_i.
• S: the aggregate of s_1 to s_N.

Aggregating per-hop signatures into a single value s1 --. | H2: sign(m2) --> s2 --+--> aggregate --> S | H3: sign(m3) --> s3 --' Verify once: S against { (k1,m1), (k2,m2), (k3,m3) } * one value S proves all of H1, H2, H3 signed * to drop Hk from S, the attacker must subtract sk but sk is never placed on the wire, so it cannot be removed ]]>

Combining requires no secret: any party can fold a further signature into the running value S. Removing a contribution is different. To remove hop k from S, a party needs s_k, the individual signature of hop k. In a chain where only the running aggregate is forwarded, an interior hop's individual signature is never placed on the wire, so an upstream hop cannot be removed. The algorithm that produces and combines the signatures is not fixed by this document; it is carried in each hop's WIT. Because signatures can be aggregated only within a single scheme, all hops in the chain will have to use the same algorithm (see ).

Chain Integrity via Aggregate Signatures Each hop signs its message as profiled in , additionally covering the lineage parameters of . The hops' signatures are combined into a single aggregate signature carried in a new HTTP field, Signature-Aggregate. Like the Signature field of , its value is a Byte Sequence and is therefore base64-encoded (). The presence of Signature-Aggregate signals aggregate mode: a hop that receives it folds its signature into the running aggregate rather than adding an independent Signature, and the destination verifies the single value against all Signature-Input entries. Each hop's Signature-Input entry is retained, so the verifier has, for each hop, the covered components and, via the hop's WIT, the public key needed to verify the aggregate.

Non-Removability of Interior Signatures As the request travels, each hop adds its signature to a running aggregate. A hop forwards only this combined value. The individual signatures that went into it are not sent. To make a verifier accept a chain with one hop removed, an attacker needs the aggregate for the remaining hops. Producing that value means subtracting the removed hop's individual signature from the aggregate. That signature was never sent, so the attacker cannot do this. The verifier checks the aggregate against the set of hops presented with it. A chain with a hop removed does not verify. Removal is therefore detected, and verification is all-or-nothing: the whole chain verifies, or it fails.

Anchoring the End Signatures The previous subsection shows that an interior hop cannot be removed. This leaves the two ends of the chain. Removing the last hop's signature removes that hop's own authentication. The last hop is the party presenting the request, so this defeats its own purpose. Discarding the aggregate and signing a new one makes the attacker the initiator of a new chain. The initiator is identified by its WIT. Whether a workload is allowed to originate a request is an authorization decision, which is out of scope (); this mechanism only binds the initiator's identity to the chain through its WIT. A destination that accepts requests only from permitted initiators will reject a chain re-originated by an intermediary. If an intermediary forwards the request unchanged without adding its signature, the chain passes through intact and still verifies; nothing is lost. If it modifies the request without signing, the last hop's signature no longer matches the modified request and the change is detected.

Request Lineage In an agentic system the request is modified as it travels. Some changes are legitimate: an orchestrator or gateway rewrites the request before passing it on. Some are not: a forwarding proxy is meant to pass the request through unchanged, so if it alters the request, that is an attack. This section lets a verifier tell these apart, and serves two purposes:

• Detect an unauthorized modifier. A change made by a party that did not sign is rejected.
• Provide an audit trail. A change made by a signing hop is allowed, but recorded and attributable to that hop.

The difference between the two is simply whether a signing hop made the change.

Mechanism Each hop records two digests, both covered by its signature:

• The digest of the request it received (its input).
• The digest of the request it forwards (its output). This is the Content-Digest () already required by when a body is present.

The input digest is carried in a new signature parameter, wimse-req-digest, so it is covered by the signature like any other parameter. Each hop signs as required by , and additionally covers wimse-req-digest on requests and wimse-resp-digest on responses (). Content-Digest alone is not enough: it records only what a hop sends, not what it received, so on its own it cannot show that one hop's output is the next hop's input. The verifier walks the chain and verifies that each hop's output digest matches the next hop's input digest. A mismatch indicates that the request was modified between the two hops. If the modification is reflected in the signed input and output digests recorded by a hop, it is a legitimate transformation attributable to that hop. Otherwise, the modification is unauthorized, and the request is rejected. The signed lineage record is tamper-evident and provides a verifiable audit trail for request/response transformations.

Initiator The initiator has no predecessor, so it has no input digest. Its wimse-req-digest carries the reserved value "origin", which identifies the start of the request lineage. The initiator is identified by its WIT; whether it is allowed to originate the request is an authorization decision and is out of scope ().

Responses The response path is handled the same as the request path (, ), in reverse. The responses are aggregated, and each hop records the response it received and the response it forwards. An orchestrator that combines several responses into one is a transforming hop like any other. The response takes the same path as the request, in reverse: from the destination back through each hop to the initiator. This is inherent to how the chain is connected: each hop has a link only to its neighbors, and each link is protected by TLS, so an intermediary cannot respond to the initiator directly, and the response returns hop by hop. The differences are the parameter name and the direction: each hop carries the digest of the response it received in wimse-resp-digest, and continuity is verified from the destination back to the initiator. The response originator has no predecessor on the response path and therefore no received response. It MUST set wimse-resp-digest to the reserved value "origin", which identifies the start of the response lineage. Verifiers MUST treat this value as indicating that the response originated at the destination hop.

Message Flow This section shows the request path for a two-hop chain: an initiator H1 sends a request to a hop H2, which transforms it and forwards it. Only the request is shown. Signature, aggregate, and digest values are truncated. Within the field values, line breaks preceded by a backslash are inserted for readability only and are not part of the field. H1 originates the request. It has no predecessor, so its wimse-req-digest carries the origin value. The aggregate contains only H1's signature so far.

Request sent by the initiator H1

H2 verifies H1's signature, transforms the request (so its Content-Digest changes), and forwards it. H2's wimse-req-digest is the digest of the request it received from H1, which equals H1's Content-Digest. H2 folds its signature into the aggregate, which now covers both hops.

Request forwarded by H2, aggregate now covering H1 and H2

Note that H2's wimse-req-digest (:d1a...=:) equals H1's Content-Digest in the first message: this is the continuity link that ties the two hops together. The destination verifies the single Signature-Aggregate value against both Signature-Input entries and their WIT keys, and checks that H2's wimse-req-digest equals H1's Content-Digest.

Algorithm Agility This document does not depend on any particular aggregate signature algorithm. The signature algorithm is carried in each hop's WIT (cnf.jwk.alg), as in , and all hops in a chain use the same algorithm. Any algorithm that aggregates signatures over distinct messages under distinct keys can be used, consistent with . Algorithm agility does not mean a verifier accepts whatever algorithm a hop presents. Each verifier applies a policy of acceptable algorithms and rejects a hop whose algorithm falls outside it, even if the signature verifies. The algorithm in the WIT records what a hop used; the policy decides what is acceptable. Without such a policy, agility becomes a downgrade path. At the time of writing, the mechanism can be instantiated with BLS, specified in the BLS Signatures document (); its algorithm identifier for use in a WIT will be defined in a separate specification. BLS is not post-quantum secure. Post-quantum aggregation is an active area of research, including work on aggregating Falcon signatures (), and any such scheme can be used when it matures, without changing this protocol. Without an aggregate-capable algorithm, for example in a post-quantum deployment (ML-DSA does not aggregate), a chain falls back to individual per-hop post-quantum signatures. Integrity then rests on the per-hop request and response digests, each hop recording what it received and what it forwarded: they catch removal of a hop that changed the request or response, but not one that did not, which is what the aggregate protects.

Trade-offs Aggregation verifies the chain as a whole. This is what makes it non-strippable (), but it also means a single bad signature makes the whole chain fail to verify, and the verifier cannot tell which hop was at fault. A faulty hop can therefore deny service to the chain. The benefit is that the chain carries a single aggregate value instead of every hop's signature, so its size does not grow with the length of the chain. Individual signatures carry every hop's signature; only aggregation avoids this. The saving is largest for long chains and for post-quantum signatures, whose signatures are large.

Security Considerations Chain integrity relies on the non-removability of the aggregate () and on the initiator being identified by its WIT: an attacker can neither remove an interior hop nor re-originate the chain as a permitted initiator. Because each hop verifies the chain it received before forwarding it, tampering is detected at the next honest hop, not only at the destination. The request digests of provide attributability, not correctness. They record which hop changed the request from a given input to a given output, and reject a change no hop signed for, but they do not judge whether a change was legitimate. A hop can change content maliciously and still produce a valid record; the change is attributable to that hop. The algorithm each hop uses is carried in its WIT, so a verifier learns what was used but not what should have been used. Because the path is dynamic, the expected algorithm for a given hop is not known in advance and cannot be checked after the fact. An attacker able to forge signature using a traditional algorithm could present a hop signed with that algorithm in place of a post-quantum one, and the chain would verify. Once a traditional algorithm is broken this cannot be detected; it is prevented only by policy. A post-quantum deployment excludes traditional algorithms from the acceptable set. A chain is only as strong as the weakest algorithm in it, whether the hops sign individually or their signatures are aggregated. A single hop signing with a broken or traditional algorithm lets an attacker substitute that hop's contribution. With individual signatures, the hops must use algorithms of comparable strength, though not necessarily the same algorithm: two post-quantum algorithms of equal strength are acceptable. Aggregation adds a further constraint, because signatures combine only within one algorithm: every hop uses the same algorithm. These protections apply to the response only if the response is signed along the chain (). If it is not, a response can be dropped or altered without detection. The mechanism proves which hops signed, not that every expected hop was included. A hop can deliver or forward the request without involving a further hop; because the path is dynamic, the destination does not know which hops to expect, so such a bypass cannot be detected. Requiring a particular hop to be present is a matter of authorization and is out of scope.

Privacy Considerations Every hop presents its WIT, which identifies the workload, so the complete set of workloads in a chain, and the order in which they signed, is visible to the destination and to every party on the path. The request digests further reveal that the request was transformed at each hop and link each hop's input to its output. Together these expose the structure of a delegation: which workloads participated, in what order, and where the request changed. This exposure is inherent to the mechanism. Chain integrity requires each hop to be identified by its WIT, so the participating identities cannot be hidden while still verifying the chain. A deployment can limit only what each WIT reveals about its workload; however, the delegation chain itself, including the participating workloads, their order, and the authenticated request transformations must remain visible to any party that verifies the chain.

IANA Considerations

HTTP Signature Metadata Parameters IANA is requested to register the following entries in the "HTTP Signature Metadata Parameters" registry, per the registration template in Section 6.3.1 of .

wimse-req-digest

• Name: wimse-req-digest
• Description: on request signatures, the digest of the request as received by the signing hop (its input digest), used to establish request transformation lineage across a delegation chain. A distinguished origin value indicates the initiator.
• Reference: RFC XXXX, .

wimse-resp-digest

• Name: wimse-resp-digest
• Description: on response signatures, the digest of the response as received by the signing hop from downstream (its response input digest), used to establish response transformation lineage across a delegation chain. A distinguished origin value indicates the initiator of the response.
• Reference: RFC XXXX, .

HTTP Fields IANA is requested to register the following in the "Hypertext Transfer Protocol (HTTP) Field Name" registry:

• Field Name: Signature-Aggregate
• Status: permanent
• Structured Type: Item
• Reference: RFC XXXX,

References Normative References This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Palo Alto Networks Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). Stanford University Yubico University of Waterloo Carnegie Mellon University NTT Research and ENS, Paris Cloudflare, Inc. Algorand BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. CRYPTO 2024, IACR ePrint 2024/311

What the Aggregate Adds Over Per-Hop Digests The request digests () already detect removal of a hop that changed the request: with that hop gone, the recorded input and output digests of the remaining hops no longer line up. The aggregate adds one thing on top. It also detects removal of a hop that signed but did not change the request, for example a gateway that forwards the body unchanged. The examples below use a three-hop chain H1, H2, H3 in which H2 forwards the request unchanged. As in , m_i is the message hop i signs, s_i is its signature, and k_i is its public key, taken from its WIT. With individual signatures and the digests, the pass-through hop can be stripped, because removing it keeps the digests aligned: H3: H3.req-digest=A equals H1.Content-Digest=A, continuity holds s1 and s3 still verify on their own => accepted; H2 is erased ]]> With the aggregate, the same removal fails, because H2's signature cannot be taken out of the combined value: H3: it needs s1 + s3 = S - s2 but s2 was never on the wire, so it cannot form it => rejected ]]> Aggregation is also smaller: individual signatures grow with the length of the chain, while an aggregate is a single signature regardless of length.

Acknowledgments This document builds on the WIMSE Workload Credentials and HTTP Signature drafts.