Internet-Draft Invisible End-to-End E-mail Signatures May 2025
Gallagher, et al. Expires 3 November 2025 [Page]
Workgroup:
none
Internet-Draft:
draft-gallagher-email-invisible-signatures-00
Updates:
3156 (if approved)
Published:
Intended Status:
Informational
Expires:
Authors:
A. Gallagher, Ed.
PGPKeys.EU
D. K. Gillmor
ACLU
K. Engert
Thunderbird

Invisible End-to-End E-mail Signatures

Abstract

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

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://andrewgdotcom.gitlab.io/invisible-signatures/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-gallagher-email-invisible-signatures/.

Source for this draft and an issue tracker can be found at https://gitlab.com/andrewgdotcom/invisible-signatures/.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 November 2025.

▲

Table of Contents

1. Introduction

Several different standard structures for end-to-end cryptographically signed e-mail exist (see Sections 4.1.1.1, 4.1.1.2 and 4.1.2.1 of [I-D.ietf-lamps-e2e-mail-guidance]). But the existing mechanisms have some undesirable properties which can make such mail difficult for the recipient to handle in some instances, particularly when read by legacy e-mail clients that don't understand the signing structure. This document offers another signed e-mail structure, which is designed to be invisible to legacy e-mail clients.

The goal of this mechanism is to help e-mail clients commit to signing every outbound message, which reduces complexity for the user of the mail client. The mechanism is capable of working with any signature mechanism, as well as transporting multiple signatures over a single message. It is specified initially for [OpenPGP], but can be easily extended to be used with [CMS] or other signature formats.

This mechanism is intended only for signed-only messages. A message that is encrypted-and-signed MUST NOT use this mechanism, since any existing MUA that can decrypt an encrypted-and-signed message already handles the signatures on such a message correctly.

This document updates [RFC3156] by providing an additional mechanism for producing and consuming OpenPGP-signed MIME e-mail.

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.

3. Problems With Existing Signature Schemes

Existing end-to-end signature schemes for mail can trigger a set of annoyances for a recipient who uses a MUA that doesn't understand these structures. These annoyances can cause the recipient to complain to the sender. The easiest way for the sender to try to accommodate the recipient in this case is to simply not sign mail.

The Invisible Signature scheme defined in this document is intended to minimize or eliminate all of these problems.

3.1. Unreadable Signed Mail

A signed mail message that uses the S/MIME PKCS #7 signed-data Cryptographic Layer described in Section 4.1.1.2 of [I-D.ietf-lamps-e2e-mail-guidance] is unreadable by a receiving MUA that doesn't understand [CMS].

By contrast, a mail message signed with an Invisible Signature should render normally by any legacy MUA.

3.2. Unknown Attachment

A signed mail message that uses the S/MIME Multipart Signed Cryptographic Layer described in Section 4.1.1.1 of [I-D.ietf-lamps-e2e-mail-guidance] or the PGP/MIME Signing Cryptographic Layer (multipart/signed) described in Section 4.1.2.1 of [I-D.ietf-lamps-e2e-mail-guidance] has a separate MIME part that contains the message signature.

A receiving MUA that doesn't understand these structures will often render the signature as an "attachment". This can cause confusion and anxiety to the user of the MUA, and they will sometimes respond to the sender with the complaint "I can't open your attachment".

By contrast, a mail message signed with an Invisible Signature is merely encapsulated in a multipart/mixed outer layer. Legacy MUAs do not render such an encapsulation as an attachment.

3.3. Broken Signature

In some cases, mail is tampered with in transit, whether deliberately or maliciously. In this case, for a MUA that does understand these messages, some MUAs will visibly complain to the recipient that there is a failed signature.

If unsigned mail receives no comparable warning, then the act of adding a signature to a message that might traverse a modifiable path is risky. An MUA compliant with Section 6.4 of [I-D.ietf-lamps-e2e-mail-guidance] will not create such a warning, but many MUAs do not yet comply with that guidance.

By contrast, a legacy MUA won't render anything about the cryptographic status of an Invisibly Signed message at all. And an MUA compatible with this specification that encounters a message with a broken Invisible Signtature will never render an error that it wouldn't have rendered on an unsigned message anyway, which removes this disincentive to sign.

4. Invisibly Signed Message

An Invisibly Signed Message has a specific MIME structure and uses a specific header field.

4.1. MIME structure

