none A. Gallagher, Ed. Internet-Draft PGPKeys.EU Updates: 3156 (if approved) D. K. Gillmor Intended status: Informational ACLU Expires: 3 November 2025 K. Engert Thunderbird 2 May 2025 Invisible End-to-End E-mail Signatures draft-gallagher-email-invisible-signatures-00 Abstract This document deals with end-to-end cryptographically signed e-mail. It introduces a novel structure for signed e-mail that is designed to avoid creating any disturbance in legacy e-mail clients. This "invisible" signature structure removes disincentives for signing e-mail. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://andrewgdotcom.gitlab.io/invisible-signatures/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-gallagher-email-invisible- signatures/. Source for this draft and an issue tracker can be found at https://gitlab.com/andrewgdotcom/invisible-signatures/. 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." Gallagher, et al. Expires 3 November 2025 [Page 1] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 This Internet-Draft will expire on 3 November 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Problems With Existing Signature Schemes . . . . . . . . . . 4 3.1. Unreadable Signed Mail . . . . . . . . . . . . . . . . . 4 3.2. Unknown Attachment . . . . . . . . . . . . . . . . . . . 5 3.3. Broken Signature . . . . . . . . . . . . . . . . . . . . 5 4. Invisibly Signed Message . . . . . . . . . . . . . . . . . . 5 4.1. MIME structure . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. PGP/MIME Invisible Signing Cryptographic Layer (multipart/mixed) . . . . . . . . . . . . . . . . . . 6 4.2. Sig Header Field . . . . . . . . . . . . . . . . . . . . 6 4.3. Message Normalization . . . . . . . . . . . . . . . . . . 7 4.4. OpenPGP Signature Details . . . . . . . . . . . . . . . . 7 5. Sender Guidance . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Always Use Header Protection . . . . . . . . . . . . . . 7 5.2. Message Composition . . . . . . . . . . . . . . . . . . . 8 5.3. Do Not Use Invisible Signature When Encrypting . . . . . 9 6. Recipient Guidance . . . . . . . . . . . . . . . . . . . . . 9 6.1. Detecting an Invisible Signature . . . . . . . . . . . . 9 6.2. Validating an Invisible Signature . . . . . . . . . . . . 9 6.3. Message Rendering and the Cryptographic Summary . . . . . 10 6.3.1. Example Rendering . . . . . . . . . . . . . . . . . . 10 6.3.2. Unprotected Header Fields Added In Transit . . . . . 10 6.4. Signature Failure Handling . . . . . . . . . . . . . . . 10 6.5. Handling Multiple Signatures . . . . . . . . . . . . . . 11 6.6. Ignore Out-of-place Invisible Signatures . . . . . . . . 11 7. MTA Guidance . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Performance Considerations . . . . . . . . . . . . . . . . . 12 9.1. Rationale for Signature in MIME Part . . . . . . . . . . 12 Gallagher, et al. Expires 3 November 2025 [Page 2] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 9.2. No One-pass Message Generation . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10.1. Register the Sig Header Field . . . . . . . . . . . . . 12 10.2. Create Registry for Sig Message Header Parameters . . . 13 10.3. Create Registry For t Parameter . . . . . . . . . . . . 13 10.4. Update multipart/mixed to Refer Here . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 15 A.1. From Alice to Bob . . . . . . . . . . . . . . . . . . . . 15 A.2. From David to Alice . . . . . . . . . . . . . . . . . . . 16 A.3. From Alice to David . . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Several different standard structures for end-to-end cryptographically signed e-mail exist (see Sections 4.1.1.1, 4.1.1.2 and 4.1.2.1 of [I-D.ietf-lamps-e2e-mail-guidance]). But the existing mechanisms have some undesirable properties which can make such mail difficult for the recipient to handle in some instances, particularly when read by legacy e-mail clients that don't understand the signing structure. This document offers another signed e-mail structure, which is designed to be invisible to legacy e-mail clients. The goal of this mechanism is to help e-mail clients commit to signing every outbound message, which reduces complexity for the user of the mail client. The mechanism is capable of working with any signature mechanism, as well as transporting multiple signatures over a single message. It is specified initially for [OpenPGP], but can be easily extended to be used with [CMS] or other signature formats. This mechanism is intended only for signed-only messages. A message that is encrypted-and-signed MUST NOT use this mechanism, since any existing MUA that can decrypt an encrypted-and-signed message already handles the signatures on such a message correctly. This document updates [RFC3156] by providing an additional mechanism for producing and consuming OpenPGP-signed MIME e-mail. Gallagher, et al. Expires 3 November 2025 [Page 3] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 2. Conventions and Definitions 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. * "Signed Mail" is used to refer to Internet Mail Messages that are cryptographically signed by the sender of the message, and expected to be validated by the recipient of the message. This document does not consider any cryptographic signature mechanism that is not end-to-end (such as [DKIM]), and should be agnostic to and non-interfering with any such mechanism. * "OpenPGP Signature" refers to a single OpenPGP Signature Packet as described by Section 5.2 of [OpenPGP]. * "MUA" refers to a Mail User Agent, which is also known as an e-mail client. For end-to-end signed mail, the sender's MUA performs message composition and injection into the mail system, and the receiver's MUA performs message ingestion from the mail system and rendering to the user. * "Legacy MUA" refers to a MUA that does not know about this specification. * "MTA" refers to a Message Transfer Agent, for example an SMTP server that relays Internet mail messages from one point to another. 3. Problems With Existing Signature Schemes Existing end-to-end signature schemes for mail can trigger a set of annoyances for a recipient who uses a MUA that doesn't understand these structures. These annoyances can cause the recipient to complain to the sender. The easiest way for the sender to try to accommodate the recipient in this case is to simply not sign mail. The Invisible Signature scheme defined in this document is intended to minimize or eliminate all of these problems. 3.1. Unreadable Signed Mail A signed mail message that uses the S/MIME PKCS #7 signed-data Cryptographic Layer described in Section 4.1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance] is unreadable by a receiving MUA that doesn't understand [CMS]. Gallagher, et al. Expires 3 November 2025 [Page 4] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 By contrast, a mail message signed with an Invisible Signature should render normally by any legacy MUA. 3.2. Unknown Attachment A signed mail message that uses the S/MIME Multipart Signed Cryptographic Layer described in Section 4.1.1.1 of [I-D.ietf-lamps-e2e-mail-guidance] or the PGP/MIME Signing Cryptographic Layer (multipart/signed) described in Section 4.1.2.1 of [I-D.ietf-lamps-e2e-mail-guidance] has a separate MIME part that contains the message signature. A receiving MUA that doesn't understand these structures will often render the signature as an "attachment". This can cause confusion and anxiety to the user of the MUA, and they will sometimes respond to the sender with the complaint "I can't open your attachment". By contrast, a mail message signed with an Invisible Signature is merely encapsulated in a multipart/mixed outer layer. Legacy MUAs do not render such an encapsulation as an attachment. 3.3. Broken Signature In some cases, mail is tampered with in transit, whether deliberately or maliciously. In this case, for a MUA that does understand these messages, some MUAs will visibly complain to the recipient that there is a failed signature. If unsigned mail receives no comparable warning, then the act of adding a signature to a message that might traverse a modifiable path is risky. An MUA compliant with Section 6.4 of [I-D.ietf-lamps-e2e-mail-guidance] will not create such a warning, but many MUAs do not yet comply with that guidance. By contrast, a legacy MUA won't render anything about the cryptographic status of an Invisibly Signed message at all. And an MUA compatible with this specification that encounters a message with a broken Invisible Signtature will never render an error that it wouldn't have rendered on an unsigned message anyway, which removes this disincentive to sign. 4. Invisibly Signed Message An Invisibly Signed Message has a specific MIME structure and uses a specific header field. Gallagher, et al. Expires 3 November 2025 [Page 5] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 4.1. MIME structure The top-level Content-Type of an invisibly signed message is multipart/mixed, and it has a single MIME subpart, which this specification refers to as the "Protected Part". The Protected Part's header sections' first header field is Sig, described in Section 4.2. We hereby specify a third PGP/MIME format in addition to the two listed in Section 4.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]: 4.1.1. PGP/MIME Invisible Signing Cryptographic Layer (multipart/mixed) └┬╴multipart/mixed └─╴[protected part] This MIME layer offers authenticity and integrity IFF the Protected Part contains one or more valid Sig: headers. This format is a Simple Cryptographic Envelope as specified in Section 4.4.1 of [I-D.ietf-lamps-e2e-mail-guidance], and the Protected Part (with leading Sig Header Fields removed) is the Cryptographic Payload. This MIME structure MUST NOT be used as part of a Multilayer Cryptographic Envelope. If it is found anywhere but the outside of the message it MUST NOT be treated as a Cryptographic Layer. 4.2. Sig Header Field This specification defines a new header field, named Sig. Sig is only meaningful if it appears in the Protected Part of an Invisibly Signed Message, before any non-Sig header field. It contains parameters, only two of which are currently defined. * The t parameter indicates the type of the signature with its value, and the only value currently defined is p, meaning an OpenPGP signature. See Section 10.3. * The b parameter contains a base64-encoded blob that contains the cryptographic signature object of the type described by t. Gallagher, et al. Expires 3 November 2025 [Page 6] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 4.3. Message Normalization The Protected Part, without any Sig header fields, MUST be canonicalized to a bytestring in order to create or verify the signature. This is done following the patterns described in Section 3 of [RFC3156]. * Line endings converted to CRLF * Content-Encoding is used to make the message 7-bit clean * End of line trailing whitespace is stripped or encoded to non- whitespace * If "From " starts a line, at least one letter of it should be encoded This is all done for two reasons: * to make the message unlikely to be modified by existing MTAs, and * to make the signature invariant no matter whether the OpenPGP signature is text-mode or binary-mode. FIXME: is all this really necessary in 2025? What if we said that an Invisibly Signed Message that needs 8BITMIME simply can't be transmitted across an MTA that doesn't support 8BITMIME? Or what if we decided that it's OK if the signature breaks in that case? 4.4. OpenPGP Signature Details The OpenPGP Signature is made over the canonical bytestring, in binary mode (OpenPGP Signature Type 0x00). Note that if multiple Sig header fields appear in a single message, each Sig header field represents a signature over the Protected Part without any Sig header field. That is, each Sig signs the same content, and the order of the Sig header fields among themselves doesn't matter as long as every Sig header field precedes all non-Sig header fields in the Header Section of the Protected Part. 5. Sender Guidance 5.1. Always Use Header Protection A message signed with an invisible signature MUST always use [I-D.ietf-lamps-header-protection], signing every header field known to the sending MUA at message composition time. Gallagher, et al. Expires 3 November 2025 [Page 7] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 5.2. Message Composition This updates the message composition function found in Section 5.1 of [I-D.ietf-lamps-e2e-mail-guidance], using the same parameters. * origbody: the traditional unprotected message body as a well- formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has structural header fields present. * origheaders: the intended non-structural header fields for the message, represented here as a list of (h,v) pairs, where h is a header field name and v is the associated value. * crypto: an indication that the message is to be signed with one or more Invisible Signatures. This contains a list of one or more secret keys. Each key will make one signature. The algorithm returns a MIME object that is ready to be injected into the mail system: 1. Create MIME tree inner as a copy of origbody 2. Ensure Content-Type Header Field of inner has parameter hp set to "clear". 3. For each header name and value (h,v) in origheaders: a. Add header h to inner with value v 4. Normalize inner to bytestring innerbytes (see Section 4.3) 5. For each signing key key in crypto: a. Sign innerbytes with key, yielding signature sig b. Prepend a Header Field named Sig to inner with two parameters, t (set to the literal string p) and b (set to the base64-encoded value of sig). 6. Create new MIME tree output with Content-Type multipart/mixed, with a single subpart, set to inner 7. For each header name and value (h,v) in origheaders: a. Add header h to outer with value v 8. Return output Gallagher, et al. Expires 3 November 2025 [Page 8] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 5.3. Do Not Use Invisible Signature When Encrypting In accordance with Section 5.2 of [I-D.ietf-lamps-e2e-mail-guidance], when sending end-to-end encrypted messages an MUA MUST place end-to- end signatures inside the encrypted data. This mechanism is therefore not applicable to encrypted messages. 6. Recipient Guidance 6.1. Detecting an Invisible Signature A receiving MUA detects the presence of an invisible signature on a message by verifying that: * the message Content-Type is multipart/mixed, and * there is exactly one top-level subpart (though that subpart itself may be multipart), and * the Content-Type of that top-level subpart has parameter hp="clear", and * the first header field of the top-level subpart is named Sig, and * the top-level subpart has a From header field, and its addr-spec matches the addr-spec in the message's From header field. This last requirement (matching From addr-specs) is an anti-spoofing measure, by analogy with Section 4.4 of [I-D.ietf-lamps-header-protection]. 6.2. Validating an Invisible Signature When validating an invisible signature, the signature data (i.e. the value of the b field) is converted from Base64 to binary format to recover the signature packet. The signed object is extracted from the multipart/mixed part by selecting every octet that comes after the CRLF that terminates the last Sig header, and before the CRLF that immediately precedes the trailing MIME boundary. The signed object is then normalized as described in Section 4.3. The normalized data is then passed to the signature verification routine as a raw bytestream. Gallagher, et al. Expires 3 November 2025 [Page 9] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 6.3. Message Rendering and the Cryptographic Summary If the message has at least one Invisible Signature which validates, then the MUA SHOULD render the message as though the top-level subpart is the message itself. The Cryptographic Summary of the message SHOULD indicate that the message is signed-only, and that all header fields present in the top-level subpart share that Cryptographic Status. 6.3.1. Example Rendering For example, consider a message with this structure: A └┬╴multipart/mixed B └┬╴multipart/alternative; hp="clear" [Cryptographic Payload] C ├─╴text/plain D └─╴text/html If at least one Invisible Signature is present as a leading Sig header field in B, and it validates correctly, the message should be rendered the same way as this message: B └┬╴multipart/alternative C ├─╴text/plain D └─╴text/html And its Cryptographic Status will be signed-only. 6.3.2. Unprotected Header Fields Added In Transit As noted in Section 7 of [I-D.ietf-lamps-header-protection], it's possible that a MUA encounters some Header Fields on the outer message (in the Header Section of A in the example above) which could not have been known by the sender. If any such fields would normally be rendered in some fashion by the MUA on an unsigned message, it MAY consider rendering them even on a signed-only Invisibly Signed message, but it should take care to indicate that they do not share the signed-only Cryptographic Status with the rest of the message. 6.4. Signature Failure Handling Sometimes a receiving MUA encounters an invisibly signed message where all invisible signatures fail to validate. The receiving MUA MUST NOT present the user with a cryptographic status that is different from a message with no signature at all. That is, the message's Cryptographic Status SHOULD be unprotected. Gallagher, et al. Expires 3 November 2025 [Page 10] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 If a message gets tampered with in such a way that all invisible signatures are broken, the recipient should see the message as though it were a normal unsigned message. 6.5. Handling Multiple Signatures If more than one invisible signature is present in a message, the receiving MUA MUST verify each signature against the known certificates associated with the indicated sender. As long as one of the signatures validates, the message should be treated as correctly signed, even if all the other signatures are invalid. 6.6. Ignore Out-of-place Invisible Signatures An invisible signature Sig header field MUST NOT be evaluated unless it is within the MIME headers of the only subpart of a multipart/ mixed message. Evaluating a Sig header outside of this location might mean that a modified message could still appear to be successfully verified. For example, an invisibly signed message might be included as a sub-part of another multipart message, or be transformed into a non-MIME message with different message headers than the original email. This could conceivably be used by an attacker to make subtle changes to the meaning of a message without altering the content of the Protected Part. 7. MTA Guidance An MTA or any other message relay service that observes a message with Content-Type multipart/mixed that is a single part MUST NOT alter the content of this message body in any way, including, but not limited to, changing the content transfer encoding of the body part or any of its encapsulated body parts. This corresponds to the guidance in Section 2.1 of [RFC1847] about the first section of multipart/signed messages. 8. Security Considerations Based on the principle that "a broken signature is the same as no signature", a receiving MUA MUST NOT display any warnings if an Invisible Signature fails to verify, unless the user has requested debugging output. This is because if an MITM can modify a message in transit, then they can choose whether or not to also remove the (now invalid) signature. If the receiving MUA displayed a more severe warning for a broken signature than for a missing one (or vice versa), the MITM could choose to modify the message in such a way that would result in the less-severe warning. The warning message is Gallagher, et al. Expires 3 November 2025 [Page 11] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 thus attacker-controlled. Otherwise, the security properties are equivalent to those of a multipart/signed message. 9. Performance Considerations 9.1. Rationale for Signature in MIME Part * An MTA is more likely to modify, reorder, or enforce limits on header fields associated with the entire message than it is to corrupt header fields in the subpart. * Any DKIM signature that includes the body of the message will cover the end-to-end signature. If the end-to-end signature was in the outer message it would not normally be signed by DKIM, and would be vulnerable to inadvertent breakage by naive MTAs. 9.2. No One-pass Message Generation Because the signature is included first in the message, it is not possible to generate the message in a single pass. A sending MUA that needs to generate a signed outbound message in a single pass should use another end-to-end signing mechanism, like multipart/signed. 10. IANA Considerations 10.1. Register the Sig Header Field IANA is requested to update the Permanent Message Header Field Names registry to add the following entry: +============+==========+==========+========+=======+===========+ | Header | Template | Protocol | Status | Trace | Reference | | Field Name | | | | | | +============+==========+==========+========+=======+===========+ | Sig | | MIME | | | This | | | | | | | document | +------------+----------+----------+--------+-------+-----------+ Table 1: Permanent Message Header Field Names Gallagher, et al. Expires 3 November 2025 [Page 12] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 10.2. Create Registry for Sig Message Header Parameters IANA is requested to create a registry titled "Sig Message Header Parameters" in the "Message Headers" group of registries, with the following initial contents: +======+======================================+===============+ | Name | Description | Reference | +======+======================================+===============+ | t | Type of Signature (see Section 10.3) | This document | +------+--------------------------------------+---------------+ | b | Base64-encoded Signature Content | This document | | | (whitespace permitted and ignored) | | +------+--------------------------------------+---------------+ Table 2: Sig Message Header Parameters (( TODO: do we need a registry for this? Are we expecting any new parameters? )) 10.3. Create Registry For t Parameter IANA is requested to create a registry titled "Sig Message Header Signature Types" in the "Message Headers" group of registries, with the following initial contents: +=======+===================================+===============+ | Value | Description | Reference | +=======+===================================+===============+ | p | A single OpenPGP Signature packet | This document | +-------+-----------------------------------+---------------+ Table 3: Sig Message Header Signature Types 10.4. Update multipart/mixed to Refer Here IANA is requested to update the "multipart/mixed" entry in the Media Types registry, to add a reference to this document. 11. References 11.1. Normative References Gallagher, et al. Expires 3 November 2025 [Page 13] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 [I-D.ietf-lamps-e2e-mail-guidance] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Guidance on End-to-End E-mail Security", Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-17, 8 January 2025, . [I-D.ietf-lamps-header-protection] Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header Protection for Cryptographically Protected E-mail", Work in Progress, Internet-Draft, draft-ietf-lamps-header- protection-25, 6 January 2025, . [OpenPGP] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [DKIM] 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, . Gallagher, et al. Expires 3 November 2025 [Page 14] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 [I-D.bre-openpgp-samples] Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP Example Keys and Certificates", Work in Progress, Internet-Draft, draft-bre-openpgp-samples-02, 16 April 2025, . [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, October 1995, . Appendix A. Test Vectors These test vectors show different examples of invisible signed messages. A.1. From Alice to Bob The message below is a common multipart/alternative e-mail, signed with an invisible signature. The signature should be verifiable using the "Alice" certificate found in Section 2.1 of [I-D.bre-openpgp-samples]. Content-Type: multipart/mixed; boundary="89d" MIME-Version: 1.0 From: Alice Lovelace To: Bob Babbage Subject: This is a Test Date: Thu, 01 May 2025 22:16:15 -0400 Message-ID: --89d Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBQq 7wAKCRDyMVUMT0fjjixaAQCKo/ILDinzplUkebnERgKApWHoytKnP7rITQl WT0JNIwEAs7phDDVb1a/Dhy5lHJg2mU4Bu6HH8/VHnU9fqp1sywo= MIME-Version: 1.0 From: Alice Lovelace To: Bob Babbage Subject: This is a Test Date: Thu, 01 May 2025 22:16:15 -0400 Message-ID: Content-Type: multipart/alternative; boundary="913"; hp="clear" --913 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Gallagher, et al. Expires 3 November 2025 [Page 15] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 Hi Bob, This is Alice. I need you to: - read this message - reply to it - delete it promptly. Thanks, Alice --913 Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

