none A. Gallagher, Ed.
Internet-Draft PGPKeys.EU
Updates: 3156 (if approved) D. K. Gillmor
Intended status: Informational ACLU
Expires: 13 November 2025 K. Engert
Thunderbird
12 May 2025
Unobtrusive End-to-End E-mail Signatures
draft-gallagher-email-unobtrusive-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
"unobtrusive" 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/unobtrusive-signatures/. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-gallagher-email-unobtrusive-
signatures/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/andrewgdotcom/unobtrusive-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 13 November 2025 [Page 1]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
This Internet-Draft will expire on 13 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 . . . . . . . . . . . . . . . . . 5
3.2. Unknown Attachment . . . . . . . . . . . . . . . . . . . 5
3.2.1. Reducing Confusion with name Parameter . . . . . . . 5
3.3. Broken Signature . . . . . . . . . . . . . . . . . . . . 6
4. Unobtrusively Signed Message . . . . . . . . . . . . . . . . 6
4.1. MIME structure . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. PGP/MIME Unobtrusive Signing Cryptographic Layer
(multipart/mixed) . . . . . . . . . . . . . . . . . . 6
4.2. Sig Header Field . . . . . . . . . . . . . . . . . . . . 7
4.3. Line Ending Normalization . . . . . . . . . . . . . . . . 7
5. Sender Guidance . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Always Use Header Protection . . . . . . . . . . . . . . 8
5.2. Message Composition . . . . . . . . . . . . . . . . . . . 8
5.3. Do Not Use Unobtrusive Signature When Encrypting . . . . 9
5.4. Message Canonicalization . . . . . . . . . . . . . . . . 9
5.5. OpenPGP Signature Details . . . . . . . . . . . . . . . . 9
6. Recipient Guidance . . . . . . . . . . . . . . . . . . . . . 9
6.1. Detecting an Unobtrusive Signature . . . . . . . . . . . 9
6.2. Validating an Unobtrusive Signature . . . . . . . . . . . 10
6.3. Message Rendering and the Cryptographic Summary . . . . . 10
6.3.1. Example Rendering . . . . . . . . . . . . . . . . . . 10
6.3.2. Unprotected Header Fields Added In Transit . . . . . 11
6.4. Signature Failure Handling . . . . . . . . . . . . . . . 11
6.5. Handling Multiple Signatures . . . . . . . . . . . . . . 11
6.6. Ignore Out-of-place Unobtrusive Signatures . . . . . . . 11
7. MTA Guidance . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Gallagher, et al. Expires 13 November 2025 [Page 2]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
9. Performance Considerations . . . . . . . . . . . . . . . . . 12
9.1. Rationale for Signature in MIME Part . . . . . . . . . . 12
9.2. No One-pass Message Generation . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. Register the Sig Header Field . . . . . . . . . . . . . 13
10.2. Create Registry for Sig Message Header Parameters . . . 13
10.3. Create Registry For t Parameter . . . . . . . . . . . . 14
10.4. Update multipart/mixed to Refer Here . . . . . . . . . . 14
10.5. Registration Policies . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 16
A.1. From Alice to Bob . . . . . . . . . . . . . . . . . . . . 16
A.2. From David to Alice . . . . . . . . . . . . . . . . . . . 17
A.3. From Alice to David . . . . . . . . . . . . . . . . . . . 18
A.4. Alice to David Followup . . . . . . . . . . . . . . . . . 20
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 21
Appendix C. Document History . . . . . . . . . . . . . . . . . . 21
C.1. Changes Between
draft-gallagher-email-invisible-signatures-00 and
draft-gallagher-email-unobtrusive-signatures-00 . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 transparent 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.
Gallagher, et al. Expires 13 November 2025 [Page 3]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
This document updates [RFC3156] by providing an additional mechanism
for producing and consuming OpenPGP-signed MIME e-mail.
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 Unobtrusive Signature scheme defined in this document is intended
to minimize or eliminate all of these problems.
Gallagher, et al. Expires 13 November 2025 [Page 4]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
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].
By contrast, a mail message signed with an Unobtrusive 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 Unobtrusive Signature is
merely encapsulated in a multipart/mixed outer layer. Legacy MUAs do
not render such an encapsulation as an attachment.
3.2.1. Reducing Confusion with name Parameter
For existing end-to-end multipart signature schemes, one partial
mitigation to this problem is to mark the signature part with an
explicit filename that a legacy MUA is likely to display to the
recipient. Concretely, some signing MUAs that generate multipart/
signed messages using PGP/MIME ([RFC3156]) will add a name="openpgp-
digital-signature.asc" parameter to the Content-Type header of the
application/pgp-signature MIME part.
For recipients who understand what an OpenPGP digital signature is
(even if their MUA can't interpret it), this might reduce the amount
of pushback they provide to the sender.
The Unobtrusive Signature scheme described in this document intends
to offer even less friction to the recipient using a Legacy MUA by
hiding the signature entirely.
Gallagher, et al. Expires 13 November 2025 [Page 5]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
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 Unobtrusively Signed message at all. And
an MUA compatible with this specification that encounters a message
with a broken Unobtrusive Signtature will never render an error that
it wouldn't have rendered on an unsigned message anyway, which
removes this disincentive to sign.
4. Unobtrusively Signed Message
An Unobtrusively Signed Message has a specific MIME structure and
uses a specific header field.
4.1. MIME structure
The top-level Content-Type of an unobtrusively 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 Unobtrusive 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.
Gallagher, et al. Expires 13 November 2025 [Page 6]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
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 Unobtrusively
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.
Whitespace is ignored in this value and MUST be ignored when
reassembling the original signature. In particular, the signing
process can safely insert FWS in this value in arbitrary places to
conform to line-length limits.
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.
4.3. Line Ending Normalization
Line endings in the message MUST be converted to CRLF format before
signing or verification. This ensures that an OpenPGP signature over
the message will be invariant for both binary and text mode
signatures.
5. Sender Guidance
Gallagher, et al. Expires 13 November 2025 [Page 7]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
5.1. Always Use Header Protection
A message signed with an unobtrusive signature MUST always use
[I-D.ietf-lamps-header-protection], signing every header field known
to the sending MUA at message composition time.
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 Unobtrusive 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. Canonicalize inner (see Section 5.4)
5. Convert inner to bytestring innerbytes
6. 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).
Gallagher, et al. Expires 13 November 2025 [Page 8]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
7. Create new MIME tree output with Content-Type multipart/mixed,
with a single subpart, set to inner
8. For each header name and value (h,v) in origheaders:
a. Add header h to outer with value v
9. Return output
5.3. Do Not Use Unobtrusive 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.
5.4. Message Canonicalization
The Protected Part, without any Sig header fields, SHOULD be
canonicalized following the patterns described in Section 3 of
[RFC3156]:
* 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
The canonicalized Protected Part MUST then be line ending normalized
as per Section 4.3 before creating the signature. A signature over a
message is more likely to be verifiable if the message is
canonicalized into a format robust against MTA modification in
transit.
5.5. OpenPGP Signature Details
The OpenPGP Signature is made over the canonical bytestring, and
binary mode (OpenPGP Signature Type 0x00) SHOULD be used.
6. Recipient Guidance
6.1. Detecting an Unobtrusive Signature
A receiving MUA detects the presence of an unobtrusive signature on a
message by verifying that:
Gallagher, et al. Expires 13 November 2025 [Page 9]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
* 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 Unobtrusive Signature
When validating an unobtrusive 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.
6.3. Message Rendering and the Cryptographic Summary
If the message has at least one Unobtrusive 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
Gallagher, et al. Expires 13 November 2025 [Page 10]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
If at least one Unobtrusive 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 Unobtrusively 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 unobtrusively signed message
where all unobtrusive 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 unobtrusive
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 unobtrusive 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 Unobtrusive Signatures
An unobtrusive signature Sig header field MUST NOT be evaluated
unless it is within the MIME headers of the only subpart of a
multipart/mixed message.
Gallagher, et al. Expires 13 November 2025 [Page 11]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
Evaluating a Sig header outside of this location might mean that a
modified message could still appear to be successfully verified. For
example, an unobtrusively 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
Unobtrusive 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.
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 Header Section it would not normally be
signed by DKIM, and would be vulnerable to inadvertent breakage by
naive MTAs.
Gallagher, et al. Expires 13 November 2025 [Page 12]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
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
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? ))
Gallagher, et al. Expires 13 November 2025 [Page 13]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
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.
10.5. Registration Policies
IANA is requested to set all registries within this document to use
the SPECIFICATION REQUIRED registration policy, see Section 4.6 of
[RFC8126]. This policy means that review and approval by a
designated expert is required, and that the IDs and their meanings
must be documented in a permanent and readily available public
specification, in sufficient detail so that interoperability between
independent implementations is possible.
11. References
11.1. Normative References
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-e2e-mail-guidance-17>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
header-protection-25>.
Gallagher, et al. Expires 13 November 2025 [Page 14]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
[OpenPGP] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/rfc/rfc9580>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001,
<https://www.rfc-editor.org/rfc/rfc3156>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
11.2. Informative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[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,
<https://www.rfc-editor.org/rfc/rfc6376>.
[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-03, 8 May 2025,
<https://datatracker.ietf.org/doc/html/draft-bre-openpgp-
samples-03>.
[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, <https://www.rfc-editor.org/rfc/rfc1847>.
Gallagher, et al. Expires 13 November 2025 [Page 15]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
Appendix A. Test Vectors
These test vectors show different examples of unobtrusive signed
messages.
A.1. From Alice to Bob
The message below is a common multipart/alternative e-mail, signed
with an unobtrusive signature. The signature should be verifiable
using the "Alice" v4 certificate found in Section 2.1.1 of
[I-D.bre-openpgp-samples].
Content-Type: multipart/mixed; boundary="5d6"
MIME-Version: 1.0
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Subject: This is a Test
Date: Thu, 01 May 2025 22:16:15 -0400
Message-ID: <uosig-0@openpgp.example>
--5d6
Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBQq
7wAKCRDyMVUMT0fjjr+3AP4nGDsaptk9I6EePoXftyevyH6luB2aSAzrD8o
xQVNWDQD/VQ/s85C3v6SAxtFDcBsn2H32Hd/yW5BsDx62gmpL7Aw=
MIME-Version: 1.0
From: Alice Lovelace <alice@openpgp.example>
To: Bob Babbage <bob@openpgp.example>
Subject: This is a Test
Date: Thu, 01 May 2025 22:16:15 -0400
Message-ID: <uosig-0@openpgp.example>
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
Gallagher, et al. Expires 13 November 2025 [Page 16]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
<html><head></head><body><p>Hi Bob,</p>
<p>This is Alice. I need you to:</p>
<ul>
<li>read this message</li>
<li>reply to it</li>
<li>delete it promptly.</li>
</ul>
<p>Thanks,
Alice</p></body></html>
--913--
--5d6--
A.2. From David to Alice
The message below is a simple text/plain e-mail, signed with an
unobtrusive 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 13 November 2025 [Page 17]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
Content-Type: multipart/mixed; boundary="a21"
MIME-Version: 1.0
From: David Deluxe <david@openpgp.example>
To: Alice Lovelace <alice@openpgp.example>
Subject: Checking in
Date: Fri, 02 May 2025 13:01:07 -0400
Message-ID: <uosig-1@openpgp.example>
--a21
Sig: t=p; b=wpIGABsIAAAAKSIhBkGZ2eqmaCp41aU09iv3YiKlTk3rx4Xb
5qbFs0WGAm/iBQJoFPpTAAAACgkQQZnZ6qZoKnhDIRA9tgkt50eA1ckzilm
9KndQt3t4iYlab66bvtP+kP9D7zaNzvC1vE+B6jPY1gUBOQMyF5CK3yC/xZ
Ol2ww+x8Y3PZ7OpZ1dPUlshDL5gA7ZAw==
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: David Deluxe <david@openpgp.example>
To: Alice Lovelace <alice@openpgp.example>
Subject: Checking in
Date: Fri, 02 May 2025 13:01:07 -0400
Message-ID: <uosig-1@openpgp.example>
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
--a21--
A.3. From Alice to David
The message below is a multipart/alternative e-mail with an image
attached, signed with an unobtrusive signature. The signature should
be verifiable using the "Alice" v4 certificate found in Section 2.1.1
of [I-D.bre-openpgp-samples].
Gallagher, et al. Expires 13 November 2025 [Page 18]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
Content-Type: multipart/mixed; boundary="3e4"
MIME-Version: 1.0
From: Alice Lovelace <alice@openpgp.example>
To: David Deluxe <david@openpgp.example>
Subject: Re: Checking in
Date: Fri, 02 May 2025 17:03:35 -0400
Message-ID: <uosig-2@openpgp.example>
In-Reply-To: <uosig-1@openpgp.example>
References: <uosig-1@openpgp.example>
--3e4
Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBUz
JwAKCRDyMVUMT0fjjmnRAQDKnIfyPyvE2lVlVOQl+H99TK+VFCvBaTZyTAV
xnKgJ1gEAjVDQ3idx4Z4wSN+pLhWS1LdpVbWdH7mW58gS0GBz5AM=
MIME-Version: 1.0
From: Alice Lovelace <alice@openpgp.example>
To: David Deluxe <david@openpgp.example>
Subject: Re: Checking in
Date: Fri, 02 May 2025 17:03:35 -0400
Message-ID: <uosig-2@openpgp.example>
In-Reply-To: <uosig-1@openpgp.example>
References: <uosig-1@openpgp.example>
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
<html><head></head><body><p>Hi David,</p>
<p>I think the attached logo might look good
Gallagher, et al. Expires 13 November 2025 [Page 19]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
on the website.</p>
<p>Thanks,
Alice</p></body></html>
--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--
--3e4--
A.4. Alice to David Followup
The message below is a multipart/alternative e-mail that is a self-
reply from about a week later. In the meantime, Alice has gotten a
new OpenPGP certificate, so the message is signed with both her old
key and her new key. This message's signatures should be verifiable
respectively using either the "Alice" v4 certificate found in
Section 2.1.1 of [I-D.bre-openpgp-samples] or the "Alice" v6
certificate found in Section 2.2.1 of [I-D.bre-openpgp-samples].
Content-Type: multipart/mixed; boundary="0cd"
MIME-Version: 1.0
From: Alice Lovelace <alice@openpgp.example>
To: David Deluxe <david@openpgp.example>
Subject: Re: Checking in
Date: Thu, 08 May 2025 18:41:05 -0400
Message-ID: <uosig-3@openpgp.example>
In-Reply-To: <uosig-2@openpgp.example>
References: <uosig-2@openpgp.example>
--0cd
Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaB0z
AQAKCRDyMVUMT0fjjtCJAQCLvEeDH/grJ9szJTEPumRz0lvQm1f3GHNuTnS
W9+SV/wD/YpPK4oMy2Cbrzo9JagpO4uxXkbCWQIHI9HFlwkz8Hg0=
Sig: t=p; b=wpIGABsIAAAAKSIhBuRqR5oGQqpTb/U1uxxDl7NeiBI/TgFl
Z9LvdROjBBHyBQJoHTMBAAAACgkQ5GpHmgZCqlOwFhA99dXXagDzmkcTALm
p1ZYQ0IyBvaqxRgRwNHw7VdYBSZ66F1vAjY44pdc8ynahPGHexB4AdfXFeb
K1GcqiREQgwF74RoCegJ6ZZkRfWCr3Cw==
MIME-Version: 1.0
Gallagher, et al. Expires 13 November 2025 [Page 20]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
From: Alice Lovelace <alice@openpgp.example>
To: David Deluxe <david@openpgp.example>
Subject: Re: Checking in
Date: Thu, 08 May 2025 18:41:05 -0400
Message-ID: <uosig-3@openpgp.example>
In-Reply-To: <uosig-2@openpgp.example>
References: <uosig-2@openpgp.example>
Content-Type: multipart/alternative; boundary="97a"; hp="clear"
--97a
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Hey David,
Also, please spell my name correctly in the
website's acknowledgements section.
Kind regards,
Alice
--97a
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
<html><head></head><body><p>Hey David,</p>
<p>Also, please spell my name correctly in the
website's acknowledgements section.</p>
<p>Kind regards,
Alice</p></body></html>
--97a--
--0cd--
Appendix B. Acknowledgments
The authors would like to thank the attendees of the 9th OpenPGP
Email Summit for feedback and suggestions.
Appendix C. Document History
Note to RFC Editor: this section should be removed before
publication.
Gallagher, et al. Expires 13 November 2025 [Page 21]
Internet-Draft Unobtrusive End-to-End E-mail Signatures May 2025
C.1. Changes Between draft-gallagher-email-invisible-signatures-00 and
draft-gallagher-email-unobtrusive-signatures-00
* Updated sender canonicalization guidance from MUST to SHOULD.
* Registries changed to SPECIFICATION REQUIRED.
* Improved test vectors.
* Renamed to "Unobtrusive Signatures".
* Explicitly allow folding whitespace.
* Document existing convention re attachment filenames.
* Fixed references.
* Various clarifications to wording.
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 13 November 2025 [Page 22]