The top-level Content-Type of an invisibly signed message is multipart/mixed, and it has a single MIME subpart, which this specification refers to as the "Protected Part". The Protected Part's header sections' first header field is Sig, described in Section 4.2.

We hereby specify a third PGP/MIME format in addition to the two listed in Section 4.1.2 of [I-D.ietf-lamps-e2e-mail-guidance]:

4.1.1. PGP/MIME Invisible Signing Cryptographic Layer (multipart/mixed) 

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

This MIME layer offers authenticity and integrity IFF the Protected Part contains one or more valid Sig: headers.

This format is a Simple Cryptographic Envelope as specified in Section 4.4.1 of [I-D.ietf-lamps-e2e-mail-guidance], and the Protected Part (with leading Sig Header Fields removed) is the Cryptographic Payload.

This MIME structure MUST NOT be used as part of a Multilayer Cryptographic Envelope. If it is found anywhere but the outside of the message it MUST NOT be treated as a Cryptographic Layer.

4.2. Sig Header Field

This specification defines a new header field, named Sig. Sig is only meaningful if it appears in the Protected Part of an Invisibly Signed Message, before any non-Sig header field.

It contains parameters, only two of which are currently defined.

  • The t parameter indicates the type of the signature with its value, and the only value currently defined is p, meaning an OpenPGP signature. See Section 10.3.

  • The b parameter contains a base64-encoded blob that contains the cryptographic signature object of the type described by t.

4.3. Message Normalization

The Protected Part, without any Sig header fields, MUST be canonicalized to a bytestring in order to create or verify the signature. This is done following the patterns described in Section 3 of [RFC3156].

  • Line endings converted to CRLF

  • Content-Encoding is used to make the message 7-bit clean

  • End of line trailing whitespace is stripped or encoded to non-whitespace

  • If "From " starts a line, at least one letter of it should be encoded

This is all done for two reasons:

  • to make the message unlikely to be modified by existing MTAs, and

  • to make the signature invariant no matter whether the OpenPGP signature is text-mode or binary-mode.

FIXME: is all this really necessary in 2025? What if we said that an Invisibly Signed Message that needs 8BITMIME simply can't be transmitted across an MTA that doesn't support 8BITMIME? Or what if we decided that it's OK if the signature breaks in that case?

4.4. OpenPGP Signature Details

The OpenPGP Signature is made over the canonical bytestring, in binary mode (OpenPGP Signature Type 0x00).

Note that if multiple Sig header fields appear in a single message, each Sig header field represents a signature over the Protected Part without any Sig header field. That is, each Sig signs the same content, and the order of the Sig header fields among themselves doesn't matter as long as every Sig header field precedes all non-Sig header fields in the Header Section of the Protected Part.

5. Sender Guidance

5.1. Always Use Header Protection

A message signed with an invisible signature MUST always use [I-D.ietf-lamps-header-protection], signing every header field known to the sending MUA at message composition time.

5.2. Message Composition

This updates the message composition function found in Section 5.1 of [I-D.ietf-lamps-e2e-mail-guidance], using the same parameters.

  • origbody: the traditional unprotected message body as a well-formed MIME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, origbody already has structural header fields present.

  • origheaders: the intended non-structural header fields for the message, represented here as a list of (h,v) pairs, where h is a header field name and v is the associated value.

  • crypto: an indication that the message is to be signed with one or more Invisible Signatures. This contains a list of one or more secret keys. Each key will make one signature.

The algorithm returns a MIME object that is ready to be injected into the mail system:

  1. Create MIME tree inner as a copy of origbody

  2. Ensure Content-Type Header Field of inner has parameter hp set to "clear".

  3. For each header name and value (h,v) in origheaders:

    1. Add header h to inner with value v

  4. Normalize inner to bytestring innerbytes (see Section 4.3)

  5. For each signing key key in crypto:

    1. Sign innerbytes with key, yielding signature sig

    2. Prepend a Header Field named Sig to inner with two parameters, t (set to the literal string p) and b (set to the base64-encoded value of sig).

  6. Create new MIME tree output with Content-Type multipart/mixed, with a single subpart, set to inner

  7. For each header name and value (h,v) in origheaders:

    1. Add header h to outer with value v

  8. Return output

5.3. Do Not Use Invisible Signature When Encrypting

In accordance with Section 5.2 of [I-D.ietf-lamps-e2e-mail-guidance], when sending end-to-end encrypted messages an MUA MUST place end-to-end signatures inside the encrypted data. This mechanism is therefore not applicable to encrypted messages.

