| Internet-Draft | WIMSE Chain Provenance | September 2026 |
| Reddy, et al. | Expires 1 April 2027 | [Page] |
A request and its response, passing through a chain of workloads, may need authenticated provenance: proof of which workloads participated and whether each changed the message. The base WIMSE HTTP Message Signatures mechanism ([I-D.ietf-wimse-http-signature]) authenticates one workload's message to its immediate recipient and does not provide this across a chain. This document establishes authenticated provenance using per-hop digests of what each hop received and forwarded; this alone detects an omitted hop that changed the message. An aggregate signature closes the remaining gap, a hop that forwards the message unchanged, and keeps the signature close to the size of one signature regardless of chain length. The mechanism works with any aggregate signature scheme.¶
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-reddy-wimse-aggregate-signatures/.¶
Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (mailto:wimse@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at https://www.ietf.org/mailman/listinfo/wimse/.¶
Source for this draft and an issue tracker can be found at https://github.com/tireddy2/WIMSE-aggregate-signature.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2027.¶
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.¶
The WIMSE architecture ([I-D.ietf-wimse-arch]) authenticates a workload with a Workload Identity Token (WIT) ([I-D.ietf-wimse-workload-creds]), 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 ([I-D.ietf-wimse-http-signature]) 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, forming a delegation chain. [I-D.ietf-wimse-http-signature] authenticates one workload's message to its immediate recipient and requires a single signature per message; it does not define a mechanism for preserving provenance across a sequence of distinct workload-to-workload exchanges. This is by design, not a shortcoming: the base protocol was not scoped to provide it.¶
This document defines that additional property: authenticated provenance across a delegation chain, meaning the ability for a downstream party to verify which workloads participated in the chain and whether each one changed the message. Because every hop's signature remains verifiable at the destination, an alteration by a later hop is also detected: if the initiator signed a POST and a hop forwards it as a DELETE, the initiator's signature no longer verifies.¶
The base WIMSE HTTP Message Signatures mechanism ([I-D.ietf-wimse-http-signature]) authenticates a workload to its immediate peer. It gives no mechanism for the destination to learn the full set of workloads that participated in a delegation chain, for either the request or the response. When an agent delegates a sub-task through several other agents or tools, nothing lets a later party reconstruct who was actually involved, a gap that matters most in agentic systems (Section 2), where the path is dynamic and chosen at runtime.¶
A party receiving a delegated request or response may need to know, for each participating workload, whether it forwarded the message unchanged or modified it. This document proves that per workload, using the aggregate signature (Section 5) and the lineage digests (Section 6) together. A party that separately knows a workload's expected role can use this proof to detect misbehavior: for example, a gateway that is expected only to forward can be shown to have modified the message instead. What a workload is allowed to do is a separate question, addressed by authorization policy and out of scope (Section 2.2); this document only proves what a workload actually did.¶
A misbehaving workload can act in one of two ways: it can omit itself from the chain undetected, or it can tamper with the message, for example an agent that hallucinates and forwards a sub-task built on fabricated information. This mechanism supports audit and forensics: it narrows the search by identifying which workload made a change and fingerprinting what changed, so an auditor knows which workload's own logs to consult for the actual transformation. Without this record, finding that workload requires tracing the chain manually, and for one omitted silently, may not be possible at all.¶
This document defines two mechanisms. First, each hop's WIMSE signature covers, in addition to what [I-D.ietf-wimse-http-signature] requires, lineage digests of the message body the hop received and forwarded, and the path and query it sent (Section 6). This detects removal of a hop that changed the message body, and identifies which hop changed the body, path or query, with individual signatures. Second, an aggregate signature, used in place of individual signatures, additionally prevents removal of a hop that forwarded the message unchanged (Section 5, Appendix A), and keeps the signature size constant regardless of chain length, which matters for large PQC signatures once PQC aggregate schemes mature (Section 9).¶
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 make the need for authenticated provenance described in Section 1 especially important.¶
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.¶
For a delegation chain, this document provides evidence, carried on the message and verified by the party acting on it, for three uses:¶
Detecting attacks on the chain from the message itself, at the next workload or the destination, without relying on out-of-band records.¶
A signed record of which workloads participated and whether each changed the message.¶
Input to decisions that depend on the multi-hop behavior of the task, not only on the last hop. For example, a destination can reject a request that passed through a workload not permitted to handle the task, or whose content was modified by a workload expected only to forward it.¶
The mechanism provides the following security properties:¶
Originator authentication: the initiator is identified by its WIT, and the chain traces back to it.¶
Removal detection: a workload that signed cannot be removed from the chain, including one that forwarded the message unchanged (Section 5).¶
Modification detection: a change made by a party that did not sign is detected (Section 6). A change made by a signing workload to @method or content-type, for example a POST forwarded as a DELETE, is also detected, because the earlier workloads' signatures no longer verify (Section 5.2).¶
Change attribution: a change made by a signing workload is recorded as that workload's change (Section 6).¶
Non-repudiation: a workload cannot deny what it received or sent, because it signed both.¶
Response binding: each response is bound to the request it answers (Section 7).¶
Distributed tracing ([W3C-TRACE-CONTEXT]) also records which workloads handled a request or response. The record is unsigned: a workload can alter what it reports or leave itself out. It is also collected out-of-band: per-workload logs must be gathered and correlated across workloads, which is slow and expensive, and a receiving party must wait on, or trust, that trace. This document instead carries verifiable evidence on the message itself, so the receiving party can act on it directly. A workload cannot later deny what it received or sent, because it signed both.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terms from [I-D.ietf-wimse-arch], [I-D.ietf-wimse-workload-creds], and [I-D.ietf-wimse-http-signature]. Aggregation is used as defined in [I-D.irtf-cfrg-bls-signature]: 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:¶
Signed evidence of which workloads participated in a delegation chain and whether each changed the message.¶
A workload that signs the message as it passes along the chain.¶
The sequence of hops that sign the message, from the initiator (H_1) to the last hop (H_N). This document authenticates which hops participated and the message lineage between them (Section 6). The lineage also authenticates the order of hops that change the message, but not of consecutive hops that forward it unchanged. A workload may issue several requests to fulfill a delegated task. A request that delegates the task, or part of it, to another workload continues the chain. A request the workload issues on its own behalf, for example to retrieve data from a tool, is not part of the chain; the workload acts as the initiator of a new chain and can use this mechanism for it.¶
The first hop (H_1), which originates the message.¶
The party (H_{N+1}) that receives the message from the last hop and verifies the chain.¶
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 (Figure 1). The values are:¶
k_i: the public key of hop i, obtained from its WIT.¶
m_i: the signature base ([RFC9421] Section 2.5) for hop i, built per the WIMSE profile ([I-D.ietf-wimse-http-signature]) from hop i's Signature-Input entry. This is the input to HTTP_SIGN and HTTP_VERIFY ([RFC9421] Section 3.3).¶
s_i: the signature of hop i over m_i.¶
S: the aggregate of s_1 to s_N.¶
H1: sign(m1) --> s1 --.
|
H2: sign(m2) --> s2 --+--> aggregate --> S
|
H3: sign(m3) --> s3 --'
Verify: S against { (k1,m1), (k2,m2), (k3,m3) } in a single operation
* 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 Section 9).¶
Each hop signs its message as profiled in [I-D.ietf-wimse-http-signature], additionally covering the lineage parameters of Section 6. The hops' signatures are combined into a single aggregate signature carried in a new HTTP field, Signature-Aggregate. Like the Signature field of [RFC9421], its value is a Byte Sequence and is therefore base64-encoded ([RFC9651]). 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.¶
When Signature-Aggregate is present, the Signature field MUST NOT be present, overriding the requirement in [RFC9421] Section 4 that Signature-Input and Signature contain the same labels. A verifier that supports this specification verifies Signature-Aggregate once, against the full set of (public key, message) pairs derived from Signature-Input.¶
Each hop tags its Signature-Input entry "wimse-delegation-chain" rather than "wimse-workload-to-workload". The rule in [I-D.ietf-wimse-http-signature] Section 3 that a recipient reject a message carrying more than one signature tagged "wimse-workload-to-workload" is scoped to that tag and does not apply.¶
In a delegation chain, each hop's WIT is carried as a member of
Workload-Identity-Tokens, a Dictionary Structured Field ([RFC9651]),
keyed by the hop's Signature-Input label. A hop's Signature-Input entry
covers "workload-identity-tokens";key="<label>", its own WIT. The label
MUST be the same in both fields: it selects the hop's WIT, the WIT's sub
claim identifies the hop, and the WIT's cnf.jwk gives the hop's public key.¶
A hop MUST choose a label that is not already present in Workload-Identity-Tokens, so that adding its own WIT does not overwrite an earlier hop's member.¶
On receiving a message, a hop keeps every existing entry in Workload-Identity-Tokens unchanged. It checks each earlier hop's signature using the key from that hop's WIT, then adds its own WIT under its own label.¶
A hop MUST NOT replace or remove an existing member of Workload-Identity-Tokens. Doing so changes the covered value for that label's Signature-Input entry, so the affected hop's signature fails to verify.¶
@path and @query take their values from the message a hop sends, which later hops overwrite. Each hop additionally covers wimse-req-path and wimse-req-query, String parameters holding its own @path and @query values. Each hop carries these in its own Signature-Input entry, where they persist for later hops, so the verifier reconstructs an earlier hop's signature base from them rather than from the final message.¶
[I-D.ietf-wimse-http-signature] requires @query to be covered even when the request has no query component, in which case its value is "?" ([RFC9421] Section 2.2.7). wimse-req-query carries that value unchanged.¶
@method and content-type need no parameter: a workload MUST NOT change either, so the received values verify every workload, and any change is caught as a failed signature.¶
A hop's content-digest value is what the next hop records in its wimse-req-digest (Section 6), so the verifier reads it from the next hop's Signature-Input entry when rebuilding that hop's signature base. The last hop has no successor, so its value is the Content-Digest of the final message.¶
As the message 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.¶
Security against removal of an individual contribution relies on the unforgeability of the selected aggregate signature scheme. 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.¶
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 (Section 2.2); 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.¶
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.¶
Each hop records two digests, both covered by its signature:¶
The digest of the message body it received (its input).¶
The digest of the message body it forwards (its output). This is the Content-Digest ([RFC9530]) already required by [I-D.ietf-wimse-http-signature] when a body is present.¶
Content-Digest covers only the message body, not the method, target URI, or headers; those are separately covered by each hop's own signature, via its covered components. The lineage mechanism establishes continuity of the body across hops, not of the request or response as a whole.¶
The input digest is carried in a new signature parameter, wimse-req-digest, so it
is covered by the signature like any other parameter. Its value is a String
([RFC9651]) holding the serialized Content-Digest field value as the hop
received it, for example wimse-req-digest="sha-256=:d1a...=:", or the reserved
value "origin" for the initiator.¶
Each hop signs as required by [I-D.ietf-wimse-http-signature], and additionally covers wimse-req-digest on requests and wimse-resp-digest on responses (Section 7). Content-Digest records only what a hop sends, so each hop must state separately what it received.¶
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 body 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 body transformations.¶
The initiator has no predecessor, so it has no input digest. Its wimse-req-digest carries the reserved String 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 (Section 2.2).¶
The response path is handled the same as the request path (Section 5, Section 6), in reverse. The responses are aggregated, and each hop records the response it received and the response it forwards. An orchestrator that combines responses from several workloads into one verifies each, then conveys back the combined response: it sets wimse-resp-digest to "origin". The responses it received remain signed by the workloads that sent them, so an audit of the orchestrator can establish which workloads contributed.¶
The response takes the same path as the request, in reverse: from the destination back through each hop to the initiator. Each hop, including the initiator, holds the context for the request it made and needs the corresponding response to continue its own task; a workload that did not make a request has no context to act on a response to it.¶
The differences are the parameter name and the direction: each hop carries the digest of the message content it received in wimse-resp-digest, and continuity is verified from the destination back to the initiator. wimse-resp-digest takes the same form as wimse-req-digest (Section 6): a String holding the serialized value of the Content-Digest field as the hop received it.¶
A response signature covers @path;req and @query;req, taking their values from the request it answers. A hop verifying the whole chain has only its own request, not the requests other hops sent, so it cannot resolve those components for those hops' signatures. Each hop therefore covers wimse-req-path and wimse-req-query instead, holding the path and query of the request it answers. @method;req needs no parameter: the method does not change across hops (Section 5.2).¶
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.¶
This section shows the request path for a three-hop chain: an initiator H1, a transforming hop H2, and a pass-through hop H3 that forwards the request unchanged to the destination. The request path is shown first, then one response (Section 8.1). 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. This example follows [I-D.ietf-wimse-http-signature].¶
H1 originates the request. It has no predecessor, so its wimse-req-digest is "origin". Workload-Identity-Tokens has one member, h1, covered by H1's own Signature-Input entry via key="h1".¶
H2 verifies H1's signature using the key from h1's WIT, transforms the request, and forwards it. H2 keeps H1's entry in Workload-Identity-Tokens unchanged and adds its own under h2. H2's wimse-req-digest equals H1's Content-Digest, continuing the lineage. H2 folds its signature into the aggregate, which now covers both hops.¶
H3 forwards the request to the destination unchanged. H3's wimse-req-digest equals H2's Content-Digest, and H3's own Content-Digest is identical to H2's, since nothing was transformed. H3 keeps H1's and H2's entries in Workload-Identity-Tokens unchanged and adds its own under h3.¶
The destination validates each WIT in Workload-Identity-Tokens, takes each hop's public key from its WIT's cnf.jwk, and reconstructs each hop's signature base (using wimse-req-path and wimse-req-query for @path and @query, and the next hop's wimse-req-digest for content-digest), then verifies Signature-Aggregate against all three (public key, message) pairs in a single operation. It also checks the digest chain: H2's wimse-req-digest records what H1 sent, H3's wimse-req-digest records what H2 sent, and the final Content-Digest is what H3 sent. Because H3 forwarded unchanged, its recorded input equals the final Content-Digest, so the digest chain alone cannot show whether H3 participated; only the aggregate does.¶
Figure 5 shows the signature base the destination builds for H1, the hop whose values are furthest from the final message.¶
"@method": POST
"@path": /task
"@query": ?job=42
"content-type": application/json
"content-digest": sha-256=:d1a...=:
"workload-identity-tokens";key="h1": \
"eyJhbGciOiJFUzI1NiIs...h1wit...jw"
"@signature-params": ("@method" "@path" "@query" "content-type" \
"content-digest" "workload-identity-tokens";key="h1");created=1710000000;\
expires=1710000060;nonce="a1b2...";tag="wimse-delegation-chain";\
wimse-aud="h2.example";wimse-req-digest="origin";\
wimse-req-path="/task";wimse-req-query="?job=42"
Each line has one of three sources. @path, @query and @signature-params come from h1's own Signature-Input entry. content-digest comes from h2's wimse-req-digest, since it records what H1 sent. @method and content-type come from the final message, because neither changes across hops.¶
The destination responds to H3. It originates the response, so its wimse-resp-digest is "origin". wimse-req-nonce carries the nonce of H3's request, binding this response to it, and wimse-req-path and wimse-req-query carry the path and query of that request in place of @path;req and @query;req (Section 7).¶
Figure 7 shows the signature base H1 builds for the destination's response, after the response has travelled back through H3 and H2.¶
"@status": 200
"@method";req: POST
"content-type": application/json
"content-digest": sha-256=:5c7...=:
"workload-identity-tokens";key="d": \
"eyJhbGciOiJFUzI1NiIs...dwit...jw"
"@signature-params": ("@status" "@method";req "content-type" \
"content-digest" "workload-identity-tokens";key="d");created=1710000015;\
expires=1710000075;nonce="g7h8...";tag="wimse-delegation-chain";\
wimse-req-nonce="e5f6...";wimse-resp-digest="origin";\
wimse-req-path="/finish";wimse-req-query="?"
content-digest comes from H3's wimse-resp-digest, which records the response H3 received. @method;req and content-type come from the final response. Everything else comes from the destination's own entry, including wimse-req-nonce, which identifies H3's request as the one answered. @path;req and @query;req do not appear: the wimse-req-path and wimse-req-query parameters in the signature-params line carry those values instead (Section 7).¶
Each hop on the way back adds its own entry the same way, setting wimse-resp-digest to the digest of the response it received and folding its signature into the aggregate.¶
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 [I-D.ietf-wimse-http-signature], and all hops in a chain use the same
algorithm. The mechanism can be instantiated with any aggregate signature scheme
that remains secure when signers' keys are generated independently and resists
rogue-key attacks, consistent with [RFC7696].¶
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 the BLS message-augmentation scheme ([I-D.irtf-cfrg-bls-signature] Section 3.2). 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 ([FALCON-LABRADOR]), 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.¶
Aggregation verifies the chain as a whole. This is what makes it non-strippable (Section 5), 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 aggregate stays close to one signature's size regardless of chain length. Signature-Input, Workload-Identity-Tokens, and the digests still grow with the chain.¶
Chain integrity relies on the non-removability of the aggregate (Section 5) 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 message digests of Section 6 provide attributability, not correctness. They record which hop changed the message 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 (Section 7). 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 message 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. A destination can require a particular workload to be present as policy (Section 2.1); without such a policy, the omission is not detectable.¶
Each hop presents its WIT, so any party that verifies the chain learns which workloads participated, and the digest lineage reveals where the message was changed. Each workload's wimse-aud names the workload it sent to, which can reveal the sequence of hops.¶
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 [RFC9421].¶
Name: wimse-req-path¶
Description: String; in request and response signatures, the @path value of the request the signing hop sent.¶
Reference: RFC XXXX, Section 5.2, Section 7.¶
Name: wimse-req-query¶
Description: String; in request and response signatures, the @query value of the request the signing hop sent.¶
Reference: RFC XXXX, Section 5.2, Section 7.¶
IANA is requested to register the following in the "Hypertext Transfer Protocol (HTTP) Field Name" registry:¶
Field Name: Workload-Identity-Tokens¶
Status: permanent¶
Structured Type: Dictionary¶
Reference: RFC XXXX, Section 5.1¶
The message digests (Section 6) already detect removal of a hop that changed the message: 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 message, 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 Figure 1, 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:¶
H1 Content-Digest=A req-digest=origin
H2 Content-Digest=A req-digest=A (forwards unchanged)
H3 Content-Digest=B req-digest=A
Attacker strips H2 and presents H1 -> 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:¶
Aggregate S = s1 + s2 + s3
Attacker strips H2 and claims the chain is H1 -> 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.¶
This document builds on the WIMSE Workload Credentials and HTTP Signature drafts.¶