Factor-based Attestation and Credential Transport Scheme (FACTS) over TLS 1.3
draft-ritz-seat-facts-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) | |
|---|---|---|---|
| Author | Nathanael Ritz | ||
| Last updated | 2026-03-01 | ||
| 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-ritz-seat-facts-00
Secure Evidence and Attestation Transport N. Ritz
Internet-Draft Independent
Intended status: Standards Track 1 March 2026
Expires: 2 September 2026
Factor-based Attestation and Credential Transport Scheme (FACTS) over
TLS 1.3
draft-ritz-seat-facts-00
Abstract
This document describes FACTS (Factor-based Attestation and
Credential Transport Scheme) over TLS 1.3. Conceptually acting as
"multi-factor authentication" for machine identities, factor-based
attestation derives session trust from multiple independent
cryptographic inputs rather than a single point of failure.
Specifically, it utilizes a dual-key scheme that binds identity to
attestation evidence through the use of key encapsulation material
keys (KEM) and traditional identity signing keys (IK), establishing
per-session freshness.
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-ritz-seat-facts/.
Discussion of this document takes place on the Secure Evidence and
Attestation Transport Working Group mailing list
(mailto:seat@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/seat. Subscribe at
https://www.ietf.org/mailman/listinfo/seat/.
Source for this draft and an issue tracker can be found at
https://github.com/nathanaelritz/facts-tls.
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/.
Ritz Expires 2 September 2026 [Page 1]
Internet-Draft FACTS-TLS March 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 September 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Split-Session Alternative . . . . . . . . . . . . . . . . 11
5. Key Schedule Integration . . . . . . . . . . . . . . . . . . 11
5.1. Early Secret Binding . . . . . . . . . . . . . . . . . . 12
5.2. psk_attest Derivation . . . . . . . . . . . . . . . . . . 12
5.3. AAD Construction . . . . . . . . . . . . . . . . . . . . 12
6. Evidence Binding . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Report Data Construction . . . . . . . . . . . . . . . . 13
7. Extended Key Update with PSK Injection . . . . . . . . . . . 13
7.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Interaction with draft-ietf-tls-extended-key-update . . . 14
8. Extension Definitions . . . . . . . . . . . . . . . . . . . . 14
8.1. The facts_hello Extension . . . . . . . . . . . . . . . . 14
8.2. The facts_challenge Extension . . . . . . . . . . . . . . 15
8.2.1. ClientHello Variant . . . . . . . . . . . . . . . . . 15
8.2.2. EncryptedExtensions Variant . . . . . . . . . . . . . 16
8.3. The facts_attestation Extension . . . . . . . . . . . . . 16
9. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. The facts_attest_req Extension . . . . . . . . . . . . . 19
9.1.1. Extension Structure . . . . . . . . . . . . . . . . . 19
9.1.2. Server Behavior . . . . . . . . . . . . . . . . . . . 20
9.1.3. Client Behavior . . . . . . . . . . . . . . . . . . . 20
Ritz Expires 2 September 2026 [Page 2]
Internet-Draft FACTS-TLS March 2026
9.1.4. Relationship to cert_req_context . . . . . . . . . . 21
10. EAT/AR Claims as Identity Documents . . . . . . . . . . . . . 21
10.1. EAT Structure . . . . . . . . . . . . . . . . . . . . . 21
10.2. AR Structure . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11.1. Idealized deployment topology assumptions . . . . . . . 23
11.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24
11.2.1. ProVerif model (Work in Progress) . . . . . . . . . 25
11.3. Key Separation . . . . . . . . . . . . . . . . . . . . . 25
11.4. Compound Authentication . . . . . . . . . . . . . . . . 25
11.5. Pre-Handshake Identity Binding . . . . . . . . . . . . . 26
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
12.1. DNS Lookup Exposure . . . . . . . . . . . . . . . . . . 26
12.2. Evidence Disclosure . . . . . . . . . . . . . . . . . . 26
12.3. Identity Document Opacity . . . . . . . . . . . . . . . 26
12.4. Conditional Evidence Disclosure . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
13.1. TLS ExtensionType Registry . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Remote attestation enables an entity to demonstrate the integrity of
its runtime environment to a remote peer. When combined with TLS
[I-D.ietf-tls-rfc8446bis], attestation allows a relying party to
verify that the TLS endpoint operates within a Trusted Execution
Environment (TEE) with known-good software before exchanging
application data.
This document combines the latency properties of intra-handshake
attestation with the security binding of post-handshake attestation
through a dual-key authentication architecture that introduces four
targeted architectural changes that preserve the standard TLS 1.3
state machine and key schedule:
1. _LTK and KEM Keys:_ Introduction of a dedicated encapsulation key
(pubKEM), alongside the usual long-term signing or identity key
(pubIK / LTK).
2. _Early authentication:_ Accessing signed identity documents (e.g.
signed JWT/CWT) just before starting the TLS handshake enables
cryptographic binding of pubKEM to the server identity and pubIK
jointly, closing the identity/key confusion gap that diversion
attacks exploit.
Ritz Expires 2 September 2026 [Page 3]
Internet-Draft FACTS-TLS March 2026
3. _Dual-Nonce Encapsulation:_ Encapsulation of mutual 'challenge'
and 'counter-challenge' nonces (CN1, CN2) to the Server's pubKEM
and the Client's per-session pubKEM, respectively.
4. _Session-Specific Quote Encryption:_ Encrypting the attestation
quote under psk_attest (derived from both challenge nonces), with
the rdata committing to the full suite of parameters (pubIK_S,
CN1, CN2, pubKEM_C).
The pre-handshake Identity Document is formatted as a JSON Web Token
[RFC7519] carrying keys in a JWKS cnf claim [RFC7800]. No novel
cryptographic structures are introduced by this document. JWT
provides a self-contained, channel-independent integrity guarantee
suitable for distribution over untrusted transports such as DNS.
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.
The reader is assumed to be familiar with the vocabulary and concepts
defined in [RFC9334], [I-D.ietf-tls-rfc8446bis], and [RFC9180].
FACTS relies on the RATS Conceptual Message Wrapper (CMW)
[I-D.ietf-rats-msg-wrap] for encapsulating attestation payloads and
supports both the background-check and passport topologies defined in
[RFC9334].
TLS Identity Key (privIK / pubIK aka LTK): A long-term signing key
pair used by a TLS peer for authentication during the handshake
via CertificateVerify. In the threat model of this document,
privIK is assumed to be potentially compromisable by an adversary
with sufficient access to the software layer.
Encapsulation Key (privKEM / pubKEM): A key pair used for
Authenticated Hybrid Public Key Encryption (AuthHPKE, mode 2 of
[RFC9180]). In the threat model of this document, privKEM is
assumed to be potentially compromisable independently of privIK.
Attestation Key (privAK / pubAK): A hardware-bound key pair rooted
in the TEE's hardware root of trust (e.g., a TPM endorsement key,
an Intel TDX report signing key, or an Arm CCA platform
attestation key). The private component (privAK) MUST NOT be
extractable from the hardware security boundary. This key pair is
the trust anchor for the protocol's Evidence integrity.
Ritz Expires 2 September 2026 [Page 4]
Internet-Draft FACTS-TLS March 2026
Challenge Nonce (CN1, CN2): Ephemeral random values exchanged
between client and server during the handshake using AuthHPKE.
CN1 is generated by the client and sealed to the server's pubKEM.
CN2 is generated by the server and sealed to the client's pubKEM.
Together they provide mutual freshness and form the basis for
attestation key derivation.
Session Binding Commitment (rdata / eat_nonce): The 32-byte SHA-256
digest SHA-256(pubIK_S || CN1 || CN2 || pubKEM_C) that binds the
attester's identity key, both challenge nonces, and the client's
ephemeral KEM key into a single compound nonce. No single party
controls all four inputs. This value is conveyed in the platform-
specific report data field of the TEE attestation report (where it
is referred to as rdata) and as the eat_nonce claim when
serialized as an EAT. Both carry the identical digest; the
distinction is purely one of serialization layer.
Attestation Key Material (psk_attest): A symmetric key derived from
both challenge nonces. psk_attest is used to encrypt Evidence
during the handshake and is subsequently injected into the
Extended Key Update to rotate session traffic keys.
Trust Authority (TA / CA): A trusted third party that signs the
Identity Document, establishing a verifiable chain of trust. This
document uses "CA" for simplicity.
Platform Measurements (quote): The set of cryptographic measurements
characterizing the Trusted Computing Base (TCB) of the platform,
reduced to a 32-byte SHA-256 commitment (the Evidence Commitment)
for use as input to key derivation.
3. Protocol Architecture
Ritz Expires 2 September 2026 [Page 5]
Internet-Draft FACTS-TLS March 2026
+----------------+
| (Trust anchor) |
| signs ID Doc |
+----+-----------+
|
| Signed ID Document
| (subject, pubIK, pubKEM)
|
+------+-------+--------------+
| | |
v v v
+----------+ +----------+ +----------+
| Identity | | Identity | | Identity |
| Store | | Store | | Store |
| (JWT) | | (Cert) | | (Log) |
+----+-----+ +----+-----+ +----+-----+
| | |
+--------------+--------------+
^
| Lookup
v
+------------+
| Verifier |<------+
+-----+------+ |
| |
| Challenge |
| |
v |
+------------+ |
| Attester | |
+-----+------+ |
| |
+--------------+
Signature
Figure 1: FACTS Architectural Topology
FACTS proceeds in three phases, preceded by an enrollment step that
executes once per server instance. The protocol's trust model rests
on two independently operating dimensions: the attestation ordering
(which peer attests first) and the appraisal topology (how evidence
is evaluated). These dimensions combine freely.
Ritz Expires 2 September 2026 [Page 6]
Internet-Draft FACTS-TLS March 2026
+------------------+
| Device Boots TEE |
+--------+---------+
|
v
/ Valid AR? \
+-------------+
| |
(Yes) (No) ---> +---------------+
| | Enrollment/CA |
|<--(AR Issued)----+---------------+
v
+-------------------+
| Client Fetches AR |
+---------+---------+
|
v
+-------------------+
| TLS Handshake |
| (FACTS Phase 2) |
+---------+---------+
|
v
/ Server Policy: \
| Attest Now? |
\ /
| |
(Yes) (No)
| |
v v
+----------------+ +---------------+
| Standard Flow | | Cond. mTLS |
| Server Attests | | Client Attests|
+--------+-------+ +------+--------+
| |
v v
+-----------------------------------+
| Phase 3: EKU & PSK Injection |
+-----------------+-----------------+
|
v
/ Server Attest \
| Pending? |
\ /
| |
(Yes) (No)
| |
v v
Ritz Expires 2 September 2026 [Page 7]
Internet-Draft FACTS-TLS March 2026
+------------------+ (Mutual Attest Done)
| Post-Handshake |
| (SEAT Expat) |
+--------+---------+
|
v
(Mutual Attest Done)
Figure 2: FACTS Decision Flow
*Enrollment.* A device with no valid AR generates its identity and
encapsulation key pairs and produces an EAT [RFC9711] signed by its
hardware-bound attestation key. The Verifier appraises the platform
measurements and, if accepted, issues an AR carrying the dual-key
binding: cnf [RFC7800] for pubIK (_signing_) and attested_kem for
pubKEM (_encapsulation_). This AR is distributed via DNS, HTTPS, or
any untrusted channel; the Verifier's signature protects integrity.
See Section 9 for the enrollment protocol and Section 10 for the AR
and EAT claim structures.
*Phase 1 -- Identity Lookup.* The client fetches and verifies the AR,
extracting pubIK_S and pubKEM_S. It generates an ephemeral pubKEM_C,
unique to this session and never reused.
*Phase 2 -- Attested TLS Handshake.* The client seals a challenge
nonce (CN1) to pubKEM_S; the server proves possession of privKEM_S by
unsealing it, then seals its counter-challenge (CN2) to the client's
ephemeral pubKEM_C. Both peers derive psk_attest.
The handshake then branches on server policy. In the standard flow,
the server includes its encrypted evidence in the Certificate
message. In the conditional _mTLS_ flow, the server withholds its
evidence and issues a facts_attest_req, requiring the client to
attest first.
The choice between Passport and Background Check topologies [RFC9334]
is orthogonal to this ordering and applies independently to either
flow.
*Phase 3 -- EKU with PSK Injection.* After evidence appraisal, an
Extended Key Update [I-D.ietf-tls-extended-key-update] mixes
psk_attest into the traffic keys. Any adversary lacking privKEM_C
cannot derive the rotated keys and is evicted.
*Post-Handshake.* If the server deferred attestation, it delivers
evidence via Exported Authenticators [I-D.fossati-seat-expat] over
the rotated channel. Periodic reattestation is available to any flow
via the same mechanism.
Ritz Expires 2 September 2026 [Page 8]
Internet-Draft FACTS-TLS March 2026
4. Protocol Flow
The following diagram illustrates the 3 phase flow:
Client Server
| |
| [1] Pre-fetch identity doc (e.g. signed jwt/x.509) |
| during IP resolution, service discovery, etc |
+--------------------------------------------+ |
| in(untrusted_dns_txt, (identity_doc, sig)) | |
+--------------------------------------------+ | \
| | |
| [2] Internal Validation | [Phase 1]
+-----------------------------------+ | |
| verify(pubCA, identity_doc, sig) | | /
| extract (ID_S, pubKEM_S, pubIK_S) | |
+-----------------------------------+ |
| |
| - - - - - - - - - TLS 1.3 Handshake - - - - - - - -|
| |
| [3] ClientHello |
| + key_share |
| + facts_hello |
| + facts_challenge(pubKEM_C, |
| + HPKE{CN1}_{pubKEM_S}) |
| + psk_binder |
| -------------------------------------------------> |
| |
| [4] Decapsulate + Verify |
| +---------------------------------+
| | hpkeOpen(ct, aad_ct, privKEM_S) |
| | verify psk_binder; new CN2 |
| +---------------------------------+
| |
| [5] ServerHello |
| + key_share |
| <------------------------------------------------- |
| |
| [6] {EncryptedExtensions} |
| + facts_challenge(HPKE{CN2}_{pubKEM_C})|
| <------------------------------------------------- |
| |
| [7] Decapsulate CN2 | \
+---------------------------------------+ | |
| hpkeOpen(cn2_ct, aad_ee, privKEM_C) | | [Phase 2]
| `psk_attest` = derive(CN1, CN2) | | |
+---------------------------------------+ | /
| |
Ritz Expires 2 September 2026 [Page 9]
Internet-Draft FACTS-TLS March 2026
| [8] {Certificate} |
| + facts_attestation |
| + (pubIK, selfsign, |
| + AEAD{quote}_{psk_attest}) |
| <------------------------------------------------- |
| |
| [9] Verify Certificate |
+---------------------------------------+ |
| verify(pubCA, identity_doc, sig) | |
| attest_open(encQuote, `psk_attest`) | |
| verify(pubAK, dataSign, sig) | |
| check hash(pubIK,CN1,CN2,pubKEM_C) | |
+---------------------------------------+ |
| |
| [10] {CertificateVerify} |
| <------------------------------------------------- |
| |
| [11] {ServerFinished} |
| <------------------------------------------------- |
| |
| [12] {ClientFinished} |
| -------------------------------------------------> |
| |
| - - - - - - - - - Post Handshake - - - - - - - - - |
| |
| [I-D.ietf-tls-extended-key-update, |
| (requires EKU-PSK extension) |
| |
| [13] Derive post-rotation key for PFS | \
+-------------------------------------------+ | |
| eku_key = (eku_dh_shared || `psk_attest`) | | [Phase 3]
+-------------------------------------------+ | |
| [14] {EKU Request} =========================> | /
| [15] {EKU Response} <========================= |
| |
| <===============================================> |
| [16] Application Data |
| [17] Periodic re-Attestation health checks |
| [e.g., I-D.fossati-seat-expat] |
| <===============================================> |
| |
Figure 3: The 3 phase flow of FACTS-TLS
Ritz Expires 2 September 2026 [Page 10]
Internet-Draft FACTS-TLS March 2026
4.1. Split-Session Alternative
An alternative design uses a sacrificial bootstrap handshake followed
by PSK-DHE resumption on a new TCP connection, rather than EKU within
a single connection.
Client MiTM Attester/TEE
| | |
|- - - Session 0.5: Bootstrap (sacrificial) - -|
| CH + facts_challenge | |
|--------------------->|---------------------->|
| | SH + EE + CRT + |
| | facts_attestation |
|<---------------------|<----------------------|
| | |
| Verify Evidence | |
| Derive psk_attest | |
| Exporter + CN1,CN2 | |
| Finished NOT sent | |
| | |
|- - ABORT Session 0.5 - - - - - - - - - - - - |
|- - - Session 1.0: PSK-DHE Resume - - - - - - |
| (new TCP connection) |
| |
| CH2 + PSK binder |
| + 0-RTT EarlyData |
| ============================================>|
| <=========================================== |
| |
Figure 4: Split-Session Alternative: Bootstrap + PSK-DHE Resume
The EKU-based design is the practical extension of this concept: it
replaces the connection tear-down and PSK-DHE resumption with an in-
band EKU exchange, saving one TCP round-trip (SYN/SYN-ACK) plus the
second ClientHello flight. Both produce equivalent post-rotation
security. The split-session variant is useful for legacy stacks
without EKU support.
5. Key Schedule Integration
FACTS integrates with the TLS 1.3 key schedule at two points: the
Early Secret (for PSK binder validation) and the Extended Key Update
(for traffic key rotation).
Ritz Expires 2 September 2026 [Page 11]
Internet-Draft FACTS-TLS March 2026
5.1. Early Secret Binding
CN1 is used to derive a PSK that feeds into the Early Secret
computation, enabling PSK binder validation in the ClientHello.
PSK = HKDF-Extract(salt=0, IKM=CN1)
Early Secret = HKDF-Extract(salt=0, IKM=PSK)
binder_key = Derive-Secret(Early Secret, "res binder", "")
binder = HMAC(binder_key, Transcript(ClientHello_truncated))
5.2. psk_attest Derivation
Both peers derive the attestation key material from the concatenation
of both challenge nonces:
psk_attest = HKDF-Expand-Label(
HKDF-Extract(salt=0, IKM=CN1 || CN2),
"facts:v1:psk", "", Hash.length)
psk_attest serves two purposes: it encrypts Evidence during the
handshake (via AEAD), and it is injected into the EKU key schedule
after Evidence appraisal.
5.3. AAD Construction
Two distinct AAD values are used, one per HPKE operation. Both MUST
be computed as specified here; deviations invalidate the session-
binding properties of the protocol.
*aad_ct* — used when sealing CN1 in facts_challenge (ClientHello):
aad_ct = Hash(pubKEM_S || ClientHello.random || NegotiationOffer)
This binds the CN1 ciphertext to the target server's KEM key, the
client's fresh random, and the negotiated parameters. An adversary
cannot replay the ciphertext to a different server or across
sessions.
*aad_ee* — used when sealing CN2 in facts_challenge
(EncryptedExtensions):
aad_ee = Hash(ClientHello || ServerHello)
This binds the CN2 ciphertext to the full handshake transcript up to
that point (log_SH). The CN2 ciphertext is therefore specific to the
handshake in flight and cannot be transferred to any other session.
Ritz Expires 2 September 2026 [Page 12]
Internet-Draft FACTS-TLS March 2026
Implementations MUST use the negotiated handshake hash algorithm for
both computations. The NegotiationOffer in aad_ct is the offer value
from the key exchange negotiation as carried in the ClientHello.
6. Evidence Binding
The attester binds the TEE Evidence to the TLS session by including
session-specific data in the TEE-signed attestation report.
6.1. Report Data Construction
rdata = SHA-256(pubIK_S || CN1 || CN2 || pubKEM_C)
The report data (rdata) binds the Evidence to both the attester's
identity key, the mutually exchanged nonces and the Client's own
ephemeral per-session pubKEM KEM.
7. Extended Key Update with PSK Injection
After Evidence appraisal succeeds, the client initiates an Extended
Key Update [I-D.ietf-tls-extended-key-update] that injects psk_attest
into the key schedule, rotating the traffic keys to values that
incorporate attestation-derived keying material.
7.1. Procedure
1. The client generates an ephemeral key pair for the EKU exchange:
(eku_x, g^eku_x).
2. The client sends an EKU request containing g^eku_x.
3. The server generates its ephemeral key pair: (eku_y, g^eku_y).
4. Both peers compute the EKU Diffie-Hellman shared secret: eku_dh =
DH(g^eku_x, eku_y) (equivalently, DH(g^eku_y, eku_x)).
5. Both peers construct the combined input keying material:
combined_ikm = eku_dh || psk_attest
6. Both peers derive new traffic keys:
combined_ikm = eku_dh_shared || psk_attest
stored_secret = Derive(main_secret_N, "derived", "")
main_secret_N+1 = HKDF-Extract(stored_secret, combined_ikm)
eku_cts = Derive(main_secret_N+1, "c_app_traffic_N+1", eku_log)
eku_sts = Derive(main_secret_N+1, "s_app_traffic_N+1", eku_log)
Ritz Expires 2 September 2026 [Page 13]
Internet-Draft FACTS-TLS March 2026
Figure 5: FACTS Key Schedule for Extended Key Update
main_secret_N
|
Derive(main_secret_N, "derived", "")
|
stored_secret
| (eku_dh || psk_attest)
| |
+--------> HKDF-Extract(stored, combined_ikm)
|
main_secret_N+1
/ \
' '
Derive Derive
"c_app_traffic_N+1" "s_app_traffic_N+1"
| |
eku_cts eku_sts
Figure 6: EKU Key Schedule with PSK Injection
Because combined_ikm includes psk_attest, which requires knowledge of
CN2, any entity that cannot derive CN2 (because it lacks privKEM_C to
unseal the server's Ctx2) cannot compute main_secret_N+1 or any
traffic keys derived from it.
7.2. Interaction with draft-ietf-tls-extended-key-update
The PSK injection mechanism defined in this section extends the EKU
key schedule specified in [I-D.ietf-tls-extended-key-update]. The
standard EKU derivation uses only the DH shared secret as IKM; FACTS
concatenates psk_attest to the DH shared secret before extraction.
All other aspects of the EKU exchange (message formats, transcript
construction, key switch timing) remain as specified in
[I-D.ietf-tls-extended-key-update].
8. Extension Definitions
8.1. The facts_hello Extension
The facts_hello extension is carried in the ClientHello and serves as
the capability signal for FACTS. Its presence indicates that the
client supports the FACTS protocol and is prepared to send
facts_challenge. It optionally carries a hw_id hint that identifies
the hardware platform, enabling the CA or Verifier to select the
correct endorsement key bundle, manufacturer reference values, and
appraisal policy before the attestation quote arrives.
Ritz Expires 2 September 2026 [Page 14]
Internet-Draft FACTS-TLS March 2026
enum {
facts_hello_v1(1),
(255)
} FactsHelloVersion;
enum {
no_hw_id(0),
hw_id_present(1),
(255)
} FactsHelloFlags;
struct {
FactsHelloVersion version; /* MUST be facts_hello_v1 */
FactsHelloFlags flags;
select (FactsHello.flags) {
case hw_id_present:
opaque hw_id<1..2^16-1>; /* opaque platform identifier */
case no_hw_id:
/* empty */
};
} FactsHello;
version MUST be facts_hello_v1. Servers that do not recognize the
version MUST ignore the extension.
hw_id is an opaque value whose encoding is platform-specific. It is
not a credential and is not secret. It is transmitted in the clear
in ClientHello. Deployments with elevated privacy requirements
SHOULD use no_hw_id and rely on the facts_attest_req context for
platform identification, or deliver platform identity inside the
encrypted facts_attestation payload instead.
8.2. The facts_challenge Extension
The facts_challenge extension carries HPKE-sealed challenge nonces.
It appears in two messages with distinct structures and HPKE modes.
8.2.1. ClientHello Variant
struct {
opaque initiator_id<0..2^16-1>; /* ID_C: connecting peer identity */
opaque pubKEM_C<1..2^16-1>; /* ephemeral per-session KEM public key */
opaque ct<1..2^16-1>; /* sealed CN1 */
} FactsChallengeClient;
The ciphertext ct MUST be computed as:
Ritz Expires 2 September 2026 [Page 15]
Internet-Draft FACTS-TLS March 2026
/* Runtime flow — HPKE Mode 0 (RFC 9180 §5.1) */
ct = HPKE-Seal(plaintext=CN1, aad=aad_ct, pkR=pubKEM_S)
/* Enrollment flow — Auth HPKE Mode 2 (RFC 9180 §5.2.1) */
ct = AuthHPKE-Seal(plaintext=CN1, aad=aad_ct, pkR=pubKEM_S, skS=privLTK_C)
where aad_ct is computed per Section 5.3.
The server MUST verify that pubKEM_C is a valid public key for the
negotiated KEM group before proceeding.
8.2.2. EncryptedExtensions Variant
struct {
opaque ct<1..2^16-1>; /* sealed CN2 */
} FactsChallengeServer;
The ciphertext ct MUST be computed as:
/* Runtime flow — HPKE Mode 0 */
ct = HPKE-Seal(plaintext=CN2, aad=aad_ee, pkR=pubKEM_C)
/* Enrollment flow — Auth HPKE Mode 2 */
ct = AuthHPKE-Seal(plaintext=CN2, aad=aad_ee, pkR=pubKEM_C, skS=privIK_S)
where aad_ee is computed per Section 5.3.
The facts_challenge extension in EncryptedExtensions MUST NOT appear
unless the corresponding facts_challenge was present in the
ClientHello. Servers that receive facts_challenge in ClientHello
without a facts_hello extension MUST abort with missing_extension.
8.3. The facts_attestation Extension
The facts_attestation extension is carried in the Certificate message
and delivers the encrypted TEE Evidence along with the self-signed
key binding. It is the sole extension defined by this document that
is permitted in the Certificate message.
struct {
opaque pubIK<1..2^16-1>; /* attester's identity public key */
opaque selfsign<1..2^16-1>; /* sign(privIK, (pubIK || encEvidence)) */
opaque encEvidence<1..2^16-1>; /* AEAD{CMW-wrapped quote}_{psk_attest} */
} FactsAttestation;
pubIK MUST match the public key in the Certificate's leaf entry. The
client MUST abort with illegal_parameter if they differ.
Ritz Expires 2 September 2026 [Page 16]
Internet-Draft FACTS-TLS March 2026
selfsign is a signature over the concatenation of pubIK and
encEvidence, produced by privIK. It binds the identity key to the
encrypted Evidence payload within the same Certificate message,
preventing substitution of one attester's Evidence under another
attester's certificate.
encEvidence is the attestation quote encrypted under psk_attest using
AEAD (ChaCha20-Poly1305 per [RFC8439]). The plaintext is a RATS CMW-
wrapped Evidence payload per [I-D.ietf-rats-msg-wrap].
9. Enrollment
Certificate enrollment has a foundational chicken-and-egg problem in
TEE environments: a client needs credentials to authenticate to a CA,
but obtaining credentials is the reason it is connecting to the CA in
the first place. FACTS uses the mTLS handshake wire format to
deliver the client's X.509 certificate over a channel that is
cryptographically proven to terminate at the verified hardware
boundary: the CA's challenge nonce (CN2) is sealed to the client's
ephemeral pubKEM_C, the client's TEE evidence binds that nonce and
the client's fresh pubLTK_C in the hardware-signed quote, and the
resulting certificate arrives over traffic keys that only a party
holding privKEM_C could have derived.
Client Server
| [Pre-handshake ...]
| - - - - - - - - - - - - - - - - - - - - - - - - - -|
| |
| - - - - - - - - - - - mTLS 1.3 - - - - - - - - - - |
| |
| [1] {CertificateRequest} |
| <------------------------------------------------- |
| |
| [2] Decapsulate CN2 | \
+---------------------------------------+ | |
| hpkeOpen(cn2_ct, aad_ee, privKEM_C) | | [mTLS Attestation]
| `psk_attest` = derive(CN1, CN2) | | |
+---------------------------------------+ | /
| |
| [3] {Certificate} |
| + facts_attestation |
| + (pubIK, selfsign, |
| + AEAD{quote}_{psk_attest}) |
| <------------------------------------------------- |
| |
| [4] Verify Certificate |
+---------------------------------------+ |
| verify(pubCA, identity_doc, sig) | |
Ritz Expires 2 September 2026 [Page 17]
Internet-Draft FACTS-TLS March 2026
| attest_open(encQuote, `psk_attest`) | |
| verify(pubAK, dataSign, sig) | |
| check hash(pubIK,CN1,CN2,pubKEM_C) | |
+---------------------------------------+ |
| |
| [5] {CertificateVerify} |
| <------------------------------------------------- |
| |
| [6] {ServerFinished} |
| <------------------------------------------------- |
| |
| [7] {Certificate} |
| + facts_attestation |
| + (pubIK, selfsign, |
| + AEAD{client_quote}_{psk_attest}) |
| -------------------------------------------------> |
| |
| [8] Verify Client Cert |
| +------------------------------+
| | attest_open(client_encQuote, |
| | psk_attest) |
| | verify(pubAK, dataSign, sig) |
| | check hash(pubIK_S, CN1, |
| | CN2, pubKEM_C) |
| +------------------------------+
| |
| [9] {CertificateVerify} |
| -------------------------------------------------> |
| |
| [10] {ClientFinished} |
| -------------------------------------------------> |
| - - - - - - - - - Post Handshake - - - - - - - - - |
| |
| [I-D.ietf-tls-extended-key-update, |
| (requires EKU-PSK extension) |
| |
| [11] {EKU Request} =========================> |
| [12] {EKU Response} <========================= |
| |
| <===============================================> |
| [13] Application Data | \
| + issued AR (ID_C, pubIK_C, pubKEM_C) | |
| [14] Periodic re-Attestation health checks | [Attestation
| | Result]
| [e.g., I-D.fossati-seat-expat] | |
| <===============================================> | /
| |
Ritz Expires 2 September 2026 [Page 18]
Internet-Draft FACTS-TLS March 2026
Figure 7: Attestation over mTLS supplying RATS AR
9.1. The facts_attest_req Extension
The facts_attest_req extension is carried in the CertificateRequest
message. It signals that the server requires client attestation
before it will release its own Evidence, and communicates the
Evidence format requirements the client must satisfy. CA enrollment
is one application of this signal; privacy-gated disclosure to
unauthenticated clients is another.
9.1.1. Extension Structure
struct {
ExtensionType extension_type = facts_attest_req; /* 0xTBD1 */
opaque extension_data<0..2^16-1>;
} Extension;
struct {
FactsAttestRequestVersion version;
FactsEvidenceFormat supported_formats<1..2^8-1>;
opaque responder_identity<0..2^16-1>; /* responder's ID_S, for rdata binding */
opaque request_context<0..2^8-1>; /* opaque, echoed in client response */
} FactsAttestRequestParams;
enum {
facts_attest_req_v1(1),
(255)
} FactsAttestRequestVersion;
enum {
eat_cbor(1), /* EAT CBOR per RFC 9711 */
eat_json(2), /* EAT JSON */
cmw(3), /* RATS CMW per I-D.ietf-rats-msg-wrap */
csr_attestation(4),/* I-D.ietf-lamps-csr-attestation attribute format */
(255)
} FactsEvidenceFormat;
version identifies the facts_attest_req protocol version. Clients
that do not recognize the version MUST abort with handshake_failure.
supported_formats is an ordered list of Evidence formats the
responder is willing to accept, in descending preference. The client
MUST select the first format it supports. If no common format
exists, the client MUST abort with handshake_failure.
Ritz Expires 2 September 2026 [Page 19]
Internet-Draft FACTS-TLS March 2026
responder_identity carries the responder's ID_S value as it appears
in its Identity Document. The client MUST verify this matches the
ID_S bound in the pre-fetched Identity Document. This closes the
identity confirmation loop: the responder explicitly asserts its
identity inline rather than relying solely on the certificate chain.
request_context is an opaque value chosen by the responder. The
client MUST echo it verbatim in its response. It serves as a
lightweight correlation handle and MAY encode responder-internal
state such as a request identifier or policy selector. It MUST NOT
be used as a freshness mechanism; freshness is provided by CN1 and
CN2.
9.1.2. Server Behavior
A server sending facts_attest_req in CertificateRequest:
1. MUST include facts_challenge in EncryptedExtensions. A
facts_attest_req without a corresponding facts_challenge in
EncryptedExtensions is a protocol error; the client MUST abort
with missing_extension.
2. MUST deliver a valid X.509 certificate in its own Certificate
message.
3. MUST omit facts_attestation from its own Certificate message.
Server Evidence delivery is deferred to post-handshake Exported
Authenticators [I-D.fossati-seat-expat] once the client has been
verified. See Section 12.4.
9.1.3. Client Behavior
Upon receiving a CertificateRequest containing facts_attest_req, the
client:
1. Verifies version is supported.
2. Selects an Evidence format from supported_formats.
3. Verifies responder_identity matches the pre-fetched Identity
Document.
4. Derives psk_attest from CN1 and CN2 per Section 5.
5. Produces TEE Evidence bound to the session parameters, encrypts
it under psk_attest, and delivers it in facts_attestation within
its Certificate message per Section 8.3.
Ritz Expires 2 September 2026 [Page 20]
Internet-Draft FACTS-TLS March 2026
The enrollment-specific client steps (key pair generation, CRTEnroll
construction, rdata binding), defined earlier in this section, are a
specific application of this general mechanism.
A client that is unable or unwilling to attest MUST send an empty
Certificate message and MUST NOT send facts_attestation. The server
MUST then abort with certificate_required.
9.1.4. Relationship to cert_req_context
The standard TLS 1.3 CertificateRequest carries a
certificate_request_context field that the client echoes in its
Certificate message to prevent replay across connections. The
request_context in facts_attest_req is distinct from and
supplementary to this field. Both MUST be echoed. Implementations
MUST NOT conflate them.
10. EAT/AR Claims as Identity Documents
FACTS uses two identity documents to convey device identity and
verifier appraisal: an Entity Attestation Token (EAT) [RFC9711]
produced by the attesting device, and an Attestation Result (AR)
produced by the verifier. The EAT is signed by the device
attestation key (privAK). The AR is signed by the verifier under a
separate trust anchor.
Both documents MAY be serialized in any format supported by the
negotiated FactsEvidenceFormat; JWT serialization is one valid
option. The claims and key binding structures defined in this
section apply regardless of serialization format.
The AR's cnf-based key binding follows the same proof-of-possession
pattern established for OAuth token binding via mutual TLS [RFC8705]
and DPoP [RFC9449], extended with an attested_kem claim that provides
a second, independent proof-of-possession channel through HPKE nonce
encapsulation.
10.1. EAT Structure
The EAT payload MUST include the following FACTS-specific claims:
Ritz Expires 2 September 2026 [Page 21]
Internet-Draft FACTS-TLS March 2026
struct {
string sub; // Stable device identifier bound to pubIK and pubKEM
uint64 iat;
uint64 nbf;
uint64 exp;
bytes eat_nonce; // SHA-256(pubIK_S || CN1 || CN2 || pubKEM_C),
// base64url-unpadded;
array keys; // JWKS array carrying exactly two JWK entries
string eat_profile; // EAT profile identifier per RFC 9711
} EatClaims;
All other claims MUST conform to [RFC9711].
eat_nonce carries the session binding commitment defined in
Section 6. Its value MUST be the base64url-unpadded encoding of SHA-
256(pubIK_S || CN1 || CN2 || pubKEM_C). Implementations MUST NOT
place a verbatim verifier challenge in this field. How this value is
conveyed to the underlying platform attestation primitive is defined
in per-platform companion documents.
The keys member is a JWKS array [RFC7517] carrying exactly two JWK
entries:
keys: [
{ "kty": "OKP", "crv": "Ed25519", "use": "sig",
"kid": "pubIK_S", "x": "<pubIK key material>" },
{ "kty": "OKP", "crv": "X25519", "use": "enc",
"kid": "pubKEM_S", "x": "<pubKEM key material>" }
]
The first entry carries pubIK_S with "use": "sig" and the second
carries pubKEM_S with "use": "enc". Both MUST use the OKP key type
per [RFC8037]. The EAT presents these keys as part of the device's
attested evidence; they are bound to the platform measurements by the
TEE's signature over the complete EAT.
Platform-specific EAT claims (ueid, oemid, hwmodel, hwversion,
swname, swversion, secboot, dbgstat, and claims defined by the
applicable attestation profile such as PSA IoT) MAY be included and
are interpreted per the applicable platform profile.
10.2. AR Structure
The AR is issued by the verifier during enrollment alongside the
X.509 certificate. It enables the passport model [RFC9334] for
subsequent FACTS handshakes, permitting the device to present a
cached attestation result without a live background-check round-trip
to the verifier.
Ritz Expires 2 September 2026 [Page 22]
Internet-Draft FACTS-TLS March 2026
The AR payload MUST include:
struct {
string iss; // Verifier identity
string sub; // MUST match sub from the appraised EAT
string aud; // Intended relying party audience
object cnf; // Confirmation claim per RFC 7800
object attested_kem; // Attested encapsulation key
} ArClaims;
The cnf claim [RFC7800] MUST contain a jwk member carrying a single
JWK entry [RFC7517] with "use": "sig" carrying pubIK_S:
"cnf": {
"jwk": { "kty": "OKP", "crv": "Ed25519", "use": "sig",
"kid": "pubIK_S", "x": "<pubIK key material>" }
}
A relying party that receives an AR MUST verify that the cnf.jwk key
matches the public key presented in the TLS Certificate message.
This is the standard proof-of-possession confirmation:
CertificateVerify proves the server holds the private key
corresponding to the confirmed public key.
The attested_kem claim carries the encapsulation key as a standalone
JWK with "use": "enc":
"attested_kem": {
"kty": "OKP", "crv": "X25519", "use": "enc",
"kid": "pubKEM_S", "x": "<pubKEM key material>"
}
This key is the target for the client's HPKE-sealed challenge nonce
(CN1) in the facts_challenge extension. Successful unsealing by the
server constitutes proof-of-possession of the attested encapsulation
key. Additional appraisal claims are implementation-specific and out
of scope for this document.
11. Security Considerations
11.1. Idealized deployment topology assumptions
Ritz Expires 2 September 2026 [Page 23]
Internet-Draft FACTS-TLS March 2026
.----------------------------------------------.
| |
| .--------------------. .-----------------. |
| | Machine 1 (ID_HW1) | | ID_HW2 | |
| | privIK_1 | | privIK_2 | |
| | | | | |
| | +------+ +------+ | | +------+ | |
| | | VM1 | | VM2 | | | | VM n | ... | |
| | |prIK | |prIK | | | |prIK | | |
| | |prKEM | |prKEM | | | |prKEM | | |
| | +------+ +------+ | | +------+ | |
| | | | | |
| '---------+----------' '---------+-------' |
| ^ ^ |
| | shared | shared |
| | | |
| .-----------------------------. |
| | Manufacturer/CSP A | |
| | privAK_A | |
| '-----------------------------' |
| |
| .------------------------. |
| | Manufacturer/CSP B | |
| +----| | |
| | | privAK_B | |
| v '------------------------' |
| .--+----------------------------------. |
| | Machine n (ID_HWn) privIK_n | |
| | | |
| | +------+ +------+ +------+ | |
| | | VM1 | | VM2 | | VM n | ... | |
| | |prIK | |prIK | |prIK | | |
| | |prKEM | |prKEM | |prKEM | | |
| | +------+ +------+ +------+ | |
| '-------------------------------------' |
'----------------------------------------------'
Figure 8: Infrastructure Topology
11.2. Threat Model
FACTS is designed to mitigate compromise under adversarial
conditions:
* The adversary is an active MitM: they can intercept, inject,
modify, and replay protocol messages on the network.
Ritz Expires 2 September 2026 [Page 24]
Internet-Draft FACTS-TLS March 2026
* The distribution channel for AR is untrusted and may serve
attacker-controlled content (such as DNS without DNSSEC).
* Various states of compromise are tested including combinations
where privAK is compromised while privIK and privKEM are secured,
or when privIK and privKEM are compromised but privAK holds.
11.2.1. ProVerif model (Work in Progress)
A comprehensive ProVerif model, adapted from the open-source release
of the [ID-Crisis] formal analysis of [I-D.fossati-tls-attestation]
has been extended to evaluate the security properties of FACTS over
TLS 1.3 [FACTS-ProVerif].
11.3. Key Separation
The attacks demonstrated in [ID-Crisis] arise from using a single key
for both TLS authentication and attestation binding, enabling an
adversary to relay evidence across sessions. FACTS separates these
roles:
* The IK signs the TLS transcript (CertificateVerify) and the
selfsign binding. Compromise of privIK enables TLS impersonation
but does not yield a valid quote.
* The EK decapsulates challenge nonces and enables psk_attest
derivation. Compromise of privKEM enables decryption of the quote
but does not enable transcript forgery.
* The AK signs the TEE quote. Compromise requires breaching the
hardware security boundary.
An adversary holding privKEM and privIK simultaneously can
impersonate the TLS layer but cannot produce a quote with valid rdata
for a session they did not participate in, because rdata binds
(pubIK, CN1, CN2, pubKEM_C) and CN2 is sealed to the client's
ephemeral pubKEM_C which the adversary does not control.
11.4. Compound Authentication
The FACTS ProVerif model [FACTS-ProVerif] indicates compound
injective-agreement between the Client and Server Pre-Finish
("Property G-C2") holds even when the private Attestation Key (AK)
has been leaked. This suggests that the compound authentication
property - both for the TLS session and the attestation evidence -
refer to the same endpoint even under privAK compromise.
Ritz Expires 2 September 2026 [Page 25]
Internet-Draft FACTS-TLS March 2026
11.5. Pre-Handshake Identity Binding
The Identity Document distributed via DNS closes the identity/key
separation gap identified in [ID-Crisis]. By binding pubKEM and
pubIK to the server identity under a CA signature before the
handshake begins, the client can verify that the keys used in the
handshake correspond to the expected server identity. An adversary
presenting keys not bound in a valid Identity Document will fail
client verification.
12. Privacy Considerations
12.1. DNS Lookup Exposure
Pre-fetching the Identity Document via DNS reveals the client's
intent to connect to the target server to any observer with
visibility into DNS traffic. This is equivalent to the exposure
present in any DNS resolution prior to TLS establishment.
Deployments with elevated privacy requirements SHOULD use encrypted
DNS (DoH or DoT).
12.2. Evidence Disclosure
The TEE quote is encrypted under psk_attest, which is derived from
the challenge nonces exchanged between the two peers. The quote is
therefore not visible to passive network observers. The client
obtains the decrypted quote after step [9] and appraises it directly
(background-check model per [RFC9334]) or forwards it to a Verifier.
In the latter case, the Verifier learns the server's platform
measurements and authentication timing.
12.3. Identity Document Opacity
The Identity Document carries only public key values and standard JWT
metadata. It does not contain platform measurements, hardware
identifiers, or personally identifiable information. Distribution
via DNS does not create a correlation surface beyond the server's
domain name.
12.4. Conditional Evidence Disclosure
[I-D.fossati-seat-expat] observes that when the server acts as
Attester, it can require client authentication before releasing
Evidence, limiting exposure of hardware-level claims to authorized
clients. This document adopts that principle within the handshake.
Ritz Expires 2 September 2026 [Page 26]
Internet-Draft FACTS-TLS March 2026
In the standard FACTS flow, any client that completes the HPKE
exchange obtains the server's decrypted TEE Evidence. The
facts_attest_req extension (Section 9.1) allows the server to
withhold its own Evidence and require client attestation first.
Server Evidence is subsequently delivered via Exported Authenticators
[I-D.fossati-seat-expat] post-handshake.
Deployments where the server's platform measurements are sensitive
SHOULD use facts_attest_req for connections from unauthenticated or
untrusted clients. The decision to require client-first attestation
is a server-local policy choice.
13. IANA Considerations
13.1. TLS ExtensionType Registry
IANA is requested to register the following entries in the "TLS
ExtensionType Values" registry [RFC8447]:
+=======+===================+=========+===========+=============+
| Value | Extension Name | TLS 1.3 | DTLS-Only | Recommended |
+=======+===================+=========+===========+=============+
| TBD1 | facts_hello | CH | N | Y |
+-------+-------------------+---------+-----------+-------------+
| TBD2 | facts_challenge | CH, EE | N | Y |
+-------+-------------------+---------+-----------+-------------+
| TBD3 | facts_attestation | CT | N | Y |
+-------+-------------------+---------+-----------+-------------+
| TBD4 | facts_attest_req | CR | N | Y |
+-------+-------------------+---------+-----------+-------------+
Table 1
The facts_challenge extension is permitted in both ClientHello (CH)
and EncryptedExtensions (EE). Its structure and HPKE mode differ per
message as specified in Section 8.2. The presence of facts_challenge
in EncryptedExtensions is conditional on its presence in the
corresponding ClientHello, per [RFC8446].
The facts_attestation extension is permitted only in the Certificate
message (CT). It carries an encrypted CMW-wrapped Evidence payload
and a self-signed key binding as specified in Section 8.3.
14. References
14.1. Normative References
Ritz Expires 2 September 2026 [Page 27]
Internet-Draft FACTS-TLS March 2026
[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-tls-extended-key-update]
Tschofenig, H., Tüxen, M., Reddy.K, T., Fries, S., and Y.
Rosomakho, "Extended Key Update for Transport Layer
Security (TLS) 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-extended-key-update-09, 18 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
extended-key-update-09>.
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-14, 13 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-14>.
[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>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
Ritz Expires 2 September 2026 [Page 28]
Internet-Draft FACTS-TLS March 2026
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[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>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/rfc/rfc8439>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[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>.
14.2. Informative References
[FACTS-ProVerif]
Ritz, N., "FACTS: ProVerif Model", March 2026,
<https://github.com/nathanaelritz/formal-spec-id-crisis>.
Ritz Expires 2 September 2026 [Page 29]
Internet-Draft FACTS-TLS March 2026
[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-03, 1 March 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
early-attestation-03>.
[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>.
[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I.,
Deshpande, Y., Niemi, A., and T. Fossati, "Using
Attestation in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-fossati-tls-attestation-09, 30 April
2025, <https://datatracker.ietf.org/doc/html/draft-
fossati-tls-attestation-09>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-22, 11
February 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-csr-attestation-22>.
[ID-Crisis]
Sardar, M. U., Moustafa, M., and T. Aura, "Identity Crisis
in Confidential Computing: Formal Analysis of Attested
TLS", February 2026,
<https://doi.org/10.1145/3779208.3785387>.
[RelayAttacks]
Sardar, M. U., Dubeyko, V., and J. Jacquet, "Relay Attacks
in Intra-handshake Attestation for Confidential Agentic AI
Systems", January 2026,
<https://mailarchive.ietf.org/arch/msg/seat/
x3eQxFjQFJLceae6l4_NgXnmsDY/>.
Ritz Expires 2 September 2026 [Page 30]
Internet-Draft FACTS-TLS March 2026
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/rfc/rfc8705>.
[RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/rfc/rfc9261>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
Acknowledgments
Thanks to Sardar et al. for the open-source release of the Identity
Crisis model and for the detailed relay attack disclosures to the
community. Thank you to the authors and contributors who have worked
tirelessly on the foundational body of work for attested TLS, and for
their insights on the IETF mailing lists that helped shape this
approach. A special additional thanks to Usama Sardar for sharing
valuable time for discussions.
Author's Address
Nathanael Ritz
Independent
Email: ietf@nritz.com
Ritz Expires 2 September 2026 [Page 31]