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

[Nathanael Ritz <[e-mail]>]

Hi,

If I understand Thomas's concern correctly (and the general presupposition
of key provenance assumed with RATS in general), it is that the proposed
attested key is another silicon-bound RoT that everyone has to figure out
what to do with, how to design it into the hardware/ABIs, and so on. While
I am not involved in HW engineering of such solutions, I'm sure the concern
is valid.

What came to mind for me when reading through the new draft was how the
`key-attributes` claims could be used to enhance trustworthiness for
ephemeral PRF derived keys during TEE-backed enrollment, or effectively
attested-TOFU (such as in support of "authentication in constrained use
cases" per Sec. 4.6 of the SEAT Use-Cases I-D [0]). You can let me know if
this framing would be pushing the original intent behind the draft.

If widespread hardware support later follows, where new RoTs or additional
silicon-bound keys are widely deployed, then the transition from attested
TOFU of an ephemeral PRF key to a proper HW-bound key seems straightforward
to me. But I can imagine this being implementable in practice via software
to start.

In this case, I would imagine these claims would be carried forward in a
Verifier-signed AR which could be used for the passport models of the
proposed SEAT drafts.

Cheers,

-Nathanael

[0]
https://www.ietf.org/archive/id/draft-mihalcea-seat-use-cases-01.html#section-4.6-1

On Mon, 16 Mar 2026 at 00:39, Thomas Fossati <[e-mail]>
wrote:

> Hi Tiru & Hannes,
>
> On Sun, 15 Mar 2026 at 15:22, tirumal reddy <[e-mail]> 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.
>
> cheers, t
>
> [1] https://datatracker.ietf.org/doc/draft-bft-rats-kat/
>
> > Best regards,
> > - Tiru and Hannes
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Sunday, March 15, 2026 7:27 PM
> > To: K Tirumaleswar Reddy (Nokia) <[e-mail]>;
> Hannes Tschofenig <[e-mail]>; Hannes Tschofenig <
> [e-mail]>; K Tirumaleswar Reddy (Nokia) <
> [e-mail]>
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>