<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc
  ipr="trust200902"
  category="exp"
  submissionType="IETF"
  docName="draft-madaras-high-assurance-exec-00"
  version="3">

  <front>
    <title abbrev="HAE">
      High-Assurance Execution Environment (HAE) for Secure Approval
    </title>

    <author fullname="Tom Madaras" initials="T." surname="Madaras">
      <organization>GuardSuite, VXMSecure</organization>
      <address>
        <postal>
          <city>Hollywood</city>
          <region>FL</region>
          <country>USA</country>
        </postal>
        <email>tom@vxmsecure.com</email>
      </address>
    </author>

    <author fullname="Pat Estis" initials="P." surname="Estis">
      <organization>GuardSuite, VXMSecure</organization>
      <address>
        <postal>
          <city>Houston</city>
          <region>TX</region>
          <country>USA</country>
        </postal>
        <email>pat.estis@gmail.com</email>
      </address>
    </author>

    <date year="2025" month="December" day="3"/>

    <abstract>
      <t>
        This document specifies the High-Assurance Execution Environment
        (HAE), a trusted, ephemeral approval environment designed to
        protect the authorization of high-risk digital and physical
        actions.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro">
      <name>Introduction</name>
      <t>
        The High-Assurance Execution Environment (HAE) provides an
        isolated, attestation-backed approval environment for high-risk
        actions such as financial transfers, cloud administrative
        operations, industrial control system commands, and AI-initiated
        operations.
      </t>
    </section>

    <section anchor="reqs">
      <name>Requirements Language</name>
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
        "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
        are to be interpreted as described in BCP 14
        (<xref target="RFC2119"/>, <xref target="RFC8174"/>)
        when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>
        This document introduces no security considerations beyond those
        inherent in isolated execution and attestation systems.
      </t>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>
        This document has no IANA actions.
      </t>
    </section>

  </middle>

  <back>
    <references>
      <name>Normative References</name>

      <reference anchor="RFC2119" target="https://www.rfc-editor.org/rfc/rfc2119">
        <front>
          <title>
            Key words for use in RFCs to Indicate Requirement Levels
          </title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
      </reference>

      <reference anchor="RFC8174" target="https://www.rfc-editor.org/rfc/rfc8174">
        <front>
          <title>
            Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
          </title>
          <author initials="B." surname="Leiba" fullname="Barry Leiba"/>
          <date year="2017" month="May"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
      </reference>

    </references>
  </back>

</rfc>