Hi Bob,

This is Alice. I need you to:

  • read this message
  • reply to it
  • delete it promptly.

Thanks, Alice

--913-- --89d-- A.2. From David to Alice The message below is a simple text/plain e-mail, signed with an invisible signature. The signature should be verifiable using the "David" certificate found in Section 5.1 of [I-D.bre-openpgp-samples]. Gallagher, et al. Expires 3 November 2025 [Page 16] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 Content-Type: multipart/mixed; boundary="593" MIME-Version: 1.0 From: David Deluxe To: Alice Lovelace Subject: Checking in Date: Fri, 02 May 2025 13:01:07 -0400 Message-ID: --593 Sig: t=p; b=wpIGABsIAAAAKSIhBkGZ2eqmaCp41aU09iv3YiKlTk3rx4Xb 5qbFs0WGAm/iBQJoFPpTAAAACgkQQZnZ6qZoKniIQxCd+H4MGl/IITzJsjA 9q4FguPa7PmjhMulQsCT6bO0sXu6PWMJEE621/CnbUnRBwZnisYHwPpIR+S bduePAM5e25Xs7d+lsIJl65ffoVUJxAQ== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: David Deluxe To: Alice Lovelace Subject: Checking in Date: Fri, 02 May 2025 13:01:07 -0400 Message-ID: Content-Type: text/plain; charset="us-ascii"; hp="clear" Alice! So good to see you earlier. I hope you will have a chance to check out our new website: https://openpgp.example/ and tell me what you think. All the best, David --593-- A.3. From Alice to David The message below is a multipart/alternative e-mail with an image attached, signed with an invisible signature. The signature should be verifiable using the "Alice" certificate found in Section 2.1 of [I-D.bre-openpgp-samples]. Gallagher, et al. Expires 3 November 2025 [Page 17] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 Content-Type: multipart/mixed; boundary="cf0" MIME-Version: 1.0 From: Alice Lovelace To: David Deluxe Subject: Re: Checking in Date: Fri, 02 May 2025 17:03:35 -0400 Message-ID: In-Reply-To: References: --cf0 Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBUz JwAKCRDyMVUMT0fjjlavAP9Id9p5b5H17IBKVqaYq2NSwb4Er+/IWq19MnY AKhOlwgEAva0huFRnH4FNQpDG58E6l4o05BlzIa2Y+BTXGLqX/QI= MIME-Version: 1.0 From: Alice Lovelace To: David Deluxe Subject: Re: Checking in Date: Fri, 02 May 2025 17:03:35 -0400 Message-ID: In-Reply-To: References: Content-Type: multipart/mixed; boundary="d64"; hp="clear" --d64 Content-Type: multipart/alternative; boundary="f4f" MIME-Version: 1.0 --f4f Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Hi David, I think the attached logo might look good on the website. Thanks, Alice --f4f Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

Hi David,

I think the attached logo might look good Gallagher, et al. Expires 3 November 2025 [Page 18] Internet-Draft Invisible End-to-End E-mail Signatures May 2025 on the website.

Thanks, Alice

--f4f-- --d64 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="logo.png" iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAAcElEQVR42uVTOxbA MAgS739nO3TpRw20dqpbfARQEjOywiwYnCtkDKnbcLk66sqlT+zt9cidkE+6KwkZ sgrzfcqVMpL2jo0447gYDpeArk+OnJHkIhAfTPRicihAf5YJrw7vjv0ZWRWM/uli vdPf1QZ2kDD9xppd8wAAAABJRU5ErkJggg== --d64-- --cf0-- Appendix B. Acknowledgments The authors would like to thank the attendees of the 9th OpenPGP Email Summit for feedback and suggestions. Authors' Addresses Andrew Gallagher (editor) PGPKeys.EU Email: andrewg@andrewg.com Daniel Kahn Gillmor ACLU Email: dkg@fifthhorseman.net Kai Engert Thunderbird Email: kaie@thunderbird.net Gallagher, et al. Expires 3 November 2025 [Page 19]