[Secdispatch] Re: [saag] Re: [Gendispatch] New Int ernet-Draft: High-Assurance Execution Environment (HAE)

Thank you for the feedback. To address the concerns, I want to clarify
both *(1)
what specific work this draft proposes for the IETF*, and *(2) why PRE-RCT
/ HAE is not similar to DKIM*, despite both involving signed structures.
------------------------------
*1. What Work the IETF Is Expected to Do*

The PRE-RCT and HAE documents propose IETF work in *four very specific
areas*, all of which are *outside the scope of DKIM* and current IETF
protocols:
*(A) Define a Standardized Format for Pre-Execution Authorization Receipts*

The IETF work item is to define a structured, canonical, verifiable format
that binds:

   -

   canonical *Action parameters*,
   -

   canonical *Policy state*,
   -

   a *time-bounded authorization decision*,
   -

   *attested execution context*, and
   -

   *presence-bound ephemeral signatures*.

This is the PRE-RCT object—*not a message-signing scheme*, but a *pre-execution
authorization artifact* that downstream systems must validate before
executing a high-risk action.
*(B) Define the High-Assurance Execution (HAE) Token Format*

The IETF is asked to standardize the token produced by a secure approval
environment.
It includes:

   -

   hardware-rooted attestation evidence,
   -

   masking profile (side-channel guarantees),
   -

   enclave identity,
   -

   UI-integrity binding,
   -

   ephemeral signing keys, and
   -

   a canonicalized approval decision.

This is described in the HAE Token Format section.
*(C) Define Canonicalization Rules for Action/Policy Binding*

The work item is not a DKIM-like RFC. It is:

   -

   canonicalization of *action semantics*,
   -

   canonicalization of *policy evaluation state*,
   -

   deterministic reconstruction rules allowing verifiers to recompute
   action_hash and policy_hash *from authoritative system state*.

*(D) Define Verification Procedures*

The IETF work includes defining:

   -

   how a verifier recomputes Action/Policy state,
   -

   how attestation evidence is validated,
   -

   how replay detection is performed,
   -

   how UI-integrity binding is enforced,
   -

   how time-bounded validity windows are checked, and
   -

   how ephemeral presence-bound approvals are consumed.

None of this exists in existing RFCs.
------------------------------
*2. Why This Is Not Similar to DKIM (Technical Clarification)*

Although both DKIM and PRE-RCT involve digital signatures over canonical
data, the *security goals, trust model, and semantics* differ fundamentally.

Below is the rigorous differentiation:
------------------------------
*2.1 DKIM Signs Messages; PRE-RCT / HAE Signs Attested Authorization
Decisions*

DKIM’s purpose:
*Bind a domain name to an email message body + selected headers.*

PRE-RCT’s purpose:
*Bind a human/system authorization decision to:*

   -

   the exact action parameters shown to the approver,
   -

   a hardware-attested secure execution environment,
   -

   a UI-integrity-verified prompt,
   -

   a masking profile describing side-channel posture,
   -

   policy evaluation context,
   -

   a short-lived ephemeral signing key,
   -

   a replay-preventable, time-bounded decision.

The HAE architecture explicitly requires secure rendering, enclave
execution, and attestation evidence.
DKIM does none of these.
------------------------------
*2.2 PRE-RCT Binds UI State, Human Presence, and Attested Context — DKIM
Does Not Have These Concepts*

PRE-RCT requires that the final signed object is produced *only* after:

   -

   the Action is displayed in a trusted UI,
   -

   the UI is verified free of OS manipulation,
   -

   attestation evidence is collected (PCRs, UEID, measurement),
   -

   masking profiles (side-channel mitigations) are active,
   -

   ephemeral enclave keys are generated,
   -

   human/system decision is captured in an isolated environment.

These requirements are normative in the HAE specification:

   -

   Trusted UI requirements.
   -

   Attestation structure and platform integrity requirements.
   -

   Ephemeral execution and teardown.

DKIM has *no UI*, *no user presence*, *no enclave*, *no attestation*, *no
interaction with human intent*, and no notion of *action binding*.
------------------------------
*2.3 PRE-RCT Is Pre-Execution, Not Post-Transmission*

DKIM signs data *after* it is created and before it is transmitted.
Systems verify DKIM signatures *after* receiving the message.

PRE-RCT exists *before execution*, not after.

