WIMSE Workload Attestation
draft-reddy-wimse-workload-attestation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Nathanael Ritz | ||
| Last updated | 2026-06-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reddy-wimse-workload-attestation-00
WIMSE T. Reddy
Internet-Draft Nokia
Intended status: Standards Track N. Ritz
Expires: 9 December 2026 Independent
7 June 2026
WIMSE Workload Attestation
draft-reddy-wimse-workload-attestation-00
Abstract
This document extends the WIMSE workload-to-workload authentication
architecture with a mechanism for conveying attestation across TLS-
terminating proxies, a deployment topology where TLS-layer
attestation mechanisms lose their end-to-end security properties.
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 9 December 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.
Reddy & Ritz Expires 9 December 2026 [Page 1]
Internet-Draft WIMSE Attestation June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Workload-Evidence Header Field . . . . . . . . . . . . . 5
5. The Workload-Attestation-Result Header Field . . . . . . . . 5
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Background Check Model Protocol Flow . . . . . . . . . . 6
6.2. Passport Model Protocol Flow . . . . . . . . . . . . . . 7
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . 8
9. Verification Algorithms . . . . . . . . . . . . . . . . . . . 8
9.1. Background Check Model (Workload-Evidence) . . . . . . . 9
9.2. Passport Model (Workload-Attestation-Result) . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10.1. Key Binding . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Stripping Attack . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix B. Document History . . . . . . . . . . . . . . . . . . 13
B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Workloads communicate with each other over HTTPS. Securing these
workload-to-workload calls requires answering two questions: who is
the caller, and can the caller be trusted?
Reddy & Ritz Expires 9 December 2026 [Page 2]
Internet-Draft WIMSE Attestation June 2026
The first question is addressed by the WIMSE architecture
[I-D.ietf-wimse-arch]. The Workload Identity Token (WIT)
[I-D.ietf-wimse-workload-creds] carries the workload's identity,
issued and signed by an Identity Server [I-D.ietf-wimse-arch]. The
WIT embeds the workload's public key, the Identity Server's assertion
that this key belongs to this workload. The WIT alone, however, does
not prove that the presenter holds the corresponding private key; any
party that intercepts the WIT could replay it. The Workload Proof
Token (WPT) [I-D.ietf-wimse-wpt] closes this gap: it is a short-lived
token signed by the workload's private key, bound to a specific HTTPS
request and target URL, proving possession of the private key
corresponding to the public key in the WIT. Together, the WIT and
WPT establish both who the caller is and that the caller is the
legitimate holder of that identity. Both travel as HTTP header
fields and survive TLS termination at proxies.
The second question, whether the caller's platform and key state can
be trusted is not addressed by the WIT/WPT mechanism. A workload may
have a valid identity and prove possession of its key, yet be running
in a compromised environment, with a key that is not hardware-
protected, or on a platform whose firmware or software does not meet
the relying party's security policy.
The SEAT Working Group is developing protocols that add attestation
to TLS. [I-D.fossati-seat-early-attestation] introduces new TLS
extensions that carry attestation Evidence or Attestation Results
intra-handshake. [I-D.fossati-seat-expat] provides post-handshake
attestation using TLS Exported Authenticators. Both mechanisms are
designed so that Evidence is cryptographically tied to a specific TLS
connection.
However, this same property is their limitation when TLS does not
extend end-to-end to the backend workload, as described in
[I-D.ietf-wimse-arch]. The attestation binding does not reach the
backend, and the backend workload receives no cryptographic evidence
of the original caller's platform and key state.
Since the WIT and WPT already travel end-to-end as HTTP headers
through TLS-terminating proxies, attestation information can travel
alongside them in the same way. This document supports both the
background check model and the passport model [RFC9334]. In both
cases, the workload's public key is the binding element across the
WIT, WPT, and the attestation information. This requires no changes
to TLS, no changes to proxy infrastructure, and no modifications to
the WIT or WPT specifications.
Reddy & Ritz Expires 9 December 2026 [Page 3]
Internet-Draft WIMSE Attestation June 2026
For the key binding verification to be cryptographically meaningful,
the Evidence needs to contain a public-key confirmation claim
corresponding to the workload's public key, and claims describing the
protection properties of the associated private key. [RFC9711]
illustrates how a key and key store may be represented in Evidence in
Appendix A.1.4, but uses private-use claim labels and does not define
standardised key-protection claims. One way to satisfy these
requirements is the profile defined in [I-D.reddy-rats-key-binding].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals as shown here.
2. Terminology
This document uses terms defined in the WIMSE Architecture
[I-D.ietf-wimse-arch] and the RATS Architecture [RFC9334].
Workload Identity Token (WIT): A JWT that represents the identity of
a workload and binds a public key to that identity, as defined in
[I-D.ietf-wimse-workload-creds].
Workload Proof Token (WPT): A JWT that provides proof of possession
of the private key associated with a WIT, as defined in
[I-D.ietf-wimse-wpt].
TLS-terminating proxy: An intermediary that terminates the caller's
TLS connection and establishes a new, independent TLS connection
to the backend workload.
Workload Evidence (WE): Attestation Evidence generated by the
workload's TEE, signed by the Attestation Key, and carried in the
Workload-Evidence HTTP header field as defined in this document.
Evidence freshness is provided by using the WPT jti claim
[I-D.ietf-wimse-wpt] as the nonce during Evidence collection.
Workload EAR (WEAR): An EAT Attestation Result (EAR)
[I-D.ietf-rats-ear] generated by a Verifier following appraisal of
the workload's Evidence, and carried in the Workload-Attestation-
Result HTTP header field as defined in this document. Request
binding is provided by using the WPT jti claim
[I-D.ietf-wimse-wpt] as the nonce during Evidence collection,
which the Verifier echoes in the eat_nonce claim of the EAR.
Reddy & Ritz Expires 9 December 2026 [Page 4]
Internet-Draft WIMSE Attestation June 2026
3. Scope
This document specifies mechanisms for conveying workload attestation
information alongside WIMSE workload-to-workload HTTP requests,
supporting both the background check model and the passport model
[RFC9334].
4. The Workload-Evidence Header Field
The Workload-Evidence header field carries Evidence generated by the
workload's TEE. The Evidence MUST be encapsulated in a CMW
(Conceptual Message Wrapper) [I-D.ietf-rats-msg-wrap]. The CMW type
field identifies the attestation technology and serialization format,
providing interoperability at the envelope level without out-of-band
negotiation.
The Evidence MUST contain:
* a public-key confirmation claim corresponding to the workload's
public key, and
* claims describing the protection properties of the associated
private key.
One way to satisfy these requirements is the profile defined in
[I-D.reddy-rats-key-binding].
The three header fields form a coherent set, each independently
signed by a different authority:
+----------------------------+------------------+---------------------------+
| Header field | Signer | Binds to |
+----------------------------+------------------+---------------------------+
| Workload-Identity-Token | Identity Server | Workload identity |
| Workload-Proof-Token | Workload | Private key + Target URI |
| Workload-Evidence | TEE (AK) | Platform + key |
+----------------------------+------------------+---------------------------+
The workload's public key is the binding across all three: it is
asserted by the Identity Server in the WIT, proven in possession by
the WPT, and attested as hardware-protected by the Evidence.
5. The Workload-Attestation-Result Header Field
When the passport model is used, the Workload-Attestation-Result
header field carries the EAT Attestation Result (EAR) generated by
the Verifier [I-D.ietf-rats-ear].
Reddy & Ritz Expires 9 December 2026 [Page 5]
Internet-Draft WIMSE Attestation June 2026
The EAR MUST contain the ear_verified_attester_key claim. This claim
provides the Relying Party with the verified public key of the
attester. Because the ear_verified_attester_key claim is represented
as a PEM-encoded SPKI or certificate, and the WIT carries the
workload's public key as a JWK [I-D.ietf-wimse-workload-creds],
implementations MUST convert between the two formats to perform the
required cryptographic comparison.
The EAR MUST also contain the eat_nonce claim, set to the nonce value
extracted from the appraised Evidence. Because the workload uses the
WPT jti claim as the Evidence nonce, this value enables the Relying
Party to verify that the EAR was produced from Evidence collected for
this specific request.
+-----------------------------+------------------+---------------------------+
| Header field | Signer | Binds to |
+-----------------------------+------------------+---------------------------+
| Workload-Identity-Token | Identity Server | Workload identity |
| Workload-Proof-Token | Workload | Private key + Target URI |
| Workload-Attestation-Result | Verifier | Appraised platform + key |
+-----------------------------+------------------+---------------------------+
Similar to the background check model, the workload's public key acts
as the binding element: it is asserted by the Identity Server in the
WIT, proven in possession by the WPT, and verified by the Verifier in
the EAR.
6. Protocol Flows
6.1. Background Check Model Protocol Flow
Reddy & Ritz Expires 9 December 2026 [Page 6]
Internet-Draft WIMSE Attestation June 2026
Caller (TEE Workload) Backend Workload
| |
| [Startup] |
| Generate key pair inside TEE |
| Obtain WIT from Identity Server |
| |
| [Per-request] |
| Construct WPT, generate jti |
| Collect Evidence using jti as nonce |
| Sign WPT with private key |
| |
|------ HTTPS Request ----------------->|
| Workload-Identity-Token: <WIT> |
| Workload-Proof-Token: <WPT> |
| Workload-Evidence: <CMW> |
| |
| Verify WIT |
| Verify WPT |
| Submit Evidence |
| + jti + WIT key |
| to Verifier |
| Evaluate policy |
| |
|<------ Response ----------------------|
6.2. Passport Model Protocol Flow
In the passport model, the caller obtains the Attestation Result from
a Verifier before initiating the request to the backend workload.
The caller uses the WPT jti claim as the challenge when requesting
the EAR.
Reddy & Ritz Expires 9 December 2026 [Page 7]
Internet-Draft WIMSE Attestation June 2026
Caller (TEE Workload) Verifier Backend Workload
| | |
| [Startup] | |
| Generate key pair inside TEE | |
| Obtain WIT from Identity Server | |
| | |
| [Per-request] | |
| Construct WPT, generate jti | |
| Collect Evidence (jti as nonce) | |
| Submit Evidence to Verifier --->| |
| | Verify Evidence |
|<----- Return EAR (w/ key) ------| |
| Sign WPT with private key | |
| | |
|------ HTTPS Request --------------------------------->|
| Workload-Identity-Token: <WIT> |
| Workload-Proof-Token: <WPT> |
| Workload-Attestation-Result: <EAR> |
| |
| Verify WIT |
| Verify WPT |
| Verify EAR sig |
| Verify key in |
| EAR matches WIT |
| Evaluate policy |
| |
|<------ Response --------------------------------------|
7. Applicability
The Workload-Evidence and Workload-Attestation-Result header fields
defined in this document are applicable to both WIMSE application-
level protection mechanisms: WPT [I-D.ietf-wimse-wpt] and HTTP
Signatures [I-D.ietf-wimse-http-signature].
8. Proxy Behaviour
A TLS-terminating proxy MUST forward the Workload-Evidence and
Workload-Attestation-Result header fields unchanged toward the
backend workload. A proxy MUST NOT strip or modify the Workload-
Evidence or Workload-Attestation-Result header fields.
9. Verification Algorithms
The backend workload acts as the Relying Party as defined in
[RFC9334] and submits Evidence to a Verifier for appraisal.
Reddy & Ritz Expires 9 December 2026 [Page 8]
Internet-Draft WIMSE Attestation June 2026
The backend workload MUST first verify the WIT and WPT as defined in
[I-D.ietf-wimse-wpt]. Following this, it MUST perform the steps for
either the Background Check Model or the Passport Model, depending on
which header is presented.
For both models, the request MUST NOT be processed further until all
steps have completed successfully. If a backend workload requires
attestation by policy, it MUST reject any request that does not
include either a valid Workload-Evidence or Workload-Attestation-
Result header field with a 403 Forbidden status code.
If a request contains both Workload-Evidence and Workload-
Attestation-Result header fields, the backend MUST reject the request
with 400 Bad Request.
9.1. Background Check Model (Workload-Evidence)
1. Extract the Workload-Evidence header field value.
2. Decode the CMW wrapper to determine the Evidence format from the
CMW type field.
3. Convert the WIT public key to the format indicated by the CMW
type field.
4. Submit the Evidence, the WPT jti, and the converted WIT public
key to a Verifier.
5. The Verifier MUST verify that the nonce carried in the Evidence
matches the submitted jti.
6. The Verifier MUST verify that the public key in the Evidence
matches the submitted WIT public key.
7. Evaluate the returned Attestation Result against local policy.
9.2. Passport Model (Workload-Attestation-Result)
1. Extract the Workload-Attestation-Result header field value.
2. Verify the digital signature of the EAR using the Verifier's
public key or trust anchor.
3. Verify that the ear_verified_attester_key claim is present in the
EAR Appraisal record.
Reddy & Ritz Expires 9 December 2026 [Page 9]
Internet-Draft WIMSE Attestation June 2026
4. Convert the PEM-encoded SPKI or certificate from the
ear_verified_attester_key claim and the JWK from the WIT into a
common format.
5. Verify that the converted public key from the EAR matches the
public key in the WIT.
6. Verify that the eat_nonce claim in the EAR matches the jti claim
from the WPT.
7. Evaluate the EAR against local policy.
10. Security Considerations
10.1. Key Binding
The security of this mechanism depends on verifying that the public
key in the Evidence matches the public key in the WIT. This ensures
the Evidence is about the same key that the WPT proves possession of.
One way to satisfy the key binding requirements is the profile
defined in [I-D.reddy-rats-key-binding].
10.2. Stripping Attack
A malicious proxy may strip the Workload-Evidence or Workload-
Attestation-Result header fields. Backend workloads that require
attestation by policy MUST reject requests lacking the required valid
Workload-Evidence or Workload-Attestation-Result header field with a
403 Forbidden status code.
11. IANA Considerations
This document requests registration of the following HTTP header
fields in the "HTTP Field Names" registry:
Field Name: Workload-Evidence
Status: permanent
Specification Document: This document
Field Name: Workload-Attestation-Result
Status: permanent
Specification Document: This document
Reddy & Ritz Expires 9 December 2026 [Page 10]
Internet-Draft WIMSE Attestation June 2026
12. References
12.1. Normative References
[I-D.ietf-rats-ear]
Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
Attestation Results", Work in Progress, Internet-Draft,
draft-ietf-rats-ear-04, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ear-04>.
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
11 December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-23>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-07, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-07>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J. A., Schwenkschuster, A.,
Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
Credentials", Work in Progress, Internet-Draft, draft-
ietf-wimse-workload-creds-01, 5 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-01>.
[I-D.ietf-wimse-wpt]
Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
Token", Work in Progress, Internet-Draft, draft-ietf-
wimse-wpt-01, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-01>.
[I-D.reddy-rats-key-binding]
Reddy.K, T., Tschofenig, H., Fossati, T., and I. Mihalcea,
"Key Attestation for Entity Attestation Tokens (EAT)",
Work in Progress, Internet-Draft, draft-reddy-rats-key-
binding-01, 7 June 2026,
<https://datatracker.ietf.org/doc/html/draft-reddy-rats-
key-binding-01>.
Reddy & Ritz Expires 9 December 2026 [Page 11]
Internet-Draft WIMSE Attestation June 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/rfc/rfc8747>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
12.2. Informative References
[I-D.fossati-seat-early-attestation]
Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and
T. Reddy.K, "Using Attestation in Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)", Work
in Progress, Internet-Draft, draft-fossati-seat-early-
attestation-04, 27 May 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
early-attestation-04>.
[I-D.fossati-seat-expat]
Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y.,
Tschofenig, H., and I. Mihalcea, "Remote Attestation with
Exported Authenticators", Work in Progress, Internet-
Draft, draft-fossati-seat-expat-02, 26 February 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-02>.
Reddy & Ritz Expires 9 December 2026 [Page 12]
Internet-Draft WIMSE Attestation June 2026
[I-D.ietf-wimse-http-signature]
Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload
Authentication with HTTP Signatures", Work in Progress,
Internet-Draft, draft-ietf-wimse-http-signature-03, 7
April 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-wimse-http-signature-03>.
Appendix A. Acknowledgements
The authors would like to thank Thomas Fossati and Ionut Mihalcea for
the review and comments, and the SEAT Working Group participants for
discussions that motivated this work.
Appendix B. Document History
B.1. Version -00
* Initial version
Authors' Addresses
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: kondtir@gmail.com
Nathanael Ritz
Independent
Email: ietf@nritz.com
Reddy & Ritz Expires 9 December 2026 [Page 13]