[Seat] Re: Fwd: New Version Notification for draft-many-seat-architecture-00.txt

[Nathanael Ritz <[e-mail]>]

On Mon, 6 Jul 2026 at 13:23, Markus Rudy <[e-mail]> wrote:

> Hi Nathanael,
>
> funny, I could have sworn that there was already a use case for this in
> the "official" collection, but I might have been confusing this with the
> "split deployment" use case.
>
> The use case is pretty simple: I'm running containers in TEEs and I'd like
> them to authenticate with a certificate that chains to the web PKI. Getting
> a certificate just in time is not feasible for short-lived containers, and
> getting a CA cert is not possible for everyone. Therefore, I'd like to just
> use a certificate obtained by cert manager (for example) and load the key
> into my VMs.
>
> Now, the private key will not be confidential in this case, but I believe
> this not to be an issue per se - if perfect forward secrecy works, we
> should also be able to utilize DHE for this, if we bind to the session
> instead of the key.
>
> Cheers, Markus
>

Thanks for the extra detail. Based on my review of
https://datatracker.ietf.org/doc/draft-mihalcea-seat-use-cases/03/, this
specific use case, using remote attestation to augment assurance on a
non-confidential private key, does not appear to be explicitly described
yet. One reason may be that the use case appears, at a glance, to brush up
against section 3.2, regarding Compound Authentication [2] that suggests
"RA should complement endpoint authentication rather than replace it." The
principle behind that advice is to avoid documented exploits such as
diversion attacks.

I appreciate that your use-case is *not* replacing endpoint authentication,
as you clearly point out that are still leveraging web PKI. Instead, it
appears your accepted risk and threat model explicitly allows the private
key to be non-confidential, while relying on specific hardware assumptions
associated with remote attestation to augment assurance in the use of those
non-confidential private keys. That, plus the typical security assumptions
that compliant TLS 1.3 implementations already have.  Let me know if I
understand your position correctly.

As I see it, this appears to be a completely valid use case for composing a
secure channel protocol like TLS with Remote Attestation. We are reviewing
ways to increase flexibility to avoid needing to specify the strict
requirement of a Target Environment-native TEE-bound identity key (`tbK`)
in every situation. Furthermore, we are looking at expanding the defintion
of the so-called `hbK` (hardware-bound key) to allow implementors the
needed flexibility to simply accept the security assumptions from their
existing resources, including the use of hardned KSMs or certificate
managers, to avoid a strict depedency on the 'tbK' at all times.

However, risks associated with diversion attacks remain, which the authors
would very much like to avoid architecturally as much as it is possible. We
are exploring solutions and hope to share a more detailed post on a new
approach in a dedicated thread on the mailing list in the coming days. In
the meantime, I do believe that simply having implementors accept their own
acceptable risk policies and acceptance of those *informed* assumptions is
reasonable enough to relax the strict "`tbK` always" mandate.

I have additional comments to share  from your previous email inline with
[NR]:



> ________________________________________
> From: Nathanael Ritz <[e-mail]>
> Sent: Monday, July 6, 2026 6:45 PM
> To: Markus Rudy <[e-mail]>
> Cc: [e-mail] <[e-mail]>; tirumal reddy <[e-mail]>;
> [e-mail] <[e-mail]>
> Subject: Re: [Seat] Fwd: New Version Notification for
> draft-many-seat-architecture-00.txt
>
> Hi Markus,
>
> Thanks very much for taking the time to review the draft.
>
> Directly on list, I would like to probe you for additional information
> immediately regarding feedback on Sec 2, as I have seen you bring up the
> issue before, I think! [0]
>
> See inline with [NR]:
>
> On Mon, 6 Jul 2026 at 01:56, Markus Rudy <[e-mail]> wrote:
> <snip>

> Sec 6.1
> > [RFC9334] expects a failed Attester appraisal to result in reduced
> access or privileges rather than outright rejection.
> > In the event of failures occurring within the Post-Handshake Window,
> this behaviour is to be handled at the transport layer.
>
> This seems to be at odds with the definition of the post-handshake window
> in sec. 2, which explicitly allows the application layer to handle
> attestation, and with the guidance in the following paragraph. Is this a
> load-bearing requirement, or can it just be relaxed?
>

[NR] Yes, I believe this can be relaxed. Depending on the approach taken
for Post-Handshake (either as a shim, or applied per-protocol as a profile
of RFC9261) the text should change to "MAY".


>
> > 9.3.  Attestation Key Correlation
>
> This seems to be a general consideration for RATS, if there is no
> conclusion for attested TLS I'd just remove it.
>

[NR] You caught a placeholder where we plan to expand this explictly for
attested TLS. Thank you for highlighting it for us!


>
> > Sec 10
> > When a transport session is resumed, previously obtained Attestation
> Credential may no longer reflect the Attester's current state.  Attestation
> from a prior session does not carry over to a resumed session.
>
> This seems to be overly restrictive: even if I accept the need for
> periodic re-attestation (which I don't), I don't see why resumption needs
> to be outright forbidden. Either describe a concern which applies
> universally, or relax the requirement?
>

[NR] Agreed. We've dropped the final sentence so it concludes with "When a
transport session is resumed, previously obtained Attestation Credential
may no longer reflect the Attester's current state", and leave it to the
concrete protocols and implementations to appropriately handle the
situation where state drift may occur. This is useful especially if the
Attestation Credential is in the form of a cached AR.

[NR] These changes are expected to make it into the eventual -01 release,
pending additional feedback. Please let me know if this aligns with what
you were looking for, or if you have any corrections or push back on
anything I've suggested here. Thanks again for the review!

Cheers,
Nathanael