Return-Path: X-Original-To: rats@mail2.ietf.org Delivered-To: rats@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3FED1CC0841A for ; Tue, 17 Mar 2026 00:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uoct3URzyHfs for ; Tue, 17 Mar 2026 00:58:19 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 79BC8CC0840F for ; Tue, 17 Mar 2026 00:58:19 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-661d20c9787so7728752a12.0 for ; Tue, 17 Mar 2026 00:58:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773734298; cv=none; d=google.com; s=arc-20240605; b=J7UyVX1v/AOepqyS23tUOkKET5m5fG608/Nb2AqnujQxEfXOpfpryG1MAmr2aiR8ji jFpJlzOok4QZabHEJ7hhdZJjar/gXaawvN+0+CD9880CIOXA+ff8xLQkkA8VsaNIsj6s vocpb2h0Ljv0J80sfKSIHVB4M078w4DLPc3gKGa40gnshqFHI5RsUSNOIHr78VZCd5kT EzV/g1CI/fjoIXt1lsnctDXWdql4ui4DW8v3nXCWZq3fC2La5eVNUcmeV4ZrFT1jhhrW 99QewlGe4/5PXz/tWqHtgO37HSjOkBd0ZX2/Onq1/n6+6L2hw9mVUXTFXLUr9EcCLUmo JYTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=OkUgd1sp4JqsHvzJeJSC3mRuPfKFULyEwp5nEBEO2mo=; fh=LPotQnD97gc3yRyhUJb7JHiaDT6b0e9j+wIcdDz1njE=; b=dcUuLP7Z40hmZnftWnorqJi6/uIs5XYTEAYaJb1v4uNzgudBlfu9kq+rmdMZ+wp7bJ PsQnthvdErzgadt5G8gEF5dWXy4eONUMLKqKDg7A+0FPkLYLV9deiaL/U1ln3mtls12s zhvKFPy7+964INQHHngJdVag4VwwpsazoeRFqFW5siuAshj0GOKOUaUpe9Cp/QFKQY73 VeUlGdy+hX7KHf6IGW0IjnvgaZ+pAa6q9m+rr8BvROloGrI2y9nKeofa0rrO50TKBw3+ Sdjbaxv20FfeiQSuShkoQMJ7zsJMXR5iopCny/7uck3rZqJAWOfNoa6HWAXwbIv+P9Tz RDOA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773734298; x=1774339098; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OkUgd1sp4JqsHvzJeJSC3mRuPfKFULyEwp5nEBEO2mo=; b=MegWWOHGuFnF+S7aafTTiQ/bOA+jZUpm/eeM069elNTnw2BQTfDrlVPVn1bxYShcgJ 8z31VbaAqqB7ImWRRqGuwUrxQ92yQzqEZIX6ltELwx7B2rjnIHRUdjBG2NA1M6z54VwB czh6aU3S3b2GF7u1mqSzVvGHyHHpmr70BK6zWIw3YAtHpui/836pXxV7jucxHUg94N7u 9mjk38NJ9AoaDHFTcNDVoBgJ2u6ls2at+8NxeqbOjq4MeRTHZFFhblYLovyieLn7v3ab EPX5NSlyC2gQeYCn+Pl9MS3N5nnbYiM4godTqzwFSKGS/yx9AlduliwggBE8fV+/TJVn r+wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773734298; x=1774339098; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OkUgd1sp4JqsHvzJeJSC3mRuPfKFULyEwp5nEBEO2mo=; b=nLCM+a3urAq3DQu0OCbdpYUmsRG8h4naL5o/NYSc4yh7Xs6J7+WKeBKbrRdjnt3IiA xS+PMtoPnSKKK8DQDjYdaBkrkVj10zlqD7ry8jRjTKSt6qMCimbAm3Pzj0HJXljk+C99 h+zKFJ2IG/FfpqyO5OTqG0GgOkPzOuKvikVPyKyNJKO3NhTZSdAjJKFcfvRUt+aMxXa4 am5p9/iLovSHn+Hb5nkxXMar9V5Eb6S5bM1sIRBqECvkR1tSa3afOMB336BlMkt/+Gpn dwkG7p5sD7Gm5uMkRu4/9fcTY6bXk3ObAXWyqkzNPkhuk9ebGLbN+6zFoJ2JXoP280mj 4FxQ== X-Forwarded-Encrypted: i=1; AJvYcCURPVk2GcKkvXDS8QWeEwBOcu3QzoP+eMLKoZo9b8tGKrGUSrPeqtCxmQgGnYoQ1UO2ESNa@ietf.org X-Gm-Message-State: AOJu0YwyrlIhCAkwBxkIeNRpssaDrMuRB899LP/zFqY3J33gBIA+gAt1 MsjragS7c/OpFu/QcLLY41vvLbt+YIOgJWjLXAIdjjLPAfOXhogx6qgi0ri07QEJStUsNqmbD4X a5W6XFSn999CrLAZ8p1lNhcVSz+U0fL0= X-Gm-Gg: ATEYQzxVUUk56Ya9sKKzX0VjFFO7d2iDevzPoutzSS0RTDVIg8ry181ceHTbnjAPas4 9I9vG/dQOZZ6Qc6BpAnWZYZYvQ/PBzEkbuNUs6pA55ckWMhl+LGrpm6IzdZbdmyIMMnlRAciLpE i9ZmnqQsctHV6y2JPv3Gmfluv6Ctks3OJ4sOmDsH/6mIonuygJYwyoy4KeE2oCLhAsG1Ub7MbuR xcq2wco49qrzgEf3c5kSToPfE8BVP43KTnrBuadvJMAU+w/fNJlKDlVh+drbpFqeJdUDfe0C1x7 wv0JFit/eHVyP9A3oQ== X-Received: by 2002:a05:6402:50cf:b0:664:3344:fa08 with SMTP id 4fb4d7f45d1cf-66433450814mr7672528a12.10.1773734297958; Tue, 17 Mar 2026 00:58:17 -0700 (PDT) MIME-Version: 1.0 References: <177358299754.193806.3663616865438494971@dt-datatracker-5477d56788-5pkt5> In-Reply-To: From: tirumal reddy Date: Tue, 17 Mar 2026 13:27:41 +0530 X-Gm-Features: AaiRm52TB_Wt2Jgi_ABl0FlvN6uddrA47kEizPgo2d-q8B4Oz5ahnyL8k1fThMo Message-ID: To: Thomas Fossati Content-Type: multipart/alternative; boundary="000000000000c17e72064d33b2a9" Message-ID-Hash: YE2U4FSCCQKOKW5MQ5KLGQIHSC422NVD X-Message-ID-Hash: YE2U4FSCCQKOKW5MQ5KLGQIHSC422NVD X-MailFrom: kondtir@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: seat@ietf.org, rats@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BRats=5D_Re=3A_=5BSeat=5D_FW=3A_New_Version_Notification_for_dra?= =?utf-8?q?ft-reddy-rats-key-binding-00=2Etxt?= List-Id: Remote ATtestation procedureS Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c17e72064d33b2a9 Content-Type: text/plain; charset="UTF-8" On Mon, 16 Mar 2026 at 12:08, Thomas Fossati wrote: > Hi Tiru & Hannes, > > On Sun, 15 Mar 2026 at 15:22, tirumal reddy wrote: > > > > We have published a new draft: > https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.txt. > > > > In certificate enrollment and TLS authentication, the attestation > evidence and the private key used to sign a CSR, or the private key > corresponding to a TLS end-entity certificate, are validated independently, > which can enable key substitution or relay attacks (a threat raised by Paul > in SEAT WG). The threat is discussed in more detail in the Introduction of > the draft. > > > > The draft addresses this by binding the Subject Key to the attested > platform state while leveraging the existing protocol-level proof of > possession, and by defining a key-attributes claim to convey key protection > properties. The mechanism defined in the draft can be used with both the > pre-handshake and post-handshake attestation solution drafts. > > > > Comments and feedback from the WG would be welcome. > > AFAICS, this approach is very similar to the one we developed in the > early days of the attested TLS project, for exactly the same reasons. > (It is captured in draft-kat [1].) > The problem with this approach was that it required the platform to > support an additional root of trust & ABIs, which is impractical in > the general case. In the context of CC, we moved the functionality to > the confidential workload and bound it on top of the existing platform > evidence. I found that a bit ad hoc, but it solved our immediate > problem. I'm not sure that can be easily generalised. This appears to > be a typical IMPDEF (implementation-defined) case, where the developer > must ensure the system hosting the TLS endpoint offers the necessary > primitives and determine how to achieve this. > Thanks for the feedback and the pointer to draft-bft-rats-kat, we discussed it before publishing this draft. The key difference is that this draft does not require an additional root of trust or new ABIs. It works with attestation evidence the platform already produces, with the binding achieved at the protocol layer by using the cnf claim to carry the subject public key in the attestation evidence. This cryptographically binds the subject key to the attested platform state without requiring any new platform primitives. The key-attributes claims are reused from draft-ietf-rats-pkix-key-attestation rather than defining new ones, we are reusing what already exists in CWT-based EAT. The key-attributes claim conveys the protection properties and the relying party makes the trust decision based on its security policy, consistent with the RATS architecture. Cheers, -Tiru > > cheers, t > > [1] https://datatracker.ietf.org/doc/draft-bft-rats-kat/ > > > Best regards, > > - Tiru and Hannes > > > > -----Original Message----- > > From: internet-drafts@ietf.org > > Sent: Sunday, March 15, 2026 7:27 PM > > To: K Tirumaleswar Reddy (Nokia) ; > Hannes Tschofenig ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; K Tirumaleswar Reddy (Nokia) < > k.tirumaleswar_reddy@nokia.com> > > Subject: New Version Notification for draft-reddy-rats-key-binding-00.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-00.txt has > been successfully submitted by Tirumaleswar Reddy and posted to the IETF > repository. > > > > Name: draft-reddy-rats-key-binding > > Revision: 00 > > Title: Key Attestation for Entity Attestation Tokens (EAT) > > Date: 2026-03-15 > > Group: Individual Submission > > Pages: 17 > > URL: > https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.txt > > Status: https://datatracker.ietf.org/doc/draft-reddy-rats-key-binding/ > > HTML: > https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.html > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-reddy-rats-key-binding > > > > > > Abstract: > > > > This document defines a CWT-based Entity Attestation Token (EAT) > > profile and a new EAT claim that cryptographically bind a private key > > used to sign a certificate signing request (CSR), or the private key > > corresponding to an end-entity certificate used for TLS > > authentication, to an attested execution environment. > > > > The subject public key is conveyed using the EAT cnf claim defined in > > [RFC8747], and freshness uses the 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 > > > > > > _______________________________________________ > > Seat mailing list -- seat@ietf.org > > To unsubscribe send an email to seat-leave@ietf.org > --000000000000c17e72064d33b2a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 16 Mar 2026 at 12:08, Thomas Foss= ati <thomas.fossati@linaro.= org> wrote:
Hi Tiru & Hannes,

