[Seat] The (slow?) Passport Model-sized elephant in the room

[Nathanael Ritz <[e-mail]>]

Hi everyone,

Back in July [0], I raised the following concern that affected both
early-attestation-05
and seat-expat-03: neither draft defined a binder mechanism for Attestation
Results [1], [2].

> _The challenge the charter requirement gives us when the TLS client is
the RP and the TLS server is the Attester is that we do not seem to have a
common understanding (let alone a performant approach) for binding a cached
Attestation Result (AR) on a per-connection basis._

I think the problem was very well articulated by Imran Siddique who had
recently resurfaced the problem on GH, noting that when "nothing requires
an Attestation Result to carry either value, and nothing asks the Relying
Party to compare one [...] a Relying Party following the passport text
accepts any Attestation Result the Verifier signed, for any [transport
signing key], on any connection." [4]

To broadcast very good news then, I observe both major solution drafts
(seat-early-09 and seat-expat-05) now explicitly define a binder mechanism
for Attestation Results [5], [6], hooray!

## The (very negative) Performance Impact

However, I strongly believe that the current approach shared by both
seat-early and seat-expat has inadvertently broken a core property promised
by the Passport Model: /caching/. Note that Section 10 of RFC9334 makes the
intent for some flexibility rather overt, (as Markus had previously
highlighted earlier in this same thread [7]):

> "Some flexibility on the freshness requirement is a key component for
**enabling caching and reuse of both Evidence and Attestation Results**,
which is especially valuable in cases where their computation uses a
substantial part of the resource budget (e.g., energy in constrained
devices)." [8]

However, now seat-expat-05 normatively mandates that, "The Relying Party
MUST compute the binding value as described [...] and verify that it
matches the value in the Attestation Result." and seat-early-09 goes even
further, mandating that "A missing binder or a mismatch MUST cause the
attestation to be considered invalid. If any of these checks fails, the
Relying Party MUST abort the connection with a fatal attestation_failed
alert."

This is TERRIBLE for performance. As outlined in our recent publication,
seat-architecture-01, Section 6.3.4, "Operating Challenges Under the
Background-Check Model":

> "In the Background-Check model, the Relying Party must withhold
application data while performing a synchronous appraisal query to an
available Verifier. This verification fan-out latency compounds channel
setup delays, which increases communication timeouts in lossy or
distributed networks. Furthermore, uncompressed platform Evidence may
exceed network Path MTU limits [...]" [9]

While I appreciate that the authors of seat-early-09 are transparent about
the performance impact of their approach, candidatly describing risks
of "Denial
of Service Through Verifier Requests" [10], the very same performance risks
apply to seat-expat-09. This is not a matter of intra- vs. post- but of
Background-Check vs Passport.

## How Did We Get Here?

In effect, both drafts define a binding mechanism under the Passport Model
that requires a Verifier to be online and available for every handshake
ever. I believe this highlights a conceptual gap that we missed for
seat-architecture-01 but hope to better articulate and demonstrate in rev.
02. In the meantime, I would encourage reviewing the example of topology
combinations seen in Fig 7 of RFC9334 [10] and reviewing recent drafts such
as TACRA [11], to explore specific uses cases where such flexibility is
paramount. Mark Novak also shared similar concerns outlining his Fintech use
case [12]

## Proposed Fix - Renable cached AR support under Passport Conveyance

I believe that the solution is straightforward, thankfully. I've published
a strawman proposal for a fix for draft-early and a complete PR for
seat-expat [13] for consideration.

Cheers,
Nathanael


[0] https://mailarchive.ietf.org/arch/msg/seat/Xwf2c1jfUWeGgHjWGFliKqtqANM/

[1]
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-05.html#section-4-5

[2]
https://www.ietf.org/archive/id/draft-fossati-seat-expat-03.html#section-4-4.2.1

[3] https://mailarchive.ietf.org/arch/msg/seat/whMijUHurwGZBMhmV_Eqa1PG7w4/

[4] https://github.com/tls-attestation/exported-attestation/issues/67

[5]
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-09.html#section-5.1.2-5

[6]
https://www.ietf.org/archive/id/draft-fossati-seat-expat-05.html#section-4-4.2.2.1.1

[7] https://mailarchive.ietf.org/arch/msg/seat/XJCkeY1jvf4s4vidLc6e7nU1RLs/

