[Seat] Re: [Rats] [WIMSE] Re: Re: Re: Re: Follow-up of meeting 122 presentation (Formal proof of insecurity of Intel's RA-TLS and draft-fossati-tls-attestation)

[Nathanael Ritz <[e-mail]>]

I am not sure about WIMSE, and apologies to the WG if it appears that I am
conflating SPIFFE/SPIRE for WIMSE, as that’s not my intention. With that
out of the way, if we use SPIRE as an example of what’s done in industry
right now, their “node attestation” process comes from a SPIRE agent
running a specific plugin that is checked against a policy. Plugin choices
are diverse, to address the specific question about “hardware vs software
‘attestation’”.

For example, a SPIRE agent can “attest” using a Keylime (HW RoT/TPM) plugin
or it can “attest” with a bootstrap bearer-token (join_token), although I
believe using join_tokens are strongly advised against. In any case, if the
“attestation” is accepted, the SPIRE agent on the node is handed a
“verifiable identity” in the form of an SVID (X.509 cert).

There is a separate process where the RBAC policy engine uses “selectors”
to “discover” what kind of privileges the successful node can have, but
that’s checked independently from the initial “node attestation” process.

My opinion to the WG is that I am very much against using “attestation” as
a noun if a node is given some static credential by passing a bearer-token.
As such mechanisms conflate authentication (through possession of an
unbound secret) for authorization, but TOFU is what it is, and that’s the
language used with SPIFFE, regardless of plugin choice, iirc.

The key detail is that the SPIRE plugin system allows both software or
hardware mechanisms for establishing trust and it appears WIMSE aligns with
similar use of language.

- Nathanael

On Fri, Jan 16, 2026 at 2:05 PM John Kemp <[e-mail]>
wrote:

> El ene 16, 2026, a las 3:35 p.m., Muhammad Usama Sardar <
> [e-mail]> escribió:
>
> Could WIMSE clarify which one of the following is intended in its
> attestation?
>
>    1. Software-based attestation *only*
>    2. Any of software-based attestation or hardware-based attestation
>
> If it is #1, then our attacks are completely irrelevant and I'll close my
> PR.
>
> So a simple question for WIMSE is: is hardware-based attestation in scope
> or not?
>
> At the architecture level we’re operating at (not specific
> implementations) I would say that whether it is hardware-based or
> software-based is not relevant. Either are possible and allowed.
>
> If hardware-based attestation is in scope, attacks are in scope.
>
> As I believe has been previously noted, the attacks you are talking about
> are quite specific — to “attested TLS” - I can’t say whether this is the
> correct document since it’s an expired draft, but there is a security
> considerations section of
> https://www.ietf.org/archive/id/draft-fossati-tls-attestation-09.html#name-security-considerations in
> the attested TLS document that would seem the correct place for a
> discussion of those attacks.
>
> In the WIMSE architecture document (the subject of this discussion) we do
> not refer to attested TLS at all, and it would be an implementation detail
> at the level of this document, so I would suggest it is out-of-scope.
>
> If hardware-based attestation is out of scope, I don't really see why
> definition says WIMSE attestation is broader than RFC9334. In this case,
> maybe simply say it is software-based attestation.
>
> Hardware-based attestation is in-scope, but the specific type, or the
> mechanism by which is used (being different from the seven described RATS
> attestation use-cases), is not relevant for the WIMSE architecture
> document, in my opinion.
>
> Regards, -johnk
>
> On 16.01.26 19:54, John Kemp wrote:
>
> WIMSE folks seem to have settled at some definition. Looking at the
> current definition of attestation of WIMSE in PR [1], I have proposed a
> small edit there.
>
> One nit: Definition says "Attestation in WIMSE is intentionally defined
> quite broadly" but I don't see what exactly is broader than RFC9334.
>
> What that specifically means to me is that the WIMSE definition is broader
> than the defined use-cases specifically mentioned in RFC9334.
>
> Well, I don't think that is quite right. RFC9334 never "defined" any use
> case. Sec. 2 says "Reference Use Cases". We don't limit remote attestation
> to these use cases only. The start of Sec. 2 says explicitly:
>
> This section covers a number of representative and generic use cases for
> remote attestation, independent of specific solutions. The purpose is to
> provide motivation for various aspects of the architecture presented in
> this document. Many other use cases exist; this document does not contain a
> complete list. It only illustrates a set of use cases that collectively
> cover all the functionality required in the architecture.
> -Usama
>
>
>