MIME-Version: 1.0
References: 
 <178083833289.681442.6533944152767384674@dt-datatracker-6784c69984-gl6cv>
 <AMBPR07MB11383CB81128162D4125806A3AB1F2@AMBPR07MB11383.eurprd07.prod.outlook.com>
 <CAFpG3genw-z=YnnzGco4p-8V=b1NAYLT04HgdqVzxAwAnDbp0Q@mail.gmail.com>
In-Reply-To: 
 <CAFpG3genw-z=YnnzGco4p-8V=b1NAYLT04HgdqVzxAwAnDbp0Q@mail.gmail.com>
From: Nathanael Ritz <nathanritz@gmail.com>
Date: Mon, 8 Jun 2026 01:43:01 -0600
Message-ID: 
 <CAHxYnaMeOVELqSNYvu2DEmkKVFTQ_h+FkQvyd+oa1Cce05x51w@mail.gmail.com>
To: tirumal reddy <kondtir@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a6cf9f0653b92906"
Message-ID-Hash: MZHQITOAV24M6BAYA6MVWDY3X3OR6SF5
CC: rats@ietf.org, "seat@ietf.org" <seat@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_FW=3A_New_Version_Notification_for_draft-reddy-ra?=
	=?utf-8?q?ts-key-binding-01=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/5THY2Y4HfUyKuRsL228OT8cOEzE>

--000000000000a6cf9f0653b92906
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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` =E2=80=94 =
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/READ=
ME.md
[3] https://mailarchive.ietf.org/arch/msg/seat/N0a95GUc6XN0LXc2fpxsKm3BbWg/

On Sun, 7 Jun 2026 at 22:46, tirumal reddy <kondtir@gmail.com> 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) an=
d
> 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 a=
n
> 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 Mod=
el
> (separate Key Attestation Token (KAT) to attest the Subject Public Key, a=
nd
> 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=3Ddraft-reddy-rats-key-binding-=
01
>
> Further comments and suggestions are welcome.
>
> Best regards,
> -Tiru
>
>
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Sunday, June 7, 2026 6:49 PM
> To: K Tirumaleswar Reddy (Nokia) <k.tirumaleswar_reddy@nokia.com>; Hannes
> Tschofenig <Hannes.Tschofenig@gmx.net>; Hannes Tschofenig <
> hannes.tschofenig@gmx.net>; Ionut Mihalcea <Ionut.Mihalcea@arm.com>;
> Ionut Mihalcea <ionut.mihalcea@arm.com>; Thomas Fossati <
> thomas.fossati@linaro.org>; K Tirumaleswar Reddy (Nokia) <
> k.tirumaleswar_reddy@nokia.com>
> 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=3Ddraft-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 -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
>

--000000000000a6cf9f0653b92906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Tiru, all,<br><br>Thanks for sharing this draft. I beli=
eve `draft-reddy-rats-key-binding-01` provides useful cryptographic vocabul=
ary and operational modes that I can use to enhance my ongoing formal analy=
sis of intra-handshake attestation as defined in `draft-fossati-seat-early-=
attestation` [0]. As I have already shared with the SEAT WG, I am investiga=
ting the properties of the novel binder construction defined in the Early I=
-D while simultaneously experimenting with RFC 9345 (TLS Delegated Credenti=
als) [1, 2].<br><br>Combined, I believe these concepts provide complementar=
y parts to a complete solution that directly supports your `key-binding pro=
file`:<br><br>* Operationalized architecture (RFC 9345): The long-term WebP=
KI identity key (`LTK`) signs a Delegated Credential, transferring TLS sign=
ing authority to a short-lived, ephemeral TLS Identity Key (`Ephemeral TIK`=
) generated directly inside the TEE.<br><br>* 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 co=
nstrained inside the hardware.<br><br>Currently, my most recent model for d=
raft-fossati-seat-early-attestation-04 maps directly to the `Combined Model=
`. That is, a single `Attestation Key` (`AK`) signs one Evidence token bind=
ing both platform state and the `Ephemeral TIK` to the session simultaneous=
ly, although I think the `Split Model` should also work with the right adju=
stments to my work.<br><br>Under the `Split Model`, the TEE-bound `Ephemera=
l TIK` acts directly as the `Subject Key`. RFC 9345 delegates TLS signing a=
uthority from the external `LTK` to the `Ephemeral TIK`; the `Combined Atte=
station Bundle` (`CAB`) then asserts the hardware security properties that =
make that delegation meaningful. The current model&#39;s `AK` plays the rol=
e of the `KAK` =E2=80=94 it signs the Evidence token asserting the `Ephemer=
al TIK`&#39;s protection properties as the `Subject Key`. I think lifting t=
he platform attestation into a dedicated `PAT` should complete the transiti=
on to the `Split Model`.<br><br>As such, I support the direction this draft=
 is going. I am not sure if I&#39;m in a direct position yet to actively ad=
vocate 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-ke=
y-binding` [3] actually inspired me to experiment with 9345. In any case, t=
his 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 revi=
sion to confirm the mechanics.=C2=A0<br><br>=C2=A0I&#39;ll share any fresh =
feedback that builds on (or deviates from!) these comments if I find anythi=
ng else substantive.<br><br>Cheers,<br>Nathanael<br><br>[0] <a href=3D"http=
s://mailarchive.ietf.org/arch/msg/seat/yjm-i7-0uTyjiZqT3XuUwA13IdI">https:/=
/mailarchive.ietf.org/arch/msg/seat/yjm-i7-0uTyjiZqT3XuUwA13IdI</a><br>[1] =
<a href=3D"https://github.com/nathanaelritz/formal-spec-id-crisis/tree/main=
/TLS-a/fix">https://github.com/nathanaelritz/formal-spec-id-crisis/tree/mai=
n/TLS-a/fix</a><br>[2] <a href=3D"https://github.com/nathanaelritz/formal-s=
pec-id-crisis/tree/main/TLS-a/README.md">https://github.com/nathanaelritz/f=
ormal-spec-id-crisis/tree/main/TLS-a/README.md</a><br>[3]=C2=A0<a href=3D"h=
ttps://mailarchive.ietf.org/arch/msg/seat/N0a95GUc6XN0LXc2fpxsKm3BbWg/">htt=
ps://mailarchive.ietf.org/arch/msg/seat/N0a95GUc6XN0LXc2fpxsKm3BbWg/</a></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sun, 7 Jun 2026 at 22:46, tirumal reddy &lt;<a href=
=3D"mailto:kondtir@gmail.com">kondtir@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote">Hi all,<br><br>=C2=A0 We have submitted a revised version =
of <a href=3D"https://datatracker.ietf.org/doc/draft-reddy-rats-key-binding=
/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-reddy-rats-key-=
binding/</a> to address comments from the WG and to incorporate key aspects=
 of draft-bft-rats-kat.=C2=A0</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">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-en=
