Looking forward to meeting everyone in person. I am looking forward to discussing my key concern with this proposal: whether it is really necessary to combine credential issuance with secure channel negotiation. Not to say it’s impossible, of course it is, but is it practical? Specifically, two most common types of workloads today are those that horizontally scale, and serverless ones. In both cases you want to reuse the same credential key and you want to limit the load on the verifier and the credential issuer. The best approach is allay the most architecturally sound one: separate the concerns; procure the credential once and not hit the verifier each time a TLS channel is established.
On Thu, Jul 17, 2025 at 7:35 PM Muhammad Usama Sardar < [email protected]> wrote: > Hello folks, > > The expat BoF proponents have put together a high-level overview of the > design space for attested TLS protocols for confidential computing use case > [1]. To the best of our knowledge and belief, it represents a *fair* > comparison of the alternative approaches. Fair here means that we do not > hide the general limitations of the approach that we are advocating for. > > The rolling BoF charter is here [2], and we are updating it for clarity as > we receive feedback. > > We welcome any feedback/comments/questions on both items. > > Thank you, > > expat BoF proponents > > [1] > https://datatracker.ietf.org/meeting/123/materials/slides-123-expat-design-space-of-attested-tls-00.pdf > > [2] > https://github.com/tls-attestation/exported-attestation/wiki/BoF-Charter > _______________________________________________ > Attested-tls mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
