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

[tirumal reddy <[e-mail]>]

On Mon, 16 Mar 2026 at 12:08, 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.
>

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: [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]
>