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

[Thomas Fossati <[e-mail]>]

Hi Tiru,

On Tue, 17 Mar 2026 at 08:58, tirumal reddy <[e-mail]> wrote:
> 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 is not what I gathered from the evidence construction described
in §3.2, which states that the EAT claims-set is signed by the AK.
Now, since the AK is defined as follows:

“A cryptographic key, typically hardware-backed, used to sign
attestation evidence that conveys claims about the state of a platform
or trusted execution environment.”

It means that, in order to obtain a signature from the AK, the
functionality (i.e. the evidence claims-set construction) will need to
be integrated into the RoT that holds the AK.  Plus, since the
construction is parameterised on nonce and PK, extending the RoT’s
API/ABI surface will also be necessary.

I can't think of any other way to realise §3.2 as written.

Instead, we (roughly) did the following:

1. Construct the unsigned "key confirmation" claims set (UCCS) within
the confidential VM that hosts the TLS endpoint
2. CBOR encode it
3. Hash the CBOR bytes
4. Supply the computed hash as nonce through the existing platform
attestation ABI
5. Get back the platform evidence
6. Wrap it alongside the UCCS in a CMW collection
7. Ship it to the TLS peer/RP, which would forward it to the verifier

The verifier would then appraise the platform token, verify the
correct binding to the "key confirmation" UCCS via the nonce, extract
the public key and send it back to the RP within an attestation result
that essentially stated: "This public key is bound to the successfully
appraised TEE and you can use it to verify your peer's signature over
the TLS handshake."

The advantage of this design is that it simply reuses existing, common
attestation ABIs (e.g., configfs-tsm, TPM, PSA), which permit a
fixed-size "inblob" parameter.

cheers!

Digression/ramblings (feel free to skip it):

The one described above is an "indirect" attestation from the
_platform_ RoT.  It’s indirect because it requires the verifier to
recognise that a certain reported measurement in the platform
attestation (e.g., that of the confidential VM) corresponds to an
execution environment with the desired “key handling” properties.

If instead there was a standard RoT that provided certain key handling
features (generation, secure storage, signing and non-exportability),
you coudl obtain an attestation statement from that RoT confirming
that you own the key used in the PoP protocol, i.e., something like
“this key is held by me, the RoT, and belongs to the presenter who is
the only one authorised to request signatures using this key."

This would be a "direct" attestation from the _special-purpose_ RoT,
whose attesattion key would be endorsed by the supply chain. This
would allow the verifier to check its claims directly rather than
indirectly via a certain measurement.

I'm not aware of any publicly available RoTs with those features.