[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)

[John Kemp <[e-mail]>]

Thanks Usama,

Just addressing your comment/change on my PR:

> El ene 15, 2026, a las 7:52 p.m., Muhammad Usama Sardar <[e-mail]> escribió:

[…]
> 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. It includes the SPIRE example that is mentioned by Arndt on my PR, and also the existing discussion of those mechanisms in the architecture document itself.
> What is additional to RFC9334 needs to be precisely mentioned explicitly here.
> 
> Attestation of RFC9334 also does not rely on any specific communication protocol. It can be used with TLS, EDHOC, IKEv2, SSH etc. So you don't actually need to say that part, and in my proposed edit, I removed that part. 
I can live with that change, and responded similarly in the PR discussion.
> What exactly do you mean by "implementation"? Is it meant to include software-based attestation vs. hardware-based attestation.
No, not specifically. And I might argue that _all_ implementations are actually software implementations, even if the update mechanisms for the software may be different in some environments ;)
> My proposed edit is under this assumption. If there is something in addition to that, please specify that to disambiguate as cleanly as possible.
The architecture may be implemented in different ways. That’s all. I don’t think the additional statement about software is required, since that is already allowed by the existing text.
> Now, the definition is broader than attestation of RFC9334, i.e., attestation of RFC9334 remains explicitly in scope.
> 
This remains my biggest question - whether to reference RFC9334 _at all_? 

If RFC9334 was intended to specifically limit implementations to those using some kind of trusted hardware, then I believe we should not reference it at all. Is there a RATS expert here who would care to comment about that?

However, the broad definition of attestation currently in 9334, and the entities described therein, is _still_ relevant for WIMSE — at the architectural level at least. I’d love to reuse it, if someone can confirm that RFC9334 doesn’t limit its text to trusted hardware attestation only?

Regards, - johnk
[1] https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/111