[Rats] Re: Review of EAT DA

[Ionut Mihalcea <[e-mail]>]

Hi Mathieu and Thomas,

Thank you for the thorough reply!

Please see a few comments inline with [IM].

________________________________
From: Mathieu Poirier <[e-mail]>
Sent: Wednesday, June 10, 2026 9:15 PM
To: Ionut Mihalcea <[e-mail]>
Cc: [e-mail] <[e-mail]>; rats <[e-mail]>; nd <[e-mail]>; Thomas Fossati <[e-mail]>; Mathieu Poirier <[e-mail]>
Subject: Re: Review of EAT DA

Hi Ionut,

Many thanks for the thorough review.

Thomas and I have jointly formulated the comments inline.

On Fri, 5 Jun 2026 at 04:49, Ionut Mihalcea <[e-mail]> wrote:
>
> Hi editors,
>
> This is a review of draft-poirier-rats-eat-da-09.
>
> The draft fills in an important gap, so it's great to see progress. The document is well organised, but the fact that it has to lean quite heavily on external documents makes it terse, particularly when describing claims.
>

Yes, we assume readers have a good understanding of the SPDM and TDISP
protocols, or that their specifications are close at hand.

> Some questions / observations below:
>
> * How are SPDM measurement-only tokens supposed to work? Do they have no signature coming from the device? I can see that you talk about the DAT being an UCCS, but it seems the DAT itself is the UCCS, covered by the Lead attester signature placed on the enclosing CMW. Is there a similar "pattern" between SPDM measurement-only tokens and the DAT?
>

By "measurement-only", we assume you mean the case where the "signature"
attribute is omitted from the SPDM measurements.  Assuming that is the
scenario you have in mind, the idea is that the lead attester/SPDM
requester has verified the SPDM signature locally and is satisfied with
it.  It then repackages the measurements into a bunch of SPDM
measurement items, assemble the DAT and sign it, either directly or,
more likely, as part of a CMW collection (as per §4.2).
(This is the "DAT as attestation result profile" point that MCR made in
his review.)

[IM] Yeah, agree with MCR's view, but it seems as though in some cases the DAT would be treated as AR and sometimes as Evidence (unless I'm misunderstanding). Don't know if there's a clear separation between those two cases, or if there needs to be.

> * For SPDM tokens you can carry certificates - is there a need to provide (or reference) guidance (in SC) for how validation should happen?
>

The certificate model (including validation) is defined by SPDM [1].
While there seems to be nothing exceptional beyond what is already
prescribed by §6 of RFC5280, it is probably worth adding a reference.

[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP2058_1.3.0.pdf#page=22

> * Also, something that bridges the security and privacy considerations sections: knowing that some victim workload X and an attacker-controller workload Y both use different interfaces on the same device, or that Y has access to a device (interface) previously used by X, could be leveraged by the attacker for side-channel attacks.
>

For this to happen, the device's implementation would have to be
faulty and/or the TDISP implementation not meeting the security
requirements outlined in the specification.  Both are possible - we
will note this in the security considerations.

> * In the intro you say "Such capabilities prevent execution environments or software components that are untrusted by the TVM (including other TVMs and the host hypervisor) from accessing or controlling a device that has been assigned to the TVM." This is not strictly correct for cases where devices have multiple interfaces which can be assigned separately.
>

I suppose this depends on how you interpret the term "device".  I think
the "virtual private" device abstraction provided by TDISP (called
"virtual function" in the PCIe spec) is what is meant here.  However, if
you interpret it as the physical device, then I agree with you.  It's
worth clarifying.

> * 'msi-x-message-control' and 'lnr-control' in the TDISP device interface report (section 3.1.4) both use key '2', is that expected?
>

No, that's a bug.  Nice catch, thanks!

> * The CDDL definition of the eat_nonce claim ( &(eat_nonce: 10) => bytes .size 64 ) clashes with the requirement in 4.4 that "the epoch ID must be encodable as an opaque binary string of between 8 and 64 octets". (Speaking of which, should that be "MUST"?)
>

Nice catch, again :-)

> * Section 3 says that name parts are joined by semicolon, which doesn't seem to be the case in the rest of the doc.
>

Can you find an instance where that is not true?  (If so, that'd be a
bug.)

A quick grep returns:

"spdm:ACME:WIDGET:0123456789" "spdm:C=CA,O=ACME,OU=Widget,CN=0123456789"
"spdm:ACME:WIDGET-A:0123456789"
"spdm:C=CA,O=ACME,OU=Widget-B,CN=9876543210" "legacy-pcie:0000:01:02.0"

which seems to consistently follow the pattern <namespace> ":"
<namespace-specific>.

[IM] Unless I'm missing some context, I believe you're agreeing with me, since semicolon == ';' and colon == ':' . Should've clarified this previously :)

> You also say that "Each individual device claim is the combination of a device name and a standard claims format" - that's confusing, and per CDDL I think you mean "each device name is associated with a set of standard claims ...".
>

Yes, that's what we meant.  A "device claim" is a claim about a device
in the usual key-value form (in RFC9334 §4.2 lingo) where the key is the
device name and the value is the standardised claims-set.  I see how the
misuse of jargon can obscure a simple reality :-) We will fix it.

> * Staying on the topic of names, are there more abstract requirements to encode re. device names? For example, can a single device appear as two submodules (perhaps even of different types)? Can / should Verifiers make trust decisions based on the name?
>

The model currently doens't cater for a device that is counted twice.
Names must be unique otherwise doing aggregation via submods won't work.
Q: Is this a theoretical or a practical concern?

[IM] Mostly a practical concern from a Verifier's perspective, in the sense of "are there any rules that must be checked regarding those names?". Might be worth making it clear either way what the intent is.

> Cheers,
> Ionut

Once again, your contribution is much appreciated.

Mathieu