6. Recipient Guidance

6.1. Detecting an Invisible Signature

A receiving MUA detects the presence of an invisible signature on a message by verifying that:

  • the message Content-Type is multipart/mixed, and

  • there is exactly one top-level subpart (though that subpart itself may be multipart), and

  • the Content-Type of that top-level subpart has parameter hp="clear", and

  • the first header field of the top-level subpart is named Sig, and

  • the top-level subpart has a From header field, and its addr-spec matches the addr-spec in the message's From header field.

This last requirement (matching From addr-specs) is an anti-spoofing measure, by analogy with Section 4.4 of [I-D.ietf-lamps-header-protection].

6.2. Validating an Invisible Signature

When validating an invisible signature, the signature data (i.e. the value of the b field) is converted from Base64 to binary format to recover the signature packet. The signed object is extracted from the multipart/mixed part by selecting every octet that comes after the CRLF that terminates the last Sig header, and before the CRLF that immediately precedes the trailing MIME boundary. The signed object is then normalized as described in Section 4.3. The normalized data is then passed to the signature verification routine as a raw bytestream.

6.3. Message Rendering and the Cryptographic Summary

If the message has at least one Invisible Signature which validates, then the MUA SHOULD render the message as though the top-level subpart is the message itself. The Cryptographic Summary of the message SHOULD indicate that the message is signed-only, and that all header fields present in the top-level subpart share that Cryptographic Status.

6.3.1. Example Rendering

For example, consider a message with this structure:

A └┬╴multipart/mixed
B  └┬╴multipart/alternative; hp="clear" [Cryptographic Payload]
C   ├─╴text/plain
D   └─╴text/html

If at least one Invisible Signature is present as a leading Sig header field in B, and it validates correctly, the message should be rendered the same way as this message:

B └┬╴multipart/alternative
C  ├─╴text/plain
D  └─╴text/html

And its Cryptographic Status will be signed-only.

6.3.2. Unprotected Header Fields Added In Transit

As noted in Section 7 of [I-D.ietf-lamps-header-protection], it's possible that a MUA encounters some Header Fields on the outer message (in the Header Section of A in the example above) which could not have been known by the sender.

If any such fields would normally be rendered in some fashion by the MUA on an unsigned message, it MAY consider rendering them even on a signed-only Invisibly Signed message, but it should take care to indicate that they do not share the signed-only Cryptographic Status with the rest of the message.

6.4. Signature Failure Handling

Sometimes a receiving MUA encounters an invisibly signed message where all invisible signatures fail to validate. The receiving MUA MUST NOT present the user with a cryptographic status that is different from a message with no signature at all. That is, the message's Cryptographic Status SHOULD be unprotected.

If a message gets tampered with in such a way that all invisible signatures are broken, the recipient should see the message as though it were a normal unsigned message.

6.5. Handling Multiple Signatures

If more than one invisible signature is present in a message, the receiving MUA MUST verify each signature against the known certificates associated with the indicated sender. As long as one of the signatures validates, the message should be treated as correctly signed, even if all the other signatures are invalid.

6.6. Ignore Out-of-place Invisible Signatures

An invisible signature Sig header field MUST NOT be evaluated unless it is within the MIME headers of the only subpart of a multipart/mixed message.

Evaluating a Sig header outside of this location might mean that a modified message could still appear to be successfully verified. For example, an invisibly signed message might be included as a sub-part of another multipart message, or be transformed into a non-MIME message with different message headers than the original email. This could conceivably be used by an attacker to make subtle changes to the meaning of a message without altering the content of the Protected Part.

7. MTA Guidance

An MTA or any other message relay service that observes a message with Content-Type multipart/mixed that is a single part MUST NOT alter the content of this message body in any way, including, but not limited to, changing the content transfer encoding of the body part or any of its encapsulated body parts. This corresponds to the guidance in Section 2.1 of [RFC1847] about the first section of multipart/signed messages.

8. Security Considerations

Based on the principle that "a broken signature is the same as no signature", a receiving MUA MUST NOT display any warnings if an Invisible Signature fails to verify, unless the user has requested debugging output. This is because if an MITM can modify a message in transit, then they can choose whether or not to also remove the (now invalid) signature. If the receiving MUA displayed a more severe warning for a broken signature than for a missing one (or vice versa), the MITM could choose to modify the message in such a way that would result in the less-severe warning. The warning message is thus attacker-controlled.

