Network Working Group J-I. Kadjo Internet-Draft Zenith Intelligence Technologies Inc. Intended status: Informational 8 May 2026 Expires: 8 November 2026 ZI2 Certified Email Server Attestation Protocol draft-kadjo-zi2cert-01 Abstract This document specifies the ZI2 Certified Email Server Attestation Protocol, a mechanism for cryptographic attestation of email origin at the mail server level. Unlike existing email authentication protocols (SPF, DKIM, DMARC), which operate at the domain level, ZI2 Certified operates at the server-instance level, enabling definitive identification of the specific server that dispatched a given email message. The protocol introduces two custom mail headers, a DNS TXT record publication format, a graduated trust model with four levels, and an integration interface for AI-based email classification systems. The protocol operates complementarily to existing email authentication infrastructure and introduces an ARC-Delegated Trust mechanism to preserve origin attestation across legitimate transit modifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Kadjo Expires 8 November 2026 [Page 1] Internet-Draft ZI2 Certified May 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Relationship to Existing Protocols . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 3.1. Cryptographic Primitives & Canonicalization . . . . . . . 4 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . 4 3.3. Outbound Certification . . . . . . . . . . . . . . . . . 4 3.4. Inbound Verification . . . . . . . . . . . . . . . . . . 5 3.5. ARC-Delegated Trust Verification . . . . . . . . . . . . 6 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 6 5. DNS Publication . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Key Rollover and Rotation . . . . . . . . . . . . . . . . 7 6. Trust Levels . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. AI Systems Integration Interface . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. Email Authentication Methods Registry . . . . . . . . . . 10 8.2. Email Authentication Result Names Registry . . . . . . . 10 8.3. Message Header Field Registry . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1. Problem Statement The current email authentication ecosystem relies on three principal protocols: SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489]. Each of these protocols operates at the domain level, answering questions about whether a domain authorized the sending of a message. None of these protocols, individually or in combination, answer a more fundamental question: "Did this specific server actually send this email?" This distinction is critical in multi-tenant mail server environments, where a single server hosts multiple domains under a Kadjo Expires 8 November 2026 [Page 2] Internet-Draft ZI2 Certified May 2026 shared IP address and MTA process. In such environments, domain- level authentication cannot distinguish between legitimate email from one co-hosted domain and spoofed email purporting to originate from another co-hosted domain. An attacker who compromises one domain's DNS records or DKIM keys can forge emails that pass SPF, DKIM, and DMARC validation for any domain on the shared server. 1.2. Scope This document specifies a server-level cryptographic attestation protocol that: 1. Generates a unique Ed25519 [RFC8032] key pair per server instance. 2. Signs outbound email with a server-specific attestation header. 3. Publishes the server's public key via DNS TXT records. 4. Verifies inbound email bearing the attestation header against the published public key. 5. Assigns graduated trust levels reflecting the strength of the verification method. 6. Integrates with ARC to preserve trust across forwarding gateways. 1.3. Relationship to Existing Protocols ZI2 Certified does not modify, replace, or interfere with SPF, DKIM, DMARC, ARC [RFC8617], BIMI, MTA-STS, or DANE [RFC7671]. It operates as a complementary attestation layer that addresses the server-level authentication gap left by existing domain-level protocols. Specifically, ZI2 Certified addresses the structural limitation of cryptographic body hashes breaking during transit modifications (such as mailing list subject tagging or gateway footer injections). By natively integrating with the Authenticated Received Chain (ARC) [RFC8617], ZI2 Certified acts as the mathematically certain origin anchor for ARC. A trusted intermediary verifies the ZI2 signature before modifying the message and seals the result within the ARC chain, allowing final recipients to authenticate the origin despite transit alterations. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174]. Certification: The process by which a sending mail server generates a cryptographic attestation of email origin and injects the attestation into the email as a structured header. Kadjo Expires 8 November 2026 [Page 3] Internet-Draft ZI2 Certified May 2026 Verification: The process by which a receiving mail server validates a certification header by retrieving the sender server's public key and verifying the cryptographic signature. Certifying Server: A mail server that generates and injects ZI2 Certified headers on outbound email originating from its hosted domains. Trust Level: A graduated integer value (0 through 3) representing the confidence in the verification result based on the method of public key retrieval. Server Identifier (sid): The fully-qualified domain name (FQDN) of the certifying server. 3. Protocol Specification 3.1. Cryptographic Primitives & Canonicalization The protocol uses Ed25519 [RFC8032] for signing, providing approximately 128 bits of security, deterministic signatures, 32-byte public keys, and 64-byte signatures. SHA-256 [RFC6234] is used for message body hash computation, and Base64 [RFC4648] is used for encoding. MIME Decoding and Canonicalization: To ensure the SHA-256 hash survives routine MTA transfer-encoding conversions (e.g., 8BITMIME downgrades to 7-bit quoted-printable), implementations MUST decode any Content-Transfer-Encoding prior to hashing. Furthermore, implementations MUST apply RFC 6376 (DKIM) Relaxed Body Canonicalization to the decoded body content before computing the hash. 3.2. Key Generation To provide true server-level attestation, the Certifying Server operates using a single cryptographic identity. Upon initial deployment, the Certifying Server MUST generate a single Ed25519 key pair (the "Server DNA"). The private key MUST be stored securely within the MTA's restricted filesystem and MUST NOT be accessible to individual tenants or the unprivileged SMTP process. The key identifier MUST follow the format "zi2-cert-YYYY-MM". 3.3. Outbound Certification Prior to certification, the ZI2 engine MUST verify two conditions: Kadjo Expires 8 November 2026 [Page 4] Internet-Draft ZI2 Certified May 2026 1. The message contains exactly one RFC5322 "From:" header. If multiple "From:" headers are present, the engine MUST reject certification to prevent header smuggling. 2. The SMTP authenticated user (SASL login) or local envelope sender is explicitly authorized by local policy to send on behalf of the domain in the "From:" header. Upon successful authorization, the Certifying Server MUST construct a structured canonical certification payload string. The payload string MUST be formatted as semi-colon delimited tag-value pairs in the following strict order: v=1; from=; to=; cc=; rt=; subj=; ts=; mid=; sid=; kid=; bh=; n=; Recipient Binding & Header Injection Rules: The engine MUST bind ONLY to the visible RFC5322 "To:" and "Cc:" headers. It MUST NOT bind to or inject envelope recipients (RCPT TO) into the header. Furthermore, all tags in the payload string are REQUIRED. If an optional header is absent in the outbound message, its corresponding tag MUST be included with an empty value (e.g., "subj=;"). During Inbound Verification (Section 3.4), if a tag is empty but the verifier detects that the corresponding header is present in the received message, the verification MUST fail. The payload string MUST be signed with the Certifying Server's Ed25519 private key. The resulting signature and payload components are injected into the outbound message as a single X-ZI2-Certified header. 3.4. Inbound Verification The verifying server MUST check for the X-ZI2-Certified header, retrieve the public key, reconstruct the canonical structured payload, and verify the Ed25519 signature. Kadjo Expires 8 November 2026 [Page 5] Internet-Draft ZI2 Certified May 2026 To retrieve the public key, the verifying server MUST extract the kid= tag from the X-ZI2-Certified header, and the domain from the RFC5322 "From:" header. The verifier MUST perform a DNS TXT query for: ._zi2cert. (For example, if the header contains kid=zi2-srv1, the query is zi2-srv1._zi2cert.example.com) The verifier MUST NOT retrieve the key based solely on the "sid=" tag, as the sid is an unverified claim until the signature is validated against the domain's published key. The verification engine MUST also validate: 1. Timestamp freshness: The timestamp MUST be within 24 hours of the verification time and MUST NOT be more than 5 minutes in the future. 2. Body hash integrity: The reconstructed SHA-256 hash of the local decoded body (after DKIM Relaxed Canonicalization) MUST match the "bh=" tag. 3. Header integrity: The values used to reconstruct the payload MUST match the visible headers of the received message. If the signature verifies but the body hash integrity check fails, the message is presumed to have been modified in transit. In this scenario, the verifier SHOULD attempt ARC-Delegated Trust Verification as defined in Section 3.5. 3.5. ARC-Delegated Trust Verification To gracefully support legitimate forwarding that breaks the full-body hash, verifying servers MUST support ARC-Delegated Trust: 1. The verifier SHALL evaluate the message for a valid Authenticated Received Chain (ARC) [RFC8617]. 2. If a valid ARC chain exists, the verifier SHALL inspect the ARC-Authentication-Results (AAR) headers to locate the specific hop (i=N) that recorded the "zi2=pass" method result. 3. The verifier SHALL extract the ARC Sealer domain (the "d=" tag in the ARC-Message-Signature) for that exact hop (i=N). 4. The verifier SHALL evaluate that specific ARC Sealer domain against a locally configured Trusted Sealer Registry. It is explicitly insufficient for only the final hop of the ARC chain to be trusted; the hop asserting the ZI2 verification MUST be trusted. 5. If the ARC Sealer for hop i=N is trusted, and the chain validates, the verifier SHALL accept the delegated attestation. The final Kadjo Expires 8 November 2026 [Page 6] Internet-Draft ZI2 Certified May 2026 verification result MUST be recorded as "arc_delegated_pass", and the Trust Level MUST be assigned as Level 1 (DNS). If the ARC chain is invalid, the specific hop asserting the ZI2 result is untrusted, or the server identities do not align, the delegation MUST be rejected and the result recorded as "tampered". 4. Header Format The X-ZI2-Certified header uses tag=value format separated by semicolons. The header MUST NOT contain redundant hashes of message fields that can be reconstructed directly from the email meta-data. All tags are REQUIRED: o v: Protocol version (currently 1) o t: Signing timestamp (Unix epoch seconds) o sid: Server identifier (FQDN) o bh: Base64-encoded SHA-256 hash of the decoded and canonicalized body o n: Base64-encoded 16-byte random nonce o sig: Base64 Ed25519 signature o kid: Key identifier string The X-ZI2-Verified header uses tag=value format: o result: pass / spoofed / tampered / arc_delegated_pass / none o level: 0, 1, 2, or 3 o reason: Machine-readable explanation string o sid: Parsed server identifier o ts: Verification timestamp Base64 encoding MUST comply with [RFC4648] Section 4. Because Mail Transfer Agents (MTAs) frequently insert Folding White Space (FWS) to adhere to line length limits, verifiers MUST tolerate and strip whitespace, line-breaks, and carriage returns within Base64 strings prior to decoding. 5. DNS Publication A certifying server MUST instruct each hosted domain to publish the server's public key as a DNS TXT record at the subdomain "_zi2cert". Format: "v=ZI2CERT1; k=ed25519; p=; kid=" The explicit version string "v=ZI2CERT1;" ensures strict segregation from DKIM and DMARC parsers. Kadjo Expires 8 November 2026 [Page 7] Internet-Draft ZI2 Certified May 2026 Because multiple domains co-hosted on the same server publish the exact same server public key, the DNS record provides cryptographic proof that the domain owner explicitly authorizes this specific server instance's identity to dispatch its mail. 5.1. Key Rollover and Rotation To maintain cryptographic hygiene or recover from a suspected compromise, the Certifying Server MUST support non-disruptive key rotation of the Server Key. Servers MUST implement a transitional overlap window to prevent transit validation failures caused by DNS propagation delays. 1. The Certifying Server generates the new Ed25519 Server Key. 2. The server instructs all hosted domains to publish the new public key as a second, concurrent DNS TXT record alongside the existing record (using a new "kid=" identifier, e.g., kid=zi2-cert-2026-11). 3. The server waits a sufficient period (RECOMMENDED 48 hours) to ensure global DNS propagation of the new records. 4. The server switches the ZI2 engine to sign new outbound messages using the new key, injecting the new "kid=" value into the header. 5. After the 24-hour timestamp freshness window expires for the last messages signed by the old key, the server instructs tenants to safely remove the old DNS TXT records. Verifying servers easily accommodate this by strictly using the "kid=" tag in the incoming header to query the correct corresponding DNS record, ensuring in-flight emails are not invalidated during the transition. 6. Trust Levels o Level 3 (ABSOLUTE): Intra-server verification. The signing and verifying keys are mathematically linked locally. No network query required. Provides mathematical certainty. o Level 2 (VERIFIED): Key obtained via direct bilateral exchange. o Level 1 (DNS): Key obtained via DNS TXT record or HTTPS endpoint. o Level 0 (UNKNOWN): No certification present or verification failed. 6.1. AI Systems Integration Interface Modern email defense systems rely heavily on Machine Learning (ML) and Large Language Models (LLMs) to detect Business Email Compromise (BEC) and spear-phishing. These AI engines traditionally evaluate probabilistic signals, such as stylometry, semantic urgency, and domain reputation. Kadjo Expires 8 November 2026 [Page 8] Internet-Draft ZI2 Certified May 2026 The ZI2 protocol provides a deterministic, cryptographic origin signal that allows AI systems to anchor their analysis in mathematical fact. When an AI classification engine or downstream filter ingests an email bearing an X-ZI2-Verified header, it SHOULD map the results to its weighting engine as follows: 1. Levels 3 (ABSOLUTE) and 2 (VERIFIED): The origin is mathematically certain. The AI engine SHOULD bypass probabilistic sender-identity heuristics (e.g., "Does this sound like the CEO?") and rely on the verified server identity. 2. Level 1 (DNS) with "pass" or "arc_delegated_pass": The engine SHOULD positively weight the server-origin identity in its anomaly detection models, utilizing the "sid=" tag as a stable reputation anchor. 3. Result "spoofed" or "tampered": The engine MUST flag the message as a high-confidence attack, explicitly overriding any positive semantic scores or domain-reputation weights. Cryptographic failure supersedes linguistic legitimacy. 7. Security Considerations DNS Poisoning: Affects Trust Level 1 only. DNSSEC [RFC4033] SHOULD be deployed to secure the "_zi2cert" TXT records. Replay Attacks: Mitigated by the 128-bit nonce, the strict 24-hour timestamp freshness window, and the cryptographically bound Message-ID and Recipient fields. Verifiers MAY implement a stateful nonce cache to detect short-term replays within the 24-hour window, though the timestamp and Message-ID binding provide significant mitigation in stateless environments. Forwarding Abuse: An attacker cannot forge an ARC chain to bypass a broken ZI2 signature because the verifier strictly requires the ARC sealing domain to reside in a Local Policy Trusted Sealer Registry, and further enforces sid-to-domain alignment to prevent cross-domain delegation spoofing. Cross-Tenant Spoofing: Strictly prevented by the mandatory explicit authorization check required in Section 3.3. The ZI2 engine securely attests to the server's origin, but it fundamentally relies on the integrity of the MTA's local SASL or envelope authentication boundary to authorize the use of the server's signing key for a specific domain. 8. IANA Considerations This document requests the following actions from IANA. Kadjo Expires 8 November 2026 [Page 9] Internet-Draft ZI2 Certified May 2026 8.1. Email Authentication Methods Registry This document requests that IANA add a new method to the "Email Authentication Methods" registry (created by [RFC7601] and updated by [RFC8601]). o Method: zi2 o Defined In: [RFC-TBD] o ptype: header o property: sid o Value: The fully-qualified domain name (FQDN) of the certifying server, extracted from the "sid=" tag of the X-ZI2-Certified header. 8.2. Email Authentication Result Names Registry This document requests that IANA add the following result codes to the "Email Authentication Result Names" registry for the "zi2" method: o Code: pass o Description: The ZI2 Certified signature and body hash were successfully verified directly by the receiving MTA. o Code: spoofed o Description: A mandatory ZI2 Certified signature was missing from an email asserting to originate from a known local domain. o Code: tampered o Description: The ZI2 Certified signature or body hash failed verification, and no trusted ARC delegation was present. o Code: arc_delegated_pass o Description: The direct ZI2 signature failed due to transit modification, but a "pass" result was successfully delegated via a valid Authenticated Received Chain (ARC) from a trusted sealer. 8.3. Message Header Field Registry This document requests that IANA register the following new header fields in the "Message Header Field" registry: o Header Field Name: X-ZI2-Certified o Protocol: mail o Status: informational o Reference: [RFC-TBD] Kadjo Expires 8 November 2026 [Page 10] Internet-Draft ZI2 Certified May 2026 o Header Field Name: X-ZI2-Verified o Protocol: mail o Status: informational o Reference: [RFC-TBD] 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, . 9.2. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . Kadjo Expires 8 November 2026 [Page 11] Internet-Draft ZI2 Certified May 2026 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, . [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, . [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, . Author's Address Joseph-Israel Kadjo Zenith Intelligence Technologies Inc. Hagerstown, MD 21740 United States of America Email: dev@zi2.app URI: https://zi2.app Kadjo Expires 8 November 2026 [Page 12]