On Sun, 15 Mar 2026 at 15:22, tirumal reddy <kondtir@gmail.com> wrote:
>
> We have published a new draft: https://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.txt.=
>
> In certificate enrollment and TLS authentication, the attestation evid= ence and the private key used to sign a CSR, or the private key correspondi= ng to a TLS end-entity certificate, are validated independently, which can = enable key substitution or relay attacks (a threat raised by Paul in SEAT W= G). The threat is discussed in more detail in the Introduction of the draft= .
>
> The draft addresses this by binding the Subject Key to the attested pl= atform state while leveraging the existing protocol-level proof of possessi= on, and by defining a key-attributes claim to convey key protection propert= ies. The mechanism defined in the draft can be used with both the pre-hands= hake and post-handshake attestation solution drafts.
>
> Comments and feedback from the WG would be welcome.

AFAICS, this approach is very similar to the one we developed in the
early days of the attested TLS project, for exactly the same reasons.
(It is captured in draft-kat [1].)
The problem with this approach was that it required the platform to
support an additional root of trust & ABIs, which is impractical in
the general case.=C2=A0 In the context of CC, we moved the functionality to=
the confidential workload and bound it on top of the existing platform
evidence.=C2=A0 I found that a bit ad hoc, but it solved our immediate
problem.=C2=A0 I'm not sure that can be easily generalised. This appear= s to
be a typical IMPDEF (implementation-defined) case, where the developer
must ensure the system hosting the TLS endpoint offers the necessary
primitives and determine how to achieve this.

