A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([email protected]) by 2025-09-27.
Secure Evidence and Attestation Layer (seal) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yaroslav Rosomakho <[email protected]> Nancy Cam-Winget <[email protected]> Assigned Area Director: Paul Wouters <[email protected]> Security Area Directors: Paul Wouters <[email protected]> Deb Cooley <[email protected]> Mailing list: Address: [email protected] To subscribe: https://mailman3.ietf.org/mailman3/lists/seal.ietf.org/ Archive: https://mailarchive.ietf.org/arch/browse/seal/ Group page: https://datatracker.ietf.org/group/seal/ Charter: https://datatracker.ietf.org/doc/charter-ietf-seal/ # Background and motivation In many scenarios, particularly with the rise of Trusted Execution Environments (TEEs) and the increasing security demands for IoT devices and confidential workloads, there is a requirement for some use cases that utilize protocols such as (D)TLS to also ensure that the peer's state is validated in addition to conventional authentication (verification of identity). Remote attestation (RFC9334) addresses this by allowing an entity to produce verifiable Evidence about its current state. For example, to prove that its software and firmware haven't been tampered with. Or that a secure boot method is enabled. Or that cryptographic keys are securely stored within a hardware-protected environment. This provides an additional assurance of trustworthiness, helping to prevent the continued use of a compromised system even if its conventional credentials remain valid, and enables authorization policies based on richer security guarantees. # Scope The Secure Evidence and Attestation Layer (SEAL) WG will document a set of use cases that protocols such as (D)TLS should be able to support. It will initially deliver a Standards Track protocol that meets these use cases and enables peer or mutual attestation for (D)TLS using the extension and/or exporter features of D(TLS). Such a mechanism would allow an entity to produce Evidence or an Attestation Result about itself for another party to evaluate. Specific scoping: - This effort will be restricted to leveraging the (D)TLS 1.3 protocol and a potential attestation binding to a (D)TLS 1.3 session. - It will leverage the existing RATS WG documents to ensure interoperability with existing and future attestation technologies. - The (D)TLS protocol solution will focus on attestation and authenticated attestation, but will not create new authentication mechanisms. - The (D)TLS protocol solution will not modify the (D)TLS protocol outside of adding (D)TLS extensions to support its goals that do not modify the core (D)TLS specification. - The (D)TLS protocol solution will allow per-connection [freshness](https://www.ietf.org/rfc/rfc9334.html#section-10). - The effort will not create solutions that decrease privacy or security properties of generic TLS sessions. The working group will engage with the research community on the evaluation and formal analysis of the protocol artifacts in parallel with the specification work. # Dependencies and Liaisons - The working group will work closely with the TLS working group, the RATS working group, and the Confidential Computing Consortium's (CCC's) Attestation Special Interest Group (SIG). - The working group will engage with research groups regarding formal analysis of the working groups's resulting work. - The working group will work closely with the WIMSE working group to ensure its deliverables are usable for common WIMSE deployments and have taken into account any Operational Considerations that apply. # (Proposed) Milestones - A use cases document describing the scenarios that this working group will be targeting in its specification document. This document need not be published as an RFC. - A Standards Track document defining a (D)TLS protocol solution supporting remote peer and mutual attestation bound to the (D)TLS session. # Future work After the initial Milestones are complete, the WG may recharter to work on adding attestation to protocols other than D(TLS), such as IKEv2 or SSH, provided there is sufficient interest. Milestones: _______________________________________________ IETF-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]