Otherwise, the security properties are equivalent to those of a multipart/signed message.

9. Performance Considerations

9.1. Rationale for Signature in MIME Part

  • An MTA is more likely to modify, reorder, or enforce limits on header fields associated with the entire message than it is to corrupt header fields in the subpart.

  • Any DKIM signature that includes the body of the message will cover the end-to-end signature. If the end-to-end signature was in the outer message it would not normally be signed by DKIM, and would be vulnerable to inadvertent breakage by naive MTAs.

9.2. No One-pass Message Generation

Because the signature is included first in the message, it is not possible to generate the message in a single pass.

A sending MUA that needs to generate a signed outbound message in a single pass should use another end-to-end signing mechanism, like multipart/signed.

10. IANA Considerations

10.1. Register the Sig Header Field

IANA is requested to update the Permanent Message Header Field Names registry to add the following entry:

Table 1: Permanent Message Header Field Names
Header Field Name Template Protocol Status Trace Reference
Sig   MIME     This document

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:

Table 2: Sig Message Header Parameters
Name Description Reference
t Type of Signature (see Section 10.3) 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? ))

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:

Table 3: Sig Message Header Signature Types
Value Description Reference
p A single OpenPGP Signature packet This document

10.4. Update multipart/mixed to Refer Here

IANA is requested to update the "multipart/mixed" entry in the Media Types registry, to add a reference to this document.

11. References

11.1. Normative References

[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, , <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, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-25>.
[OpenPGP]
Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc3156>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <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, , <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, , <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-02, , <https://datatracker.ietf.org/doc/html/draft-bre-openpgp-samples-02>.
[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, , <https://www.rfc-editor.org/rfc/rfc1847>.

Appendix A. Test Vectors

These test vectors show different examples of invisible signed messages.

A.1. From Alice to Bob

The message below is a common multipart/alternative e-mail, signed with an invisible signature. The signature should be verifiable using the "Alice" certificate found in Section 2.1 of [I-D.bre-openpgp-samples].

Content-Type: multipart/mixed; boundary="89d"
MIME-Version: 1.0
From: Alice Lovelace <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: <invisig-0@openpgp.example>

--89d
Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBQq
 7wAKCRDyMVUMT0fjjixaAQCKo/ILDinzplUkebnERgKApWHoytKnP7rITQl
 WT0JNIwEAs7phDDVb1a/Dhy5lHJg2mU4Bu6HH8/VHnU9fqp1sywo=
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: <invisig-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
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--

--89d--

A.2. From David to Alice

The message below is a simple text/plain e-mail, signed with an invisible signature. The signature should be verifiable using the "David" certificate found in Section 5.1 of [I-D.bre-openpgp-samples].

Content-Type: multipart/mixed; boundary="593"
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: <invisig-1@openpgp.example>

--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 <david@openpgp.example>
To: Alice Lovelace <alice@openpgp.example>
Subject: Checking in
Date: Fri, 02 May 2025 13:01:07 -0400
Message-ID: <invisig-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

--593--

A.3. From Alice to David

The message below is a multipart/alternative e-mail with an image attached, signed with an invisible signature. The signature should be verifiable using the "Alice" certificate found in Section 2.1 of [I-D.bre-openpgp-samples].

Content-Type: multipart/mixed; boundary="cf0"
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: <invisig-2@openpgp.example>
In-Reply-To: <invisig-1@openpgp.example>
References: <invisig-1@openpgp.example>

--cf0
Sig: t=p; b=wnUEABYKAB0WIQTrhbtfozp14V6UTmPyMVUMT0fjjgUCaBUz
 JwAKCRDyMVUMT0fjjlavAP9Id9p5b5H17IBKVqaYq2NSwb4Er+/IWq19MnY
 AKhOlwgEAva0huFRnH4FNQpDG58E6l4o05BlzIa2Y+BTXGLqX/QI=
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: <invisig-2@openpgp.example>
In-Reply-To: <invisig-1@openpgp.example>
References: <invisig-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
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--

--cf0--

Appendix B. Acknowledgments

The authors would like to thank the attendees of the 9th OpenPGP Email Summit for feedback and suggestions.

Authors' Addresses

Andrew Gallagher (editor)
PGPKeys.EU
Daniel Kahn Gillmor
ACLU
Kai Engert
Thunderbird