Thanks for the feedback and the pointer to draft-bft-rats-kat, we di= scussed it before publishing this draft.

The key difference is that= this draft does not require an additional root of trust or new ABIs. It wo= rks with attestation evidence the platform already produces, with the bindi= ng achieved at the protocol layer by using the cnf claim to carry the subje= ct public key in the attestation evidence. This cryptographically binds the= subject key to the attested platform state without requiring any new platf= orm primitives. The key-attributes claims are reused from draft-ietf-rats-p= kix-key-attestation rather than defining new ones, we are reusing what alre= ady exists in CWT-based EAT. The key-attributes claim conveys the protectio= n properties and the relying party makes the trust decision based on its se= curity policy, consistent with the RATS architecture.

<= div>Cheers,
-Tiru
=C2=A0

cheers, t

[1] https://datatracker.ietf.org/doc/draft-bft-r= ats-kat/

> Best regards,
> - Tiru and Hannes
>
> -----Original Message-----
> From: in= ternet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Sunday, March 15, 2026 7:27 PM
> To: K Tirumaleswar Reddy (Nokia) <k.tirumaleswar_reddy@nokia.com>; = Hannes Tschofenig <Hannes.Tschofenig@gmx.net>; Hannes Tschofenig <hannes.tschofenig@= gmx.net>; K Tirumaleswar Reddy (Nokia) <k.tirumaleswar_reddy@nokia.com>
> Subject: New Version Notification for draft-reddy-rats-key-binding-00.= txt
>
>
> CAUTION: This is an external email. Please be very careful when clicki= ng links or opening attachments. See the URL nok.it/ext for additional informat= ion.
>
>
>
> A new version of Internet-Draft draft-reddy-rats-key-binding-00.txt ha= s been successfully submitted by Tirumaleswar Reddy and posted to the IETF = repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0draft-reddy-rats-key-binding
> Revision: 00
> Title:=C2=A0 =C2=A0 Key Attestation for Entity Attestation Tokens (EAT= )
> Date:=C2=A0 =C2=A0 =C2=A02026-03-15
> Group:=C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 17
> URL:=C2=A0 =C2=A0 =C2=A0 htt= ps://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.txt
> Status:=C2=A0 =C2=A0https://datat= racker.ietf.org/doc/draft-reddy-rats-key-binding/
> HTML:=C2=A0 =C2=A0 =C2=A0ht= tps://www.ietf.org/archive/id/draft-reddy-rats-key-binding-00.html
> HTMLized: https://datatracker= .ietf.org/doc/html/draft-reddy-rats-key-binding
>
>
> Abstract:
>
>=C2=A0 =C2=A0 This document defines a CWT-based Entity Attestation Toke= n (EAT)
>=C2=A0 =C2=A0 profile and a new EAT claim that cryptographically bind a= private key
>=C2=A0 =C2=A0 used to sign a certificate signing request (CSR), or the = private key
>=C2=A0 =C2=A0 corresponding to an end-entity certificate used for TLS >=C2=A0 =C2=A0 authentication, to an attested execution environment.
>
>=C2=A0 =C2=A0 The subject public key is conveyed using the EAT cnf clai= m defined in
>=C2=A0 =C2=A0 [RFC8747], and freshness uses the EAT nonce claim defined= in
>=C2=A0 =C2=A0 [RFC9711].=C2=A0 The proof of possession of the subject k= ey is obtained
>=C2=A0 =C2=A0 from the surrounding protocol, such as TLS certificate-ba= sed
>=C2=A0 =C2=A0 authentication or CSR signature verification.=C2=A0 Becau= se the EAT is
>=C2=A0 =C2=A0 signed by a hardware-backed Attestation Key (AK), success= ful
>=C2=A0 =C2=A0 verification of the EAT signature together with protocol-= level proof
>=C2=A0 =C2=A0 of possession establishes a cryptographic binding between= the private
>=C2=A0 =C2=A0 key and the attested platform state.=C2=A0 This mechanism= addresses key
>=C2=A0 =C2=A0 substitution attacks that arise when attestation evidence= and the
>=C2=A0 =C2=A0 certificate private keys are validated independently.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> Seat mailing list -- seat@ietf.org
> To unsubscribe send an email to seat-leave@ietf.org
--000000000000c17e72064d33b2a9--