[Rats] Re: Review of draft-ietf-rats-multi-verifier

[Serhii Nikolaichuk <[e-mail]>]

Hi Paul, authors,

Not an author here, and I won't duplicate the review. But your Section 2
point is one I have measurements for, and I think it lands slightly
differently than either "format" or "content".

You wrote that all components might emit evidence in a common format
such as EAT and the problem would not go away, so the issue is really
content. I agree the format is not the problem. In my data the failure
did not happen at the content layer either. It happened before both: the
receiving party could not establish what kind of object it was holding.

I collected 26 hardware-signed attestation artifacts across three TEE
families and looked at what the leading bytes actually tell a reader.
AWS Nitro documents begin 84 44 a1 01 38 22 a0 59 11 40 - the first byte
is a CBOR array header, and the payload length is declared inline. Azure
SGX artifacts are JSON text and self-delimiting. Both vary in size with
content: 4523-4528 and 4432-4451 bytes respectively. AMD SEV-SNP reports
declare neither a type nor a length, and all ten of mine are exactly
1184 bytes, because 1184 is a constant of the specification rather than
a property of the instance.

Where an artifact's length is a constant of its format, length carries
no information about the artifact. That reads as abstract until it
bites. Two on-disk encodings of an SEV-SNP report - the bare report, and
the report as returned by the Linux guest ioctl, which prefixes a
32-byte response header - both occupy exactly 1184 bytes and share no
distinguishing field. My own parser selected offsets by length and read
one as the other. The CHIP_ID window landed 32 bytes early, on
reported_tcb, then 24 further bytes, then the first 32 bytes of the real
chip identifier. So the values differed between machines, were stable on
a machine, and looked entirely plausible. Four physical parts were
published as seven. I corrected that publicly.

The part that seems relevant to this document is what the ecosystem does
with those same ten files. go-sev-guest v0.15.0 accepts 4 of 10 and
reports 4 distinct chip identifiers. The sev crate accepts 4 and reports
4, both at 6.3.1 and at 8.0.0 after its parser rewrite. Both reach the
right answer, and neither reaches it by identifying the container: one
fails on guest policy reserved bit 17, the other on the report version
word, and in the wrapped layout both of those fields sit inside the
foreign header, where they read as zero because the ioctl succeeded. An
envelope with nonzero leading words would satisfy both checks. Neither
diagnostic names the real fault - "malformed guest policy: policy[17] is
reserved, must be 1, got 0" and "unsupported" - so both send an engineer
to look at their guest configuration rather than at their parsing
offset.

I raise it in this thread rather than elsewhere because it seems sharper
for multi-verifier than for the single-verifier case. In the topologies
in Section 5, evidence is serialised, handed on, and appraised by a
party that did not produce it and was not present when it was captured.
That is exactly the condition under which a reader has bytes and no
container. A verifier that requests and appraises in one step largely
avoids the question.

Two smaller consequences, offered rather than argued.

In 5.1.1 you ask whether "may wrap such evidence in a signed CMW" ought
to be a MUST. From this angle it should be. Unsigned Partial Evidence
propagating between verifiers with nothing declaring what it is is
precisely the case where the receiver cannot tell.

For Section 8, on minimisation: the attester interfaces I used across
the three families accept caller-supplied data - a nonce, or user data,
or a public key - but I found no mechanism for requesting a subset of
the claims that come back. That matches what you said, and I can say it
from the interfaces rather than from expectation.

One distinction I should draw myself before someone draws it for me.
There is a known and documented 32-byte offset in front of a SEV-SNP
report on Azure, where the report sits at offset 32 inside a larger vTPM
NVRAM blob and is extracted with dd skip=32 bs=1 count=1184; that recipe
has been in the snpguest issue tracker since May 2023. That case is
distinguishable by total length, because the containing blob is larger
than the offset plus the report. Mine is not: the file is exactly 1184
bytes, the same length as a bare report.

Yogesh - I see you have opened issue #60 to track Paul's review. If it is
easier for the authors, say the word and I will open a separate issue
against the repo for the Section 2 point rather than leave it on the list.

If the artifacts would be useful to the working group I am glad to share
them - signed attestation documents from real hardware across AWS Nitro
Enclaves, AMD SEV-SNP and Intel SGX, with the offline verifiability of
each one recorded. They check with a stock Python interpreter and no
third-party packages. Ask on the list and I will post a link, or I can
send it off-list.

Thanks for the review. Section 2 is what made me write.

Serhii Nikolaichuk
Austin, Texas

On Thu, Aug 27, 2026 11:14 AM, Yogesh Deshpande <[e-mail]>
wrote:

