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

[Arndt Schwenkschuster <[e-mail]>]

+1 on Justin asking what is being asked here? Are you asking for the
references to RFC9334 to be removed?

@Usama: A suggestion in the form of a PR would greatly help our
understanding please.

Kind regards,
Arndt

On Tue, Jan 6, 2026 at 3:11 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi Pieter and Justin,
>
> May I ask why the chairs are bypassing my question? Joe as presenter of
> the draft at IETF meeting 123 [0] agreed to remove attestation and
> Pieter as chair saw folks giving double thumbs up. What exactly has
> changed that rough consensus?
>
> On 06.01.26 12:48, Pieter Kasselman wrote:
> > I believe your objection at the start of this thread was to any WIMSE
> > draft (including draft-ietf-wimse-arch-06 and
> > draft-lkspa-wimse-verifiable-geo-fence) which proposes or even implies
> > attested TLS in pre-handshake or intra-handshake attestation.
> Yes, I stand by my words.
> > As Yaroslav pointed out, the WIMSE architecture draft does not define
> > or require attested TLS. Any security guidance given on using attested
> > TLS seems better suited for TLS or SEAT, rather than WIMSE.
>
> It mentions 13xTLS. It mentions 9xattestation. As the terminology
> defines it as consistent with RATS, there are three ways of combining
> the two: pre-/intra-/post-handshake attestation.
>
> > Regarding the use of the term attestation in the WIMSE architecture
> > draft, the WIMSE architecture draft captures the common practice in
> > large scale workload identity deployments that use the concept of
> > attestation to identify a workload, assign an identifier and issue
> > credentials. SPIRE is an example of this as Sorin and others have
> > pointed out, but other implementations follow the same patterns. Not
> > documenting this pattern would disadvantage the community because it
> > has proven an effective and scalable mechanism for managing workload
> > identity lifecycles at very large scale. The draft references the
> > definition of attestation from RFC9683, which seems generic enough and
> > applicable in this case. It also references the term "evidence" as
> > defined in RFC 9334, which is once again narrowly used and appears
> > applicable to what the architecture document attempts to describe.
> > Both definitions are generic and seem like an attempt to use already
> > established terminology rather than redefining it.
> >
> > Are you objecting to re-using the generic terms attestation and
> > evidence as defined in RFC9683 and RFC9334 respectively?
>
> Sorry, I couldn't follow your reasoning of "generic" here, but existing
> definitions of these terms are a concern for me.
>
> -Usama
>
> [0] https://youtu.be/Mv4lgHLxOH4?t=2626
> --
> WIMSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>