



none                                                   A. Gallagher, Ed.
Internet-Draft                                                PGPKeys.EU
Updates: 3156 (if approved)                                D. K. Gillmor
Intended status: Informational                                      ACLU
Expires: 27 December 2025                                      K. Engert
                                                             Thunderbird
                                                            25 June 2025


                Unobtrusive End-to-End Email Signatures
            draft-gallagher-email-unobtrusive-signatures-01

Abstract

   This document deals with end-to-end cryptographically signed email.
   It introduces a novel structure for signed email that is designed to
   avoid creating any disturbance in legacy email clients.  This
   "unobtrusive" signature structure removes disincentives for signing
   email.

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 27 December 2025                [Page 1]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   This Internet-Draft will expire on 27 December 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  . . . . . . . . . .   5
     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 . . . . . . . . . . . . . . . .   8
   5.  Sender Guidance . . . . . . . . . . . . . . . . . . . . . . .   8
     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 . . . . . . . . . . . . . . . .  10
   6.  Recipient Guidance  . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Detecting an Unobtrusive Signature  . . . . . . . . . . .  10
     6.2.  Validating an Unobtrusive Signature . . . . . . . . . . .  10
     6.3.  Message Rendering and the Cryptographic Summary . . . . .  11
       6.3.1.  Example Rendering . . . . . . . . . . . . . . . . . .  11
       6.3.2.  Unprotected Header Fields Added In Transit  . . . . .  11
     6.4.  Signature Failure Handling  . . . . . . . . . . . . . . .  11
     6.5.  Handling Multiple Signatures  . . . . . . . . . . . . . .  12
     6.6.  Ignore Out-of-place Unobtrusive Signatures  . . . . . . .  12
   7.  MTA Guidance  . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13



Gallagher, et al.       Expires 27 December 2025                [Page 2]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   9.  Performance Considerations  . . . . . . . . . . . . . . . . .  13
     9.1.  Rationale for Signature in MIME Part  . . . . . . . . . .  13
     9.2.  No One-pass Message Generation  . . . . . . . . . . . . .  14
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Register the Sig Header Field  . . . . . . . . . . . . .  14
     10.2.  Create Registry for Sig Message Header Parameters  . . .  14
     10.3.  Create Registry For t Parameter  . . . . . . . . . . . .  15
     10.4.  Update multipart/mixed to Refer Here . . . . . . . . . .  15
     10.5.  Registration Policies  . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  17
     A.1.  From Alice to Bob . . . . . . . . . . . . . . . . . . . .  17
     A.2.  From David to Alice . . . . . . . . . . . . . . . . . . .  18
     A.3.  From Alice to David . . . . . . . . . . . . . . . . . . .  19
     A.4.  Alice to David Followup . . . . . . . . . . . . . . . . .  21
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  22
     B.1.  Changes Between
           draft-gallagher-email-unobtrusive-signatures-00 and
           draft-gallagher-email-unobtrusive-signatures-01 . . . . .  22
     B.2.  Changes Between
           draft-gallagher-email-invisible-signatures-00 and
           draft-gallagher-email-unobtrusive-signatures-00 . . . . .  23
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   Several different standard structures for end-to-end
   cryptographically signed email 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 email clients that don't understand the signing
   structure.  This document offers another signed email structure,
   which is designed to be transparent to legacy email clients.

   The goal of this mechanism is to help email 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.







Gallagher, et al.       Expires 27 December 2025                [Page 3]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   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 email.

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 email
      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.

   *  "CRLF" refers to "Carriage Return followed by Line Feed", the
      standard email line-ending sequence of two octets, CR (0x0D) and
      LF (0x0A).









Gallagher, et al.       Expires 27 December 2025                [Page 4]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


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.

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.



Gallagher, et al.       Expires 27 December 2025                [Page 5]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   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.

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)





