From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: seal@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Secure Evidence and Attestation Layer (seal)
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 (iesg@ietf.org) by 2025-09-27.
Secure Evidence and Attestation Layer (seal)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Yaroslav Rosomakho <yaroslavros@gmail.com>
Nancy Cam-Winget <ncamwing@cisco.com>
Assigned Area Director:
Paul Wouters <paul.wouters@aiven.io>
Security Area Directors:
Paul Wouters <paul.wouters@aiven.io>
Deb Cooley <debcooley1@gmail.com>
Mailing list:
Address: seal@ietf.org
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:
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
seal-chairs@ietf.org,
seal@ietf.org
Subject: WG Action: Formed Secure Evidence and Attestation Layer (seal)
A new IETF WG has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.
Secure Evidence and Attestation Layer (seal)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Yaroslav Rosomakho <yaroslavros@gmail.com>
Nancy Cam-Winget <ncamwing@cisco.com>
Assigned Area Director:
Paul Wouters <paul.wouters@aiven.io>
Security Area Directors:
Paul Wouters <paul.wouters@aiven.io>
Deb Cooley <debcooley1@gmail.com>
Mailing list:
Address: seal@ietf.org
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 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
traditional 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 TLS should be able to support.
It will initially deliver a Standards Track solution that meets these
use cases and enables peer or mutual attestation for 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 protocol will focus on attestation and authenticated
attestation, but will not create new authentication mechanisms.
- The solution will not modify the TLS protocol outside of adding
TLS extensions to support its goals that does not modify
the core TLS specification.
- The protocol 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 the UFM research group regarding
formal analysis of the WG's resulting work.
- The working group will work closely with WIMSE to ensure its deliverables
are usable for common WIMSE deployments.
# 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 document defining a TLS extension supporting remote peer
and mutual attestation bound to the TLS session.
# Future work
After the initial Milestones are complete, the WG may recharter to work
on other protocols, such as IKEv2 or SSH, is there is sufficient interest.
Milestones: