]> Invisible End-to-End E-mail Signatures PGPKeys.EU
andrewg@andrewg.com
ACLU
dkg@fifthhorseman.net
Thunderbird
kaie@thunderbird.net
int none Internet-Draft 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. The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction Several different standard structures for end-to-end cryptographically signed e-mail exist (see Sections , and of ). 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 , but can be easily extended to be used with 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 by providing an additional mechanism for producing and consuming OpenPGP-signed MIME e-mail.
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 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 ), and should be agnostic to and non-interfering with any such mechanism. "OpenPGP Signature" refers to a single OpenPGP Signature Packet as described by . "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.
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.
Unreadable Signed Mail A signed mail message that uses the S/MIME PKCS #7 signed-data Cryptographic Layer described in is unreadable by a receiving MUA that doesn't understand . By contrast, a mail message signed with an Invisible Signature should render normally by any legacy MUA.
Unknown Attachment A signed mail message that uses the S/MIME Multipart Signed Cryptographic Layer described in or the PGP/MIME Signing Cryptographic Layer (multipart/signed) described in 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.
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 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.
Invisibly Signed Message An Invisibly Signed Message has a specific MIME structure and uses a specific header field.
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 . We hereby specify a third PGP/MIME format in addition to the two listed in :
PGP/MIME Invisible Signing Cryptographic Layer (multipart/mixed)
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 , 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.
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 . The b parameter contains a base64-encoded blob that contains the cryptographic signature object of the type described by t.
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 . 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?
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.
Sender Guidance
Always Use Header Protection A message signed with an invisible signature MUST always use , signing every header field known to the sending MUA at message composition time.
Message Composition This updates the message composition function found in , 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: Create MIME tree inner as a copy of origbody Ensure Content-Type Header Field of inner has parameter hp set to "clear". For each header name and value (h,v) in origheaders: Add header h to inner with value v Normalize inner to bytestring innerbytes (see ) For each signing key key in crypto: Sign innerbytes with key, yielding signature sig 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). Create new MIME tree output with Content-Type multipart/mixed, with a single subpart, set to inner For each header name and value (h,v) in origheaders: Add header h to outer with value v Return output
Do Not Use Invisible Signature When Encrypting In accordance with , 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.
Recipient Guidance
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 .
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 . The normalized data is then passed to the signature verification routine as a raw bytestream.
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.
Example Rendering For example, consider a message with this structure:
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:
And its Cryptographic Status will be signed-only.
Unprotected Header Fields Added In Transit As noted in , 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.
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. 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.
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.
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.
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 about the first section of multipart/signed messages.
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 thus attacker-controlled. Otherwise, the security properties are equivalent to those of a multipart/signed message.
Performance Considerations
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.
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.
IANA Considerations
Register the Sig Header Field IANA is requested to update the Permanent Message Header Field Names registry to add the following entry: Header Field Name Template Protocol Status Trace Reference Sig   MIME     This document
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 ) This document b Base64-encoded Signature Content (whitespace permitted and ignored) This document (( TODO: do we need a registry for this? Are we expecting any new parameters? ))
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
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.
Guidance on End-to-End E-mail Security American Civil Liberties Union pEp Project Isode Ltd End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers to help mitigate those risks, and to make end-to-end e-mail simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems. OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). MIME Security with OpenPGP This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Header Protection for Cryptographically Protected E-mail American Civil Liberties Union pEp Project Isode Ltd S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME cryptographic protections. Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community. OpenPGP Example Keys and Certificates Mailpile ehf Independent American Civil Liberties Union The OpenPGP development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of OpenPGP certificates and keys for use when generating such samples. Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]
Test Vectors These test vectors show different examples of invisible signed messages.
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 .
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 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-- ]]>
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 .
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-- ]]>
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 .
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 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-- ]]>
Acknowledgments The authors would like to thank the attendees of the 9th OpenPGP Email Summit for feedback and suggestions.