[8] https://www.rfc-editor.org/info/rfc9334/#section-10-3

[9]
https://www.ietf.org/archive/id/draft-many-seat-architecture-01.html#name-handshake-latency-and-netwo

[10]
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-09.html#section-8.1

[11]
https://www.ietf.org/archive/id/draft-novak-rats-tacra-03.html#section-abstract-3

[12] https://mailarchive.ietf.org/arch/msg/seat/B3vuCv9fzcBMVjBE3ZRGOGF_1dU/

[13] https://github.com/tls-attestation/exported-attestation/pull/72


On Fri, 10 Jul 2026 at 10:48, Nathanael Ritz <[e-mail]> wrote:

> Thanks for the feedback Markus. Inline with [NR]:
>
> On Fri, 10 Jul 2026 at 01:26, Markus Rudy <[e-mail]> wrote:
>
>> Hi Nathanael,
>>
>> I believe you are interpreting freshness differently than RFC 9334
>> defines. For attestation results, freshness is described as mostly being
>> time-based [1].
>
>
> [NR] I don't think we disagree! [1] says about the time-based element that
> "this is essential in deciding whether the included Claims can be
> **considered fresh**", emphasis my own. And it goes on to say that the
> consideration regarding freshness of Claims means, "they still reflect the
> latest state of the Attester, and that any Attestation Result was generated
> using the latest Appraisal Policy for Evidence, Endorsements, and Reference
> Values."
>
> [NR] A cached AR has a timestamp and an expiry. If the Verifier's
> signature that produced the AR is trusted and the AR has not expired, the
> Claims inside the AR are also considered fresh. Let me know if that still
> doesn't sound right to you.
>
>
>> Note the following quote from the 3rd paragraph in particular:
>>
>> > Some flexibility on the freshness requirement is a key component for
>> enabling caching and reuse of both Evidence and Attestation Results
>>
>> The charter may be too strict here.
>
>
> [NR] Well, I was talking about binding to fresh Attestation Credentials.
> However, as it turns out, if that AR includes assertions relating to the
> attester's TLS identity key, then signing the CV with that same
> identity key even provides proof of possession. However, there is no
> compound authentication available. If the identity key is compromised,
> that's the show.
>
> [NR] My concern is that such an approach is vulnerable to an oracle
> attack if that identity key is not strictly confidential (i.e., generated
> within the TEE and never leaves it). In the case where you are looking to
> inject a pre-provisioned private identity key with a cert manager to avoid
> the overhead of webPKI provisioning, a typical AR can't provide the
> assurance that either of the two concrete proposals I mentioned aim to
> deliver.
>
> But to remotely attest measured boot or other non-confidential attesting
>> environments, you probably want fresh evidence instead.
>>
>
> [NR] I don't disagree. I'm not looking to replace fresh Evidence entirely.
> I am just looking to make the Passport Model viable for Confidential
> Computing while still providing the additional assurances that the
> Background-Check model already gives us -- but without the massive overhead
> and performance penalty.
>
> [NR] If you could leverage your injected key mechanism with your trusted
> cert manager, while also getting verifiable per-TEE target environment
> assertions that come from a real confidential key, while **also** not
> needing to strictly keep a Verifier co-located with every RP?
>
> [NR] In short, I am seeking to leverage the performance gains the Passport
> conveyance Model can give us, without forcing a trade-off regarding
> resilience to single key compromise. I admit, the ambition has real "have
> your cake and eat it too" energy.
>
> Cheers,
> Nathanael
>
> On Fri, 10 Jul 2026 at 01:26, Markus Rudy <[e-mail]> wrote:
>
>> Hi Nathanael,
>>
>> I believe you are interpreting freshness differently than RFC 9334
>> defines. For attestation results, freshness is described as mostly being
>> time-based [1]. Note the following quote from the 3rd paragraph in
>> particular:
>>
>> > Some flexibility on the freshness requirement is a key component for
>> enabling caching and reuse of both Evidence and Attestation Results
>>
>> The charter may be too strict here. In my understanding, using AR was
>> always a trade-off on freshness, and it depends on the use case whether ARs
>> are appropriate. If neither the attester nor the relying party benefit from
>> leaking the ARs, it's probably fine without per-connection freshness. But
>> to remotely attest measured boot or other non-confidential attesting
>> environments, you probably want fresh evidence instead.
>>
>> Cheers, Markus
>>
>>