# 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.