[Seat] Re: Threat model and properties for attested TLS

[Songbo Bu <[e-mail]>]

Nathanael,

Thank you for the answers. They are very helpful.

I have a few more narrow clarifying questions.

I don't think any confidential computing hardware Root of Trust does
attestation signature. We use Intel TDX. Signature is done by the software
TD QE. Are you aware of any solution that really uses hardware Root of
Trust for signatures? I expect that would kill paralleism, making it
impractical.

Thanks for the narrow correction. Is it to say that attested TLS is only
useful with PKI?

I don't think it's about the complexity earlier or later. The complexity
later is necessary for re-attestation. The *additional* complexity earlier
is questionable. We have already discussed it.

How do you establish trust with "The Verifier"?

By TCB, I meant to ask: is it possible to have WebPKI identity without
trust in CSP?

Can you narrowly clarify why you say "or otherwise". I think both are
required. If it is not in Evidence, how can you check?


Best,
Songbo

Muhammad Usama Sardar <[e-mail]> 于2026年8月13日周四
09:01写道：

> Hi all,
>
> Based on off-list feedback, I realized that my initial email, specifically
> the mentioned papers and discussion points were focused on Confidential
> Computing. I agree non-Confidential Computing is also important and
> feedback on that part is welcome, too. My request of focusing this thread
> was just that we understand what we are talking about and not to mix too
> many topics. This discussion is going good and I am happy with it. We are
> making more constructive progress than I expected. Thanks everyone!
> On 13.08.26 00:53, Sophie Schmieg wrote:
>
> You definitely get very different requirements with just minor subtle
> changes in the threat model in these scenarios, so it is definitely
> important to nail this down and ensure everybody agrees what is talked
> about.
>
> This is very useful guidance and the constructive way forward to avoid
> conflicts and talking past each other. To do this, I plan to write a draft
> on the different threat models I have in mind. As a starting point, we can
> try to make high-level categories, such as:
>
>    1. Confidential Computing threat model
>    2. Non-Confidential Computing threat model
>
> and maybe further subcategories and then slowly put details in, as the
> discussion proceeds. As a starter, WG may also consider some discussion
> points for the threat model:
>
>    1. How do people currently deploy it?
>    2. Where is Attestation Key (AK) stored?
>    3. Where is Long-Term Key (LTK) of the cloud infrastructure provider
>    stored?
>    4. Where are TLS keys stored?
>    5. Which software in the system has access to the keys?
>    6. How is the key provisioned?
>    7. What is the life cycle of the keys?
>    8. What is the policy around the keys?
>    9. What else may go wrong?
>
> Does someone have something to share on these lines?
>
> ===
>
> Hi Nathanael,
>
> Thanks for the correction. I meant secrecy (confidentiality) rather than
> entropy in my last email. Apologies!
>
> I think walking to the physical hardware is practically not feasible in
> many possible use cases that I can think of. But at the same time, if you
> check it remotely, you can have diversion attacks again [0] from the
> security advisory [1]. We are in a very complicated situation. Is someone
> aware of any other workarounds? How are other implementers doing it?
>
> Best,
>
> -Usama
>
> [0]
> https://docs.edgeless.systems/contrast/1.16/architecture/components/manifest#referencevaluestdxallowedpiids
>
> [1]
> https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>