The PRE-RCT model requires:

   -

   verification before executing a transaction,
   -

   policy enforcement before execution,
   -

   time-bounded approval windows (“execute_not_after”),
   -

   replay exhaustion semantics.

This is defined in PRE-RCT verification semantics, not in DKIM-like systems.

DKIM does not control downstream execution, authorization, or policy
application of actions.
------------------------------
*2.4 PRE-RCT Includes Human-Intent Binding; DKIM Has No Intent Model*

DKIM proves only:

   -

   message integrity
   -

   association with a DNS domain

PRE-RCT proves:

   -

   the responder intended the action
   -

   in that moment
   -

   on that attested device
   -

   with that exact UI state
   -

   under that policy state
   -

   with ephemeral per-session keys
   -

   with cross-checked attestation evidence
   -

   with explicit operator presence inside an HAE

The Action binding requirement is explicit: the HAE MUST bind the displayed
Action to the signed token.

DKIM does not bind *intent*, *UI state*, *execution environment*, *presence*,
*policy evaluation*, or *action semantics*.
------------------------------
*2.5 PRE-RCT Contains Structured Attestation Claims; DKIM Contains None*

HAE Tokens embed detailed attestation evidence including:

   -

   nonce
   -

   UEID
   -

   boot/firmware measurements (TPM PCRs or equivalent)
   -

   enforced security policy ID
   -

   attestation-key signature

All defined explicitly in the “Attestation Evidence Structure.”

DKIM has *no attestation*, *no environment binding*, and *no
execution-integrity guarantees*.
------------------------------
*2.6 PRE-RCT Requires Ephemeral, Session-Scoped Keys; DKIM Uses Long-Lived
Domain Keys*

HAE requires:

   -

   ephemeral signing keys created per invocation,
   -

   keys MUST NOT survive teardown,
   -

   keys MUST be non-exportable,
   -

   no persistent credential material.

DKIM uses:

   -

   static, domain-level keys
   -

   valid for months or years
   -

   shared across all messages
   -

   no hardware binding
   -

   extractable without detection

The cryptographic threat model is not comparable.
------------------------------
*2.7 PRE-RCT Contains Masking Profile & Side-Channel Semantics; DKIM Has No
Computational Integrity Posture*

HAE Tokens include a required field:

   -

   masking_profile (M0–M3)

which indicates:

   -

   CPU jitter level
   -

   memory scrubbing level
   -

   constant-time rendering behaviors
   -

   display normalization
   -

   approved UI masking posture

Defined explicitly in the HAE Masking Profiles section.

DKIM has no computational integrity or side-channel posture requirements.
------------------------------
*3. Summary of Differences*

PRE-RCT and HAE specify:

   -

   *A secure execution environment*
   -

   *Hardware-backed attestation*
   -

   *UI integrity enforcement*
   -

   *Approved-action canonicalization*
   -

   *Ephemeral presence-bound keys*
   -

   *Policy/human/execution binding*
   -

   *Time-window semantics*
   -

   *Replay resistance*
   -

   *Side-channel posture reporting*

All of which are *absent* in DKIM.

The only commonality is that *both use digital signatures*, but the *security
semantics, threat model, and protocol role* are materially different.
------------------------------
*4. Closing: What the Next Version Will Provide*

The next revision of the draft will include:

   -

   A clearer articulation of IETF work items
   -

   A dedicated “Non-Similarity to DKIM and Other Signature Mechanisms”
   section
   -

   More explicit security semantics and threat models
   -

   Detailed examples of Action/Policy binding
   -

   Fully worked-out verifier logic

This will address the feedback and make the scope of the work precise.

On Sun, Dec 7, 2025 at 8:10 PM Murray S. Kucherawy <[email protected]>
wrote:

> On Wed, Dec 3, 2025 at 5:09 PM Eric Rescorla <[email protected]> wrote:
>
>> - Adjusting the Cc line to secdispatch and saag
>>
>> Hi Thomas,
>>
>> This draft doesn't seem to contain any real content, so it's hard to
>> provide much in the way of useful feedback. I think the first thing
>> to do would be to produce a draft that explained more clearly
>> what work you expected the IETF to do.
>>
>
> +1.
>
> It might also be helpful to understand how this is different from DKIM, to
> which it looks very similar.
>
> -MSK
>


-- 
Regards,

Tom Madaras
President / Founder GuardSuite

_______________________________________________
Secdispatch mailing list -- [email protected]
To unsubscribe send an email to [email protected]