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

[Joseph Salowey <[e-mail]>]

Phew, catching up on the thread here. I haven't had a chance to dive all
the win to all the messages here, but I think there are a few things that
we should do in the draft:

1. Attestation is an overloaded term that is used differently in different
communities to mean different things.  The architecture document should
point out this difference in how the term is used. I think we could use
some help here in untangling the concepts.  I don't think we can
define/disambiguate all the terms associated with attestation topics in the
WIMSE document, but we should try to point to places where they are
defined.

2. I feel the architecture document should steer clear of getting into the
details of specific Attestation protocols are procedures in either the RATS
or SPIFFE/SPIRE sense of the words. For now I would recommend discussing
these in the separate document.

3. There are lots of security considerations around both uses of
attestation.  I'm not sure that the architecture document is the right
place to capture them, but perhaps some more high level goals or threats
can be discussed in the security considerations.

It looks like there is some constructive work going on in the issues and
PRs in the architecture repo.

Cheers,

Joe

On Sat, Jan 10, 2026 at 11:23 AM Kathleen Moriarty <
[e-mail]> wrote:

> Hi Manu,
>
> I actually had this conversation offline separately with a few people and
> agree it would be good to address. However, we can start somewhere else and
> possibly run it separate from WIMSE.
>
> I’m planning to write a blog and can reach out with a draft.
>
> Yes, what you describe should be solved, and we’ll need to figure out
> where when we have more solid framing.
>
> Best regards,
> Kathleen
>
> Sent from my mobile device
>
> On Jan 10, 2026, at 7:11 AM, Manu Fontaine <[e-mail]> wrote:
>
> 
> Thanks Nathanael.
>
> I was not insisting, I was just suggesting other possible words in
> response to Kathleen's and John's perspectives.
>
> SPIFFE/SPIRE entered the CNCF Sandbox in 2018, and graduated in 2022. They
> were conceived and articulated from a "trusted CSP" perspective. We're now
> in 2026, and the need for hardware-backed assurances is fast becoming
> relevant for many types of workloads, across many industries and supply
> chains. Per its charter, WIMSE wants to "bridge the gaps and ambiguities in
> workload identity problems", so this is an opportunity for the IETF to
> disambiguate from a "better internet" perspective.
>
> Evidence is only admissible in court through a verified unbroken chain of
> custody. Everything else is testimony, which depends on the credibility of
> the witness. Similarly, one can check or validate that claims, attributes,
> or assertions were signed with a certain key, but that doesn't verify
> anything about the provenance, quality, lifecycle, and security of the
> signing key (i.e. its chain of custody). It's only good enough if one
> believes it is.
>
> My personal and professional perspective is that it is not
> counter-productive, nor a needless source of friction, for the IETF to
> start clearly distinguishing evidence vs. claims/attributes, attestation
> vs. assertion, and verification vs. validation, even if words have been
> used more loosely in the past or in the English language.
>
> But again, this is just a suggestion. Thanks.
>
> Best,
> Manu
>
>
>
> On Fri, Jan 9, 2026 at 5:56 PM Nathanael Ritz <[e-mail]>
> wrote:
>
>> I think that if there is a way for a given subject to convey
>> cryptographic evidence of a given expected state to the satisfaction of
>> another party, then the use of “attester” and “verifier” make common sense.
>> SPIFFE/SPIRE uses the concept of “node attestation” and insisting against
>> that terminology in WIMSE feels counter-productive.
>>
>> I do think there is value in being careful about the use of Attester,
>> Verifier, Evidence and those kinds of words as proper nouns.  It makes
>> sense to me that a draft should explain why, (and under what context) they
>> are used as proper nouns if that happens to be the case.
>>
>> But to simply say “attestation is a loaded term, so avoid using it here
>> unless you mean ____” is just going to be a needless source of friction.
>>
>> On Fri, Jan 9, 2026 at 3:06 PM Manu Fontaine <[e-mail]> wrote:
>>
>>> Perhaps WIMSE could use "Assert / Assertion", and RATS could use "Attest
>>> / Attestation"?
>>>
>>> Disambiguating the two is important because of the very different
>>> security and trust models. An assertion made by a software entity is not as
>>> "believable" (verifiable) as hardware-backed attestation.
>>>
>>> Best,
>>> Manu
>>>
>>>
>>>
>>> On Fri, Jan 9, 2026 at 4:12 PM John Kemp <[e-mail]>
>>> wrote:
>>>
>>>> Hi Kathleen,
>>>>
>>>> > El ene 8, 2026, a las 12:36 p.m., Kathleen Moriarty <
>>>> [e-mail]> escribió:
>>>> >
>>>> > WIMSE is not using the terms in this stricter verification sense in
>>>> their drafts for its core work. There is mention of attesting properties
>>>> used to create an identity from information about a workload and the host
>>>> server, but they don't have in scope how those are defined and the
>>>> attestation stated is not necessarily related to confidential computing or
>>>> use of a TPM (or even a vTPM in a TEE). Since the identifiers are not
>>>> defined and not in scope then it follows that attesting them is not in
>>>> scope.
>>>>
>>>> I will start by noting that well before RATS or TCG defined the term
>>>> ‘attestation’, it also had a[t least one] broader English-language meaning:
>>>>
>>>> "the action of formally witnessing or certifying something” (Oxford) or
>>>>
>>>> "an act or instance of attesting something” ([MW])
>>>>
>>>> WIMSE attestation certainly fits within this definition.
>>>>
>>>> I also think that the way that RATS defines the term in RFC 9334 is
>>>> sufficiently broad (I prefer that word to ‘vague’ in this case) to include
>>>> WIMSE cases.
>>>>
>>>> RATS says this about attestation (without explicitly defining it as a
>>>> term):
>>>>
>>>> "In Remote ATtestation procedureS (RATS), one peer (the "Attester")
>>>> produces believable information about itself ("Evidence") to enable a
>>>> remote peer (the "Relying Party") to decide whether or not to consider that
>>>> Attester a trustworthy peer. Remote attestation procedures are facilitated
>>>> by an additional vital party (the "Verifier”).”
>>>>
>>>> I would argue that WIMSE could quite reasonably suggest that its own
>>>> architectural entities could perform the roles of Attester, Verifier and
>>>> Relying Party, so by the above definition, I would say we are covered.
>>>>
>>>> In Henk’s prior message, I heard him suggest that we should use neither
>>>> Attestation nor Evidence as terms in WIMSE.
>>>>
>>>> I think we in WIMSE have some choices:
>>>>
>>>> 1. Remove the use of the term attestation and use a different term
>>>> entirely. I think this would be difficult, because of the existence of the
>>>> English-language term, which I do believe is appropriate and meaningful.
>>>> 2. Use the term ‘attestation’ with its commonly-known English-language
>>>> definition (although that may lead to at least some technical imprecision
>>>> and some confusion with RATS)
>>>> 3. Use the term and refer to RATS, re-using only the roles of the
>>>> entities involved in the process, and not the technical means by which they
>>>> achieve those roles.
>>>>
>>>> Personally, I lean towards (2) with an explicit note to say that we _do
>>>> not_ mean RATS attestation, even though we certainly have similar parties
>>>> to the process of attestation (Attester, Verifier and Relying Party).
>>>>
>>>> Regards, -johnk
>>>>
>>>> [MW] https://www.merriam-webster.com/dictionary/attestation
>>>>
>>>> _______________________________________________
>>>> RATS 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]
>>>
>> --
> WIMSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>