> Hello Paul,
>
>
>
> Thank you so much for your deep review and appreciate all the comments.
>
>
>
> I have created a top-level issue: https://github.com/ietf-rats-
> wg/draft-ietf-rats-multi-verifier/issues/60
>
>
>
> to track all comments. Going forward, we may create more issues, (if
> needed) from this master issue and shall incorporate all the comments.
>
>
>
> Thanks again.
>
>
>
> Regards,
>
> Multi Verifier Team
>
>
>
> *From:* Paul Howard <[e-mail]>
> *Sent:* Thursday, August 27, 2026 5:01 PM
> *To:* [e-mail]
> *Cc:* RATS <[e-mail]>; nd <[e-mail]>
> *Subject:* Review of draft-ietf-rats-multi-verifier
>
>
>
> Dear Multi-Verifier authors,
>
>
>
> I took an action from IETF-126 to review the multi-verifier draft.
>
>
>
> I have reviewed version 00 of the adopted draft [0], and I have the
> observations below. I hope they are useful. I didn’t use an LLM for this
> review. All is based on having studied the text with my meagre organic
> brain, so take it for what it’s worth!
>
>
>
> ### Overall
>
> I found the draft to be well-written and well-motivated. It provides good
> informational guidance on use cases and deployment patterns, while
> remaining agnostic on specific data formats and protocols. I think it’s a
> useful informational draft, and a helpful addition to the RATS ecosystem.
>
>
>
> I’ve grouped my observations by sections of the document (as per their
> numbering at version 00 of the draft).
>
>
>
> ### Section 1
>
> I think this section would benefit from a simple diagram of a Composite
> Attester, just to help with orientation and mapping to the terminology (see
> below).
>
>
>
> Terminology could use some tightening up. The terms Composite Attester and
> Component Attester are clearly introduced (and in the glossary), but then
> we have terms like “subsection”, “sub-entity” and “individual layer” being
> sprinkled in. We also have “attesting environment” being casually
> introduced (uncapitalised) without a reference to RFC9334. I think this is
> all too bewildering for the intro section. For instance, is a CPU a
> section, an entity, a layer, an environment, a component, or what? Along
> with a diagram, more careful and intentional use of terms would benefit the
> intro a lot. The intro is critical for reader orientation.
>
>
>
> ### Section 2
>
> “The verifier inputs listed above are linked to the shape of the
> Attesters” - the phrase “linked to the shape” could use some spelling out.
> It isn’t clear whether “shape” is intended to be a formal term in this
> document. And “linked” is slightly vague. I think what we want to convey
> here is that the number and diversity of supply chain sources (providing
> the Verifier inputs) will vary in parallel with the complexity of the
> Attester. Could use a few more words to make this clearer.
>
>
>
> We use the term “Evidence formats” as the complexity multiplier, but I’m
> not sure that “format” is really the issue, is it? I mean, in a composite
> system, all the components might produce evidence in the same common format
> (such as EAT, for instance). But this would not make the problem go away.
> So I don’t think it’s so much the format as it is the content, and which
> parts of the supply chain would know how to appraise that content.
>
>
>
> In the list of challenges at the end of this section, bullet 4 doesn’t
> feel like a challenge in its own right, but rather a redundant re-statement
> of mixtures of the other challenges.
>
>
>
> Similarly, bullet 5 feels out of place, because it’s simply a statement of
> the status quo. I’d consider detaching this from the numbered list and
> using it as a closing paragraph for Section 2 instead, perhaps motivated by
> something like “the significance of these challenges is evidenced by the
> situation that exists today”.
>
>
>
> ### Section 3
>
> “There are many other use cases” feels like a bit of a cop-out. Maybe just
> say that the reference use cases are not intended to be exhaustive, only
> representative. Are there really “many” others? The problem statement from
> Section 2 indicates that heterogeneity and layering are the key motivators
> for multi-verifier, so it feels like the reference use cases provide fairly
> complete coverage, actually.
>
>
>
> On a related note, the two use cases given are not mutually exclusive.
> Quite the opposite, in fact. The one in 3.2 would very likely be combined
> with 3.1. Worth calling this out in the text, I think.
>
>
>
> “Confidential Computing” and “TEE” terms are introduced without much
> fanfare. A sentence or two extra to give some basic definitions would help
> here, especially since those definitions can highlight the existential
> importance of attestation for this use case.
>
>
>
> IMO, the context-specific definitions of “Attester” and “Relying Party” at
> the bottoms of these paragraphs aren’t effective. These terms are defined
> by RFC9334. I get what we’re trying to do, but it would be better to flesh
> it out into proper prose or just lose it altogether. As currently written,
> they read as dangling afterthoughts, or as new glossary entries.
>
>
>
> ### Section 4
>
> The definition of “Composite Attester” refers to both “Composite Device”
> and “Layered Attester”, but neither of those is in the glossary. They
> should either be defined, or there should be a reference elsewhere (e.g.
> RFC9334).
>
>
>
> A few of the glossary definitions have the phrase “Also referred to as
> (ABBREVIATION) in the document”, which is a sentence fragment, and a bit
> cumbersome. Why not just add the abbreviations to the definitions
> themselves, e.g. “Composite Evidence (CE): Evidence produced by a Composite
> Attester”?
>
>
>
> ### Section 5
>
> In 5.1, the Component Verifiers in the figure as labelled as “Verifier 1”
> etc. But we’ve carefully introduced and defined the term Component Verifier
> (CV), so why not label the boxes with the same term?
>
>
>
> In 5.1.1, the last paragraph indicates that some PE’s might not be
> individually signed, and says that the Lead Verifier “may” (lower-case)
> wrap such evidence in a signed CMW. Is this guidance strong enough? Don’t
> we want a MUST there? Given the trust relationships described, there
> doesn’t seem to be any basis on which a CV could accept any PE that is
> *not* signed by the Lead Verifier. (Later I find this is indeed set as a
> MUST in the sec-cons, but it feels weird to not address it here).
>
>
>
> Section 5.1 has no mention of signing of PARs or AARs. Should the PARs be
> signed by CVs? Will the Lead Verifier check those signatures? Does the Lead
> Verifier sign the final AAR (seems to me that it must do).
>
>
>
> In 5.1.3, should we have an opening sentence to say that all of the trust
> relationships of RFC9334 automatically apply, in addition to the specific
> ones described here?
>
>
>
> In 5.1.3, does every CV *always*​ have to trust the Lead Verifier? In the
> hierarchical model, I’d expect it to be very common for CVs to have no
> knowledge of the Lead Verifier, and might get used by all sorts of
> different Lead Verifiers. Take a GPU vendor for example. I would expect a
> GPU verifier to be able to appraise GPU evidence regardless of where it
> came from, without even knowing whether it is taking part in a hierarchical
> topology or not. I think that the CVs only need to trust the LV in cases
> where the PE is unsigned and the CMW wrapper is applied.
>
>
>
> In 5.2, the diagram again uses the term “Verifier” and not “Component
> Verifier” or “CV”.
>
>
>
> I found the figure in 5.2 to be harder to comprehend than the one in 5.1,
> but I got it after reading the text.
>
>
>
> In the cascade pattern, it seems that verifiers must somehow “know” their
> position in the cascade. I say this because Verifier N (end of chain) is
> tasked with forming the complete AAR, but Verifier 1 (start of chain) is
> tasked with signing it. How does Verifier 1 know that it is Verifier 1 and
> not Verifier 2, for instance?
>
>
>
> In the cascade pattern, there’s no mention of whether the intermediate
> PARs need to be signed and/or integrity checked as they propagate around.
> (Again, the sec-cons has stronger statements on this, but it’s a jarring
> omission at the point of describing the topology).
>
>
>
> Last paragraph of 5.2 has “There are many protocols”. Are there? Can we
> provide maybe a single example, while remaining agnostic? It would help the
> reader understand the landscape of possibilities.
>
>
>
> Section 5.2.1 has a nesting problem: 5.2.2 and 5.2.3 need to be
> subheadings, not siblings.
>
>
>
> ### Section 7
>
> I probably should have read this section before section 5. 😊
>
>
>
> Threats and mitigations all look reasonable/sensible to me. I’ll leave
> this section to more expert reviewers.
>
>
>
> ### Section 8
>
> I don’t understand the “Minimisation” advice. It says that Attesters
> should limit the evidence they produce. But on what criteria can they do
> that? They don’t typically know what the appraisal policies are, do they?
> And how does a verifier “only request necessary claims”? Most Attester
> interfaces that I’ve seen only provide a challenge/nonce as the input. I’ve
> not seen mechanisms for requesting subsets of evidence/claims.
>
>
>
> Likewise, on the “Confidentiality” advice - there’s no advice on how to
> manage keys for encrypted evidence. This feels like it could be a
> challenge. I get that this draft probably doesn’t want to prescribe every
> cryptographic detail, but it feels weird to describe the multi-verifier
> topologies but then be silent on how key management might work among those
> same topologies to preserve the privacy of one or more PE packets. If I had
> to implement all of this, I’d appreciate some guidance for sure.
>
>
>
> ### Nits
>
> Proof-reading bits and pieces...
>
>
>
>    - Section 1: the references to Section 4.1 should be in parentheses so
>    as not to interrupt the text flow.
>
>
>    - Section 1: “The results are consumed by the Relying Party to
>    conclude the trustworthiness of the Attester” - the verb “conclude” doesn’t
>    sit right here. Feels like it should be “reach a conclusion about” or
>    “conclude on” or “evaluate”. Current reading is slightly enigmatic, almost
>    like we’re ending the trustworthiness!
>
>
>    - Section 1: “Composite Attester [..], generate evidence” - noun/verb
>    disagree in number, and the comma shouldn’t be there.
>
>
>    - Section 1: “For example Attesters can be endpoints” - needs a comma
>    after “For example"
>
>
>    - Section 1: “attesting environments” (AE) - should we be capitalising
>    “Attesting Environments” here, to better justify the abbreviation? Also, is
>    that a term from RFC9334 that we should be referencing? It feels like the
>    term is introduced a little too casually, and it’s not in the glossary.
>
>
>    - Section 1: “what was booted machine’s GPU” -> “what was booted ON
>    THE machine’s GPU”.
>
>
>    - Section 1: “wide varieties of shape and form” -> “a wide variety of
>    shapes and forms"
>
>
>    - Section 1: “Please refer to Section 2 for motivation of this
>    document” - feels redundant, especially since it’s the very next section,
>    and it’s not grammatical as written.
>
>
>    - Section 1: “various topological patterns” - the document
>    specifically describes TWO patterns. I get that this might change in the
>    future, but I think it’s better to anchor the reader’s expectations
>
>
>    - Section 2: “Reference Values from trusted supply chain actors
>    producing, aggregating, or administering Attesters (Reference Value
>    Providers)” - this needs reorganising, because this almost reads like
>    “Reference Value Providers” is a synonym for “Attesters”.  Suggest
>    something like “Reference Values from trusted supply chain actors known as
>    Reference Value Providers (RFC9334) …"
>
>
>    - Section 2: as above for bullet 2
>
>
>    - Section 2: “…that a complex and changing Composite Attesters
>    imposes” - disagreement in number, should be singular “Composite Attester"
>
>
>    - Section 2: “Reference Values Provider” -> “Reference Value Provider”
>    (bullet 3 of the challenges list)
>
>
>    - Section 3: “central processing unit (CPU)” - should be capitalised,
>    but why not just use CPU as well-known term for this readership, especially
>    since the same sentence has GPU, NPU and TPU without their expansions.
>
>
>    - Section 3.1 para 3: “partial Evidence” -> “Partial Evidence”.
>
>
>    - Section 3.2: “virtual machine (VM)” - should be capitalised, but do
>    we even need to expand it? After all, we also have TEE in this section
>    without expanding or defining it.
>
>
>    - Section 4: “...or any composition involving a combination of one or
>    more Composite Devices or Layered Attesters” - cumbersome wording, I think
>    it would be okay to just say “or any combination of these” (in the glossary
>    def for Composite Attester)
>
>
>    - Section 4 the reference to section 5.1 should be in parentheses so
>    as not to interrupt the text flow
>
>
>    - Section 4: the definition for Partial Evidence has redundant words
>    “It is an” at the start
>
>
>    - Section 5.1: “Figure below shows” -> “The figure below shows"
>
>
>    - Section 5.1.1 the mentions of passport and background check are
>    probably worth a courtesy ref to RFC9334.
>
>
>    - Section 5.1.1: “…to extract the Component Attesters Evidence” -
>    missing apostrophe - “Attester’s"
>
>
>    - Section 5.2 “..a chain of Verifier” -> “..a chain of Verifiers"
>
>
>    - Section 5.2 “The process is repeated, until the entire…” comma not
>    needed here
>
>
>    - Section 5.2 “…combines the results from it own…” -> “combines the
>    results from ITS own"
>
>
>    - Section 7.3.1.1.1 “Component Verifiers should be made available
>    suitable trust anchors…” - this doesn’t read well - do we mean “should be
>    provisioned with suitable trust anchors”?
>
>
>    - Section 8: “attestation related messages” -> “attestation-related
>    messages"
>
>
>
> [0] - https://www.ietf.org/archive/id/draft-ietf-rats-multi-
> verifier-00.html
>
>
>
> *Paul Howard*
>
> Senior Principal Software Architect | *Arm*
>
> ………………………………………………………………..
>
> m. [phone] <[phone]>
>
> arm.com
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>