Network Working Group T. Madaras Internet-Draft P. Estis Intended status: Experimental GuardSuite, a VXMSecure Company Expires: 5 June 2026 2 December 2025 GuardMail Protocol (GMP): Authenticated Messaging with Non-Repudiable Cryptographic Receipts draft-madaras-guardmail-gmp-00 Abstract This document specifies the GuardMail Protocol (GMP), a framework for authenticated outbound messaging that provides cryptographic proof of origin, integrity, and policy compliance for email and file-based communications. GMP introduces GuardMail Receipts (GMRs), signed metadata structures bound to sender identity and message content that allow recipients to verify authenticity independent of transport mechanisms such as SPF, DKIM, and DMARC. GMP provides a modern, interoperable method for organizations to protect against impersonation, deepfake-based fraud, unauthorized content changes, and spoofed internal communications in enterprise environments. 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 5 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Madaras & Estis Expires 5 June 2026 [Page 1] Internet-Draft GuardMail GMP December 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 5. GuardMail Receipt (GMR) Structure . . . . . . . . . . . . . . 4 6. Outbound Stamping Process . . . . . . . . . . . . . . . . . . 5 7. Verification Process (Inbound) . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Email and messaging systems commonly rely on SPF, DKIM, and DMARC to provide domain-level authentication and alignment. While these mechanisms help detect some forms of spoofing, they do not provide a sender-specific, action-bound, or content-bound non-repudiation mechanism. A message may appear to originate from a legitimate domain while still being malicious, manipulated, or unauthorized. GuardMail Protocol (GMP) introduces GuardMail Receipts (GMRs), which are cryptographically signed metadata objects that bind a sender identity to a particular message instance and its canonical content representation. A recipient or automated verifier can use the GMR to determine whether a message is authentic and intact, regardless of the underlying transport. GMP is designed to work with existing email infrastructure and can be deployed incrementally. It is intended to complement, not replace, mechanisms such as SPF, DKIM, and DMARC. Madaras & Estis Expires 5 June 2026 [Page 2] Internet-Draft GuardMail GMP December 2025 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology The following terms are used throughout this document: GMR (GuardMail Receipt) A cryptographically signed metadata structure associated with a specific outbound message instance, containing sender identity and content hashes. GMP (GuardMail Protocol) The protocol described in this document, defining how GMRs are constructed, attached, and verified. GMS (GuardMail Stamping Service) The service that creates and attaches GMRs to outbound messages on behalf of a sending domain or organization. VERIFIER A service or component that validates GMRs on received messages. MUA (Mail User Agent) Email client used by end-users. MTA (Mail Transfer Agent) Server responsible for transmitting email between domains. 4. Architectural Overview GMP assumes the following high-level architecture: 1. A sender composes a message using a MUA. 2. The message is submitted to a sending MTA, which forwards it to the GuardMail Stamping Service (GMS) or applies stamping locally. 3. The GMS computes content hashes, constructs a GMR, signs it, and attaches it to the message as a header and/or footer block. 4. The stamped message is delivered over existing SMTP infrastructure to the recipient's MTA and MUA. Madaras & Estis Expires 5 June 2026 [Page 3] Internet-Draft GuardMail GMP December 2025 5. A VERIFIER (running as part of the MUA, a plugin, or a gateway) extracts the GMR, recomputes hashes, validates the signature, and presents a verification status. GMP does not mandate where the GMS or VERIFIER reside; they MAY be implemented as standalone services, integrated gateways, MTA extensions, or client-side components. 5. GuardMail Receipt (GMR) Structure A GMR is a structured metadata object that MUST contain at least the following fields: * rid: A globally unique receipt identifier for this message. * sender_id: A sender identity string representing the originator. * org_id: An organization identifier for the sending domain or entity. * hdr_hash: A SHA3-256 hash of the canonicalized header set. * body_hash: A SHA3-256 hash of the canonicalized message body. * att_hash: A SHA3-256 hash of the attachments, or the string "NONE" if there are no attachments. * policy_id: An optional identifier referencing the policy or profile used when stamping this message. * ts_issued: The timestamp at which the GMR was created. * signature: A digital signature computed over the above fields using a key controlled by the GMS for the sending organization. * verify_url: An HTTPS URL for independent verification. The following header format is RECOMMENDED: X-GuardMail-Stamp: rid=; sender_id=; org_id=; hdr_hash=; body_hash=; att_hash=; ts=; sig_alg=; signature=; verify_url= A body footer MAY be added for human consumption: Madaras & Estis Expires 5 June 2026 [Page 4] Internet-Draft GuardMail GMP December 2025 ----BEGIN GUARDMAIL RECEIPT---- Receipt-ID: Sender-ID: Org-ID: Issued-At: Verification: https://verify.example.com/r/ ----END GUARDMAIL RECEIPT---- The header representation is authoritative for automated verification; the footer is primarily cosmetic. 6. Outbound Stamping Process The GuardMail Stamping Service (GMS) performs the following steps when stamping a message: 1. Canonicalize the headers and body. 2. Compute hdr_hash, body_hash, and att_hash. 3. Construct a GMR with the required fields. 4. Sign the GMR with an organizational key. 5. Insert the GMR into the message as an "X-GuardMail-Stamp" header and/or a footer block. 6. Deliver the stamped message to the next-hop MTA. MUAs and intermediate MTAs SHOULD preserve the GMR header and any associated footer blocks. 7. Verification Process (Inbound) A VERIFIER (or compatible component) MUST implement at least the following steps: 1. Extract the GMR from the "X-GuardMail-Stamp" header. 2. Canonicalize message headers and body using the same algorithm as the GMS. 3. Compute local hdr_hash, body_hash, and att_hash from the received message. 4. Compare the locally computed hashes with those contained in the GMR. Madaras & Estis Expires 5 June 2026 [Page 5] Internet-Draft GuardMail GMP December 2025 5. Validate the GMR signature using a trusted public key or certificate for the sending organization or GMS. 6. Optionally contact the verify_url endpoint for revocation checks, policy evaluation, or additional status information. Based on these checks, the VERIFIER SHOULD produce one of: * VALID * TAMPERED * UNTRUSTED * NOT FOUND 8. Security Considerations GMP is intended to raise the bar against impersonation, spoofing, and tampering by binding messages to both sender identity and content hashes through digital signatures. It does not replace the need for endpoint security, anti-malware, and user education. Implementers MUST: * Protect private keys used for GMR signing. * Implement safe key rotation and revocation mechanisms. * Address replay and downgrade attacks in the verification flow, including reuse of old GMRs with new messages or weaker policy profiles. GMP does not protect against compromise of the sender's device or account prior to GMR generation. If an attacker controls the sender's environment, they MAY be able to send malicious but syntactically "valid" messages. Additional controls (for example, strong authentication, device posture checks, and anomaly detection) are REQUIRED to mitigate those threats. GMP also does not replace the need for transport-level protections such as TLS or domain-based authentication mechanisms such as SPF, DKIM, and DMARC. Rather, it is intended to complement these mechanisms by providing cryptographic non-repudiation at the level of individual messages and senders. Madaras & Estis Expires 5 June 2026 [Page 6] Internet-Draft GuardMail GMP December 2025 9. IANA Considerations This document requests the registration of a new email header field in the "Provisional Message Header Field Names" registry: Header field name: X-GuardMail-Stamp Applicable protocol: mail Status: provisional Author/Change controller: IESG 10. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Tom Madaras GuardSuite, a VXMSecure Company Hollywood, FL 33021 United States of America Email: tom@vxmsecure.com Pat Estis GuardSuite, a VXMSecure Company Houston, TX United States of America Email: pat.estis@gmail.com Madaras & Estis Expires 5 June 2026 [Page 7]