Trustworthy Enrollment of Secure Credentials
draft-bdnr-rats-trustworthy-credentials-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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Mark Novak , Michael Richardson , Henk Birkholz | ||
| Last updated | 2026-06-29 | ||
| RFC stream | (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-bdnr-rats-trustworthy-credentials-00
RATS Working Group M. Novak
Internet-Draft J.P. Morgan Chase
Intended status: Informational M. Richardson
Expires: 31 December 2026 Sandelman Software Works
H. Birkholz
Franhaufer Inst.
29 June 2026
Trustworthy Enrollment of Secure Credentials
draft-bdnr-rats-trustworthy-credentials-00
Abstract
To be written last
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that
Attesters nevertheless need to interoperate with. Existing deployed
services, which precede the introduction of Remote Attestation, are
often difficult to change/update in significant ways due to
regulatory and cryptographic review policies. Yet there are
significant advantages if clients can be incrementally updated in the
trustworthiness of the platform.
This document details a protocol by which the trusthworthiness of an
Attesters is reviewed as part of the process of it being provided
with some form of an Identity Document (a key, or a credential) to
authenticate to RUPs.
This specification illustrates how the RATS Architecture can be
applied to interoperate with RUPs by providing Attesters with such
Identity Documents.
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-bdnr-rats-trustworthy-
credentials/.
Discussion of this document takes place on the RATS Working Group
mailing list (mailto:rats@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at
https://www.ietf.org/mailman/listinfo/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/mcr/twi-rats.
Novak, et al. Expires 31 December 2026 [Page 1]
Internet-Draft ESC June 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 31 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview of Mechanism . . . . . . . . . . . . . . . . . . . . 5
3.1. Types of Credentials . . . . . . . . . . . . . . . . . . 6
3.2. Deployment of Credentials . . . . . . . . . . . . . . . . 7
4. Details of protocol . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Novak, et al. Expires 31 December 2026 [Page 2]
Internet-Draft ESC June 2026
1. Introduction
Success of a technology is ultimately measured by its adoption. The
RATS Architecture requires that RATS Relying Parties understand
Attestation Results expressed using standards such as EAT and AR4SI,
execute Appraisal Policy for Attestation Results, and have trust in
Verifiers. Additionally, there is an unstated assumption present in
the RATS Architecture that a change in Evidence may lead to a change
in either the Attestation Results or Appraisal Policy for Attestation
Results. This requirement may pose a significant adoption blocker.
One key requirement for successful deployment of Remote Attestation-
capable workloads is minimal blast radius. When a workload is moved
from a legacy to a remotely attestable (e.g. Trusted Execution)
environment, including Intel SGX, AMD SEV-SNP, ARM TrustZone, that
workload can use Remote Attestation to obtain a stable and
trustworthy Identity Document while its clients and servers do not
notice anything different.
For that, a mechanism is required by means of which a Credential
Broker, a Key Broker, or a Credential Authority takes on the role of
RATS Relying Party. This provides an intermediation between
Attestation Results, expressed using formats such as EAT and AR4SI,
and the RATS-Unaware Relying Parties whose authentication and
authorization policies may precede the introduction of Remotely
Attestable Workloads and remain static for long periods of time.
For the RATS-Unaware Relying Parties, these adoption barriers are
eliminated, as these RUPs are capable of authenticating their clients
utilizing appropriate Identity Documents. This includes shared
symmetric keys (bearer tokens), credentials including PKIX
certificates [RFC5280], JWTs [RFC7515], or WIMSE WITs
[I-D.ietf-wimse-workload-creds]. In this world, the Attester uses
Remote Attestation to obtain from the RATS Relying Party a key, token
or credential that is compatible with the RUP.
This document details an architecture by which legacy Identity
Document Identity Document issuance mechanisms are replaced with
identical Identity Documents issued, but with the additional
prerequisite of successful Remote Attestation of the workloads in
question.
Novak, et al. Expires 31 December 2026 [Page 3]
Internet-Draft ESC June 2026
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terms and concepts defined by the WIMSE and RATS
architectures, as well as the terms defined by the Trustworthy
Workload Identity Special Interest Group at the Confidential
Computing Consortium. For a complete glossary, see Section 4 of
[RFC9334], [I-D.draft-ietf-wimse-arch] & [TWISIGDef].
The definitions of terms like Trustworthy Workload Identity and
Workload Credential match those specified by the TWI SIG Definitions
[TWISIGDef].
Broker: an entity that deals out pre-existing keys or credential.
Constrast to a Credential Authority which mints new credentials.
RUP: The RATS Unaware Party (RUP). A target service that interacts
with many clients based upon credentials provided. This is
sometimes called the Collaborating Party.
Workload: [I-D.draft-ietf-wimse-arch] defines 'Workload' as "an
instance of software executing for a specific purpose". Here we
restrict that definition to the portions of the deployed software
and its configuration that are subject to Remote Attestation.
Workload Duration: the lifespan of the workload. While some
workloads can be very long lived, but many workloads are created
for a brief period of time, often added on demand to support
rising demand, and persisting for only minutes to a small fraction
of a day.
Workload Owner: the entity that manages a workload, arranging to
provision it with appropriate Workload Credentials before Workload
is launched
Workload Credential: an ephemeral identity document containing an
identity and a number of additional claims, that can be short-
lived or long-lived, and that is used to access a service
Proof of possession credential: this is a credential, such as a JWT,
that contains no other identity or authorization claims. It is
trusted by the RUP due to local policy.
Novak, et al. Expires 31 December 2026 [Page 4]
Internet-Draft ESC June 2026
Collaborating Party: see RUP.
Verifier: an entity performing the role of Attestation Verification,
as documented in Section 4 of [RFC9334]
3. Overview of Mechanism
A newly created workload connects to the Credential Broker to obtain
a set of credentials to be used to perform it's functions.
Within this connection, Evidence is transferred to the Credential
Broker to demonstrate the workloads' trusthworthiness. The
Credential Broker is acting as a RATS Relying Party, the workload is
the Attester. The Credential Broker contacts (using the background
check model), a Verifier that it trusts in order to evaluate the
Evidence, obtaining an Attestation Result.
Figure Figure 1 extends the [RFC9334] architecture to show how the
workload and credential broker take on the roles of Attester and
Relying Party.
If the Attestation Result is acceptable, then the Credential Broker
provides the set of credentials that the workload needs to accomplish
it's task.
Novak, et al. Expires 31 December 2026 [Page 5]
Internet-Draft ESC June 2026
.----------. .-----------. .----------. .---------.
| Endorser +. | Reference | | Verifier | | Relying |
'----------' | | Value | | Owner | | Party |
| | Provider | '-+--------' | Owner |
| '-+---------' | '-------+-'
| | | Appraisal |
| | Reference | Policy for |
| | Values | Evidence |
v v v |
.-------------------------. |
.--->| Verifier +------. |
| '-------------------------' | |
| | |
| Evidence Attestation | |
| Results | |
| | |
| v v
.-----+----. .-------------------.
| Attester | | Relying Party |
|----------|------------enrollment--------->|-------------------|
| workload | | credential broker |
'-----+----' '-------------------'
\
\ authentication .---------------------.
`----work-data---------->| RATS Unaware |
| Relying Party |
| Collaborating Party |
'---------------------'
RATS-Unaware ^
Authentication |
Policy |
.--------------+-.
| RATS-Unaware |
| Relying Party |
| Owner |
'----------------'
Figure 1: Credential Enrollment Architecture
3.1. Types of Credentials
There are three kinds of credentials that can be involved. Some
workloads might use a few of each.
1. The Credential Broker is also an Identity Provider (IdP), and
acts as an Registration Authority (possibly including the
Certification Authority). It issues new credentials in the form
of PKIX certificates to each trustworthy workload.
Novak, et al. Expires 31 December 2026 [Page 6]
Internet-Draft ESC June 2026
2. The Credential Broker is a respository for a credential issued by
another Identity Provider (IdP). The Credential Broker has both
the private key and the certificate, and it discloses these to
trustworthy workloads by encrypting these to an identity that
identifies the workload.
3. The Credential Broker is a resposity for a bearer token issued by
a Resource Owner, or a Workload Identity Tokens (WITs) defined in
Section 3.1 of [I-D.draft-ietf-wimse-identifier]. The Credential
Broker discloses this to trustworthy workloads by encrypting
these to an identity that identifies the workload.
The use of a shared private key is unorthodox. This architecture is
justified by the need to rapidly scale the number of workers and to
recover from hardware or network failures. The alternatives is that
external Identity Providers would need to be willing to respond to
spikes of hundreds of credential requests within a small period of
time. This would look like a denial of service attack, and it may
also require additional human authorization for each.
The patterns of communication shown in figure Figure 1 are designed
specifically such that as few modifications are required to the
workload, and no changes to the Collaborating Party are required.
3.2. Deployment of Credentials
Workloads are expected to include a (virtual) Trusted Platform Module
(TPM) (or equivalent) by which they will collect and sign Evidence to
be used in the Remote Attestation process.
The credential that will be shared by the Credential Broker will be
encrypted to a key involved in the Remote Attestation process. The
most natural mechanism is to encrypt to a key that is available only
to the TPM. The credential are then decrypted by the TPM, and the
keypair can then be made available to the workload, while never
permitting the workload to ever see the key.
In this way, a workload that be designed to do mutual TLS using a
client-certificate, and for which the location of the private key can
be configured to be in a TPM, can be adapted to the mechanism
described in this document without any significant change to the
workload itself.
4. Details of protocol
TBD.
Novak, et al. Expires 31 December 2026 [Page 7]
Internet-Draft ESC June 2026
5. Security Considerations
All communications between entities (Workload to Credential
Authority, Workload to Verifier etc) MUST be secured using mutually
authenticated, confidential, and integrity-protected channels (e.g.,
TLS).
In addition to the considerations herein, Verifier, which is a
central point of anchor for Trustworthy Workload Identifer MUST
follow the security guidance detailed in the "Security and Privacy
considerations" as detailed in the RATS Architecture Section 11 and
Section 12 of [RFC9334].
The credential key MUST always be stored securely at all time, for
example in a secure element of the underlying platform running the
Workload.
There is a risk that a live Workload Migration may render some of the
claims about the Workload invalid (e.g., live-migrating a Workload
between Germany and France may incorrectly preserve the
"Country=Germany" claim, but correctly preserve the "Region=Europe"
claim).
6. Privacy Considerations
Remote Attestation of a Workload requires exchange of attestation
related messages, for example, Evidence and Attestation Results.
This can potentially leak sensitive information about the Workload.
Confidentiality: Encryption could be used to prevent unauthorised
parties from accessing sensitive information from Evidence or
Attestation Results. This is crucial in multi-tenant environments.
The Credential Key to be released to a Workload MUST always be
encrypted to avoid potential leakage to unauthorised actors.
7. IANA Considerations
This document has no IANA actions (yet).
8. References
8.1. Normative References
Novak, et al. Expires 31 December 2026 [Page 8]
Internet-Draft ESC June 2026
[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>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[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>.
8.2. Informative References
[I-D.draft-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.draft-ietf-wimse-identifier]
Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
Work in Progress, Internet-Draft, draft-ietf-wimse-
identifier-02, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-02>.
[I-D.draft-mihalcea-seat-use-cases]
Mihalcea, I., Sardar, M. U., Fossati, T., Reddy.K, T.,
Jiang, Y., and M. Chen, "Security Goals and Use Cases for
Integrating Remote Attestation with Secure Channel
Novak, et al. Expires 31 December 2026 [Page 9]
Internet-Draft ESC June 2026
Protocols", Work in Progress, Internet-Draft, draft-
mihalcea-seat-use-cases-03, 16 June 2026,
<https://datatracker.ietf.org/doc/html/draft-mihalcea-
seat-use-cases-03>.
[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>.
[TWISIGDef]
Confidential Computing Consortium Trustworthy Workload
Identity SIG, "Trustworthy Workload Identity (TWI) Special
Interest Group — Definitions", n.d., <https://github.com/
confidential-computing/twi/blob/main/TWI_Definitions.md>.
Acknowledgments
Authors' Addresses
Mark Novak
J.P. Morgan Chase
Email: mark.f.novak@jpmchase.com
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca
Henk Birkholz
Franhaufer Inst.
Email: Henk.Birkholz@ietf.contact
Novak, et al. Expires 31 December 2026 [Page 10]