tity certificate) and its protection properties within attestation evidence=
. Combined with protocol-level proof of possession from the surrounding pro=
tocol such as TLS, this establishes a cryptographic binding between a priva=
te key and an attested execution environment.=C2=A0=C2=A0<br><br>The key ch=
anges from the previous version are:<br><br>* Added an Architecture section=
 describing two deployment models: a Combined Model (single EAT signed by t=
he Attestation Key) and a Split Model (separate Key Attestation Token (KAT)=
 to attest the Subject Public Key, and a Platform Attestation Token (PAT) t=
hat attests the Key Attestation Key (KAK)).<br><br>* Added a Split Model pr=
ofile with a complete verification procedure, where the PAT attests the KAK=
 public key and its protection properties binding the two tokens.<br><br>Di=
ff: <a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-reddy-rats=
-key-binding-01" target=3D"_blank">https://author-tools.ietf.org/iddiff?url=
2=3Ddraft-reddy-rats-key-binding-01</a></div><div class=3D"gmail_quote"><br=
>Further comments and suggestions are welcome.</div><div class=3D"gmail_quo=
te"><br>Best regards,<br>-Tiru<br><br>
<br>
-----Original Message-----<br>
From: <a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">interne=
t-drafts@ietf.org</a> &lt;<a href=3D"mailto:internet-drafts@ietf.org" targe=
t=3D"_blank">internet-drafts@ietf.org</a>&gt; <br>
Sent: Sunday, June 7, 2026 6:49 PM<br>
To: K Tirumaleswar Reddy (Nokia) &lt;<a href=3D"mailto:k.tirumaleswar_reddy=
@nokia.com" target=3D"_blank">k.tirumaleswar_reddy@nokia.com</a>&gt;; Hanne=
s Tschofenig &lt;<a href=3D"mailto:Hannes.Tschofenig@gmx.net" target=3D"_bl=
ank">Hannes.Tschofenig@gmx.net</a>&gt;; Hannes Tschofenig &lt;<a href=3D"ma=
ilto:hannes.tschofenig@gmx.net" target=3D"_blank">hannes.tschofenig@gmx.net=
</a>&gt;; Ionut Mihalcea &lt;<a href=3D"mailto:Ionut.Mihalcea@arm.com" targ=
et=3D"_blank">Ionut.Mihalcea@arm.com</a>&gt;; Ionut Mihalcea &lt;<a href=3D=
"mailto:ionut.mihalcea@arm.com" target=3D"_blank">ionut.mihalcea@arm.com</a=
>&gt;; Thomas Fossati &lt;<a href=3D"mailto:thomas.fossati@linaro.org" targ=
et=3D"_blank">thomas.fossati@linaro.org</a>&gt;; K Tirumaleswar Reddy (Noki=
a) &lt;<a href=3D"mailto:k.tirumaleswar_reddy@nokia.com" target=3D"_blank">=
k.tirumaleswar_reddy@nokia.com</a>&gt;<br>
Subject: New Version Notification for draft-reddy-rats-key-binding-01.txt<b=
r>
<br>
<br>
CAUTION: This is an external email. Please be very careful when clicking li=
nks or opening attachments. See the URL <a href=3D"http://nok.it/ext" rel=
=3D"noreferrer" target=3D"_blank">nok.it/ext</a> for additional information=
.<br>
<br>
<br>
<br>
A new version of Internet-Draft draft-reddy-rats-key-binding-01.txt has bee=
n successfully submitted by Tirumaleswar Reddy and posted to the IETF repos=
itory.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0draft-reddy-rats-key-binding<br>
Revision: 01<br>
Title:=C2=A0 =C2=A0 Key Attestation for Entity Attestation Tokens (EAT)<br>
Date:=C2=A0 =C2=A0 =C2=A02026-06-07<br>
Group:=C2=A0 =C2=A0 Individual Submission<br>
Pages:=C2=A0 =C2=A0 22<br>
URL:=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/archive/id/draft-r=
eddy-rats-key-binding-01.txt" rel=3D"noreferrer" target=3D"_blank">https://=
www.ietf.org/archive/id/draft-reddy-rats-key-binding-01.txt</a><br>
Status:=C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-reddy=
-rats-key-binding/" rel=3D"noreferrer" target=3D"_blank">https://datatracke=
r.ietf.org/doc/draft-reddy-rats-key-binding/</a><br>
HTML:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.org/archive/id/draft-r=
eddy-rats-key-binding-01.html" rel=3D"noreferrer" target=3D"_blank">https:/=
/www.ietf.org/archive/id/draft-reddy-rats-key-binding-01.html</a><br>
HTMLized: <a href=3D"https://datatracker.ietf.org/doc/html/draft-reddy-rats=
-key-binding" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf=
.org/doc/html/draft-reddy-rats-key-binding</a><br>
Diff:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://author-tools.ietf.org/iddiff?ur=
l2=3Ddraft-reddy-rats-key-binding-01" rel=3D"noreferrer" target=3D"_blank">=
https://author-tools.ietf.org/iddiff?url2=3Ddraft-reddy-rats-key-binding-01=
</a><br>
<br>
Abstract:<br>
<br>
=C2=A0 =C2=A0This document defines an Entity Attestation Token (EAT) profil=
e and a<br>
=C2=A0 =C2=A0new EAT claim that convey the subject public key and its prote=
ction<br>
=C2=A0 =C2=A0properties within attestation evidence.=C2=A0 Combined with pr=
otocol-level<br>
=C2=A0 =C2=A0proof of possession from the surrounding protocol, this establ=
ishes a<br>
=C2=A0 =C2=A0cryptographic binding between a private key and an attested ex=
ecution<br>
=C2=A0 =C2=A0environment.<br>
<br>
=C2=A0 =C2=A0The subject public key is conveyed using the EAT cnf claim def=
ined in<br>
=C2=A0 =C2=A0[RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce =
claim<br>
=C2=A0 =C2=A0defined in [RFC9711].=C2=A0 The proof of possession of the sub=
ject key is<br>
=C2=A0 =C2=A0obtained from the surrounding protocol, such as TLS certificat=
e-based<br>
=C2=A0 =C2=A0authentication or CSR signature verification.=C2=A0 Because th=
e EAT is<br>
=C2=A0 =C2=A0signed by a hardware-backed Attestation Key (AK), successful<b=
r>
=C2=A0 =C2=A0verification of the EAT signature together with protocol-level=
 proof<br>
=C2=A0 =C2=A0of possession establishes a cryptographic binding between the =
private<br>
=C2=A0 =C2=A0key and the attested platform state.=C2=A0 This mechanism addr=
esses key<br>
=C2=A0 =C2=A0substitution attacks that arise when attestation evidence and =
the<br>
=C2=A0 =C2=A0certificate private keys are validated independently.<br>
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
<br>
</div></div>
_______________________________________________<br>
RATS mailing list -- <a href=3D"mailto:rats@ietf.org" target=3D"_blank">rat=
s@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:rats-leave@ietf.org" targ=
et=3D"_blank">rats-leave@ietf.org</a><br>
</blockquote></div>

--000000000000a6cf9f0653b92906--