[Rats] Re: FW: New Version Notification for draft-reddy-rats-key-binding-01.txt

[Nathanael Ritz <[e-mail]>]

Hi Tiru, all,

Thanks for sharing this draft. I believe `draft-reddy-rats-key-binding-01`
provides useful cryptographic vocabulary and operational modes that I can
use to enhance my ongoing formal analysis of intra-handshake attestation as
defined in `draft-fossati-seat-early-attestation` [0]. As I have already
shared with the SEAT WG, I am investigating the properties of the novel
binder construction defined in the Early I-D while simultaneously
experimenting with RFC 9345 (TLS Delegated Credentials) [1, 2].

Combined, I believe these concepts provide complementary parts to a
complete solution that directly supports your `key-binding profile`:

* Operationalized architecture (RFC 9345): The long-term WebPKI identity
key (`LTK`) signs a Delegated Credential, transferring TLS signing
authority to a short-lived, ephemeral TLS Identity Key (`Ephemeral TIK`)
generated directly inside the TEE.

* The data model (draft-reddy): This details the Entity Attestation Token
(EAT) profile, using `cnf` and `key-attributes` claims to cryptographically
prove that specific keys are constrained inside the hardware.

Currently, my most recent model for draft-fossati-seat-early-attestation-04
maps directly to the `Combined Model`. That is, a single `Attestation Key`
(`AK`) signs one Evidence token binding both platform state and the
`Ephemeral TIK` to the session simultaneously, although I think the `Split
Model` should also work with the right adjustments to my work.

Under the `Split Model`, the TEE-bound `Ephemeral TIK` acts directly as the
`Subject Key`. RFC 9345 delegates TLS signing authority from the external
`LTK` to the `Ephemeral TIK`; the `Combined Attestation Bundle` (`CAB`)
then asserts the hardware security properties that make that delegation
meaningful. The current model's `AK` plays the role of the `KAK` — it signs
the Evidence token asserting the `Ephemeral TIK`'s protection properties as
the `Subject Key`. I think lifting the platform attestation into a
dedicated `PAT` should complete the transition to the `Split Model`.

As such, I support the direction this draft is going. I am not sure if I'm
in a direct position yet to actively advocate for referencing RFC 9345 for
TLS+RA integration by way of this draft, but reviewing earlier feedback
from the -00 draft of `draft-reddy-rats-key-binding` [3] actually inspired
me to experiment with 9345. In any case, this is an early analysis, and I
plan to update my current work-in-progress with the specific `Split Model`,
`PAT`, and `KAT` details from the -01 revision to confirm the mechanics.

 I'll share any fresh feedback that builds on (or deviates from!) these
comments if I find anything else substantive.

Cheers,
Nathanael

[0] https://mailarchive.ietf.org/arch/msg/seat/yjm-i7-0uTyjiZqT3XuUwA13IdI
[1]
https://github.com/nathanaelritz/formal-spec-id-crisis/tree/main/TLS-a/fix
[2]
https://github.com/nathanaelritz/formal-spec-id-crisis/tree/main/TLS-a/README.md
[3] https://mailarchive.ietf.org/arch/msg/seat/N0a95GUc6XN0LXc2fpxsKm3BbWg/

On Sun, 7 Jun 2026 at 22:46, tirumal reddy <[e-mail]> wrote:

> Hi all,
>
>   We have submitted a revised version of
> https://datatracker.ietf.org/doc/draft-reddy-rats-key-binding/ to address
> comments from the WG and to incorporate key aspects of draft-bft-rats-kat.
>
> This document defines an EAT profile and a new EAT claim that convey the
> subject public key (e.g., the public key of an end-entity certificate) and
> its protection properties within attestation evidence. Combined with
> protocol-level proof of possession from the surrounding protocol such as
> TLS, this establishes a cryptographic binding between a private key and an
> attested execution environment.
>
> The key changes from the previous version are:
>
> * Added an Architecture section describing two deployment models: a
> Combined Model (single EAT signed by the Attestation Key) and a Split Model
> (separate Key Attestation Token (KAT) to attest the Subject Public Key, and
> a Platform Attestation Token (PAT) that attests the Key Attestation Key
> (KAK)).
>
> * Added a Split Model profile with a complete verification procedure,
> where the PAT attests the KAK public key and its protection properties
> binding the two tokens.
>
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-reddy-rats-key-binding-01
>
> Further comments and suggestions are welcome.
>
> Best regards,
> -Tiru
>
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Sunday, June 7, 2026 6:49 PM
> To: K Tirumaleswar Reddy (Nokia) <[e-mail]>; Hannes
> Tschofenig <[e-mail]>; Hannes Tschofenig <
> [e-mail]>; Ionut Mihalcea <[e-mail]>;
> Ionut Mihalcea <[e-mail]>; Thomas Fossati <
> [e-mail]>; K Tirumaleswar Reddy (Nokia) <
> [e-mail]>
> Subject: New Version Notification for draft-reddy-rats-key-binding-01.txt
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> A new version of Internet-Draft draft-reddy-rats-key-binding-01.txt has
> been successfully submitted by Tirumaleswar Reddy and posted to the IETF
> repository.
>
> Name:     draft-reddy-rats-key-binding
> Revision: 01
> Title:    Key Attestation for Entity Attestation Tokens (EAT)
> Date:     2026-06-07
> Group:    Individual Submission
> Pages:    22
> URL:
> https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-01.txt
> Status:   https://datatracker.ietf.org/doc/draft-reddy-rats-key-binding/
> HTML:
> https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-reddy-rats-key-binding
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-reddy-rats-key-binding-01
>
> Abstract:
>
>    This document defines an Entity Attestation Token (EAT) profile and a
>    new EAT claim that convey the subject public key and its protection
>    properties within attestation evidence.  Combined with protocol-level
>    proof of possession from the surrounding protocol, this establishes a
>    cryptographic binding between a private key and an attested execution
>    environment.
>
>    The subject public key is conveyed using the EAT cnf claim defined in
>    [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim
>    defined in [RFC9711].  The proof of possession of the subject key is
>    obtained from the surrounding protocol, such as TLS certificate-based
>    authentication or CSR signature verification.  Because the EAT is
>    signed by a hardware-backed Attestation Key (AK), successful
>    verification of the EAT signature together with protocol-level proof
>    of possession establishes a cryptographic binding between the private
>    key and the attested platform state.  This mechanism addresses key
>    substitution attacks that arise when attestation evidence and the
>    certificate private keys are validated independently.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>