Gallagher, et al.       Expires 27 December 2025                [Page 6]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   └┬╴multipart/mixed
    └─╴[protected part]

   This MIME layer offers authenticity and integrity if and only if 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 all 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 Folding White Space (Section 3.2.2 of
      [RFC5322]) 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
   (with all leading Sig Header Fields removed).  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.  Sig header fields MUST NOT appear in a non-leading position.









Gallagher, et al.       Expires 27 December 2025                [Page 7]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


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

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.  If h is Sig, skip that header, otherwise

       b.  Add header h to inner with value v

   4.  Canonicalize inner (see Section 5.4)



Gallagher, et al.       Expires 27 December 2025                [Page 8]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   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).

   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 (with all leading Sig Header Fields removed)
   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 any line begins with the string "From ", either the Quoted-
      Printable or Base64 MIME encoding MUST be applied, and if Quoted-
      Printable is used, at least one of the characters in the string
      "From " MUST 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.




Gallagher, et al.       Expires 27 December 2025                [Page 9]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


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:

   *  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 (that
   is, 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 leading 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 27 December 2025               [Page 10]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


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

   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.



Gallagher, et al.       Expires 27 December 2025               [Page 11]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   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, and

   *  it appears before any non-Sig header field

   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.











Gallagher, et al.       Expires 27 December 2025               [Page 12]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


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 alternate design considered for unobtrusive signatures was to
   simply place the Sig header in the Outer Header Section of the
   message itself, without requiring any additional MIME structure.
   This was rejected in favor of the MIME structure described in
   Section 4.1 for the following reasons:

   *  Unobtrusive signatures always offer Header Protection aligned with
      [I-D.ietf-lamps-header-protection], so the signature needs to be
      able to cover those Header Fields generated by the sending MUA.
      But we know that most received messages contain a mix of Header
      Fields generated by the sending MUA and Header Fields injected by
      MTAs that touch the message in transit.

   *  Placing the signature as a Header Field in the Outer Header
      Section raises challenges in identifying which Header Fields are
      covered by the signature.

   *  An MTA is more likely to modify, reorder, or enforce limits on
      Header Fields in the message's Outer Header Section 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 it is part of the message body.
      If the end-to-end signature was in the message's Outer Header
      Section it would not normally be signed by DKIM, and would be
      vulnerable to inadvertent breakage by naive MTAs.





Gallagher, et al.       Expires 27 December 2025               [Page 13]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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 Field Name | Protocol | Reference     |
             +===================+==========+===============+
             | Sig               | MIME     | This document |
             +-------------------+----------+---------------+

              Table 1: Permanent Message Header Field Names

   Note that the Template, Status, and Trace columns are empty and
   therefore not included in the table.

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 27 December 2025               [Page 14]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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 27 December 2025               [Page 15]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [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>.







Gallagher, et al.       Expires 27 December 2025               [Page 16]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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, <https://www.rfc-editor.org/rfc/rfc1847>.

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 email, 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



Gallagher, et al.       Expires 27 December 2025               [Page 17]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   - delete it promptly.

   Thanks,
   Alice
   --913
   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 email, 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 27 December 2025               [Page 18]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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 email 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 27 December 2025               [Page 19]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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 27 December 2025               [Page 20]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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 email 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 27 December 2025               [Page 21]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 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.  Document History

   Note to RFC Editor: this section should be removed before
   publication.

B.1.  Changes Between draft-gallagher-email-unobtrusive-signatures-00
      and draft-gallagher-email-unobtrusive-signatures-01

   *  Made explicit that Sig MUST NOT appear in a non-leading position.

   *  Expanded design rationale section.




Gallagher, et al.       Expires 27 December 2025               [Page 22]

Internet-Draft   Unobtrusive End-to-End Email Signatures       June 2025


   *  Clarified use of Quoted-Printable encoding.

   *  Terminology and reference cleanup.

B.2.  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.

Acknowledgments

   The authors would like to thank the attendees of the 9th OpenPGP
   Email Summit for feedback and suggestions.  Additionally, Anarcat
   offered useful feedback on the draft.

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 27 December 2025               [Page 23]
