Expect Signed Mail

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 April 2024.¶

Copyright Notice

Copyright (c) 2023 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

E-mail signature validation is hard. When an e-mail signature is absent (or invalid), a reasonable mail user agent will hide their cryptographic authenticity security indicator for the message. But an absent security indicator is hard to notice.¶

Some e-mail users create end-to-end signatures of all of their e-mails. The peers of those users may want to display a more significant warning message when a signature is absent or invalid.¶

This draft proposes a mechanism whereby an e-mail author can indicate to a peer that they should expect all their future messages to be cryptographically signed.¶

2. Signalling Mechanism

A sender that intends to signal their intention to activate the Expected-Signed mechanism MUST add an "Expected-Signed" header to the outgoing email, specifying an expiration date in the value of the header.¶

The authenticity of the header MUST be validated. The header SHOULD be transmitted in the protected headers (see [I-D.ietf-lamps-header-protection-16]), and a recipient MUA SHOULD deem it valid if the signing key is already trusted. Alternatively, the recipient's MUA:¶

• SHOULD validate the DKIM headers [RFC6376] and SHOULD require them to be in the protected headers.¶
• SHOULD validate the SPF records [RFC7208] to verify it is coming from an authorized source and SHOULD require the message to be delivered over TLS before deeming it valid.¶

FIXME: Do we want to support them all?¶

A recipient MUA that receives a valid "Expected-Signed" header SHOULD safely store this information and its expiration date indexed per email address.¶

Expect-Signed = "Expect-Signed" ":"
                [ directive ]  *( ";" [ directive ] )

directive                 = directive-name [ "=" directive-value ]
directive-name            = token
directive-value           = token | quoted-string

expiry-name  = "expiry"
expiry-value = IMF-fixdate

Expect-Signed: expiry="Sun, 20 Oct 2019 14:19:20 GMT";

3. Validating Policy

All e-mails coming from addresses that are stored and valid as Expect-Signed MUST be validated. To validate a message's signature the recipient's client MUST follow OpenPGP's specification Section 5.2.4 of [RFC4880].¶

FIXME: This is not only OpenPGP. Should include a reference to PGP/MIME [RFC3156], S/MIME [RFC8551], and [I-D.ietf-lamps-e2e-mail-guidance-12].¶

The sender's key can be retrieved from any trusted storage or repository, and if none is found it SHOULD be indicated in the feedback. This mechanism will allow the sender to automatically reply with their key.¶

4. On Policy Violation

In the scenario where a sender has enabled the Expect-Signature it is expected that all the outgoing messages are provided with a a valid signature, and both the sender and recipient should be notified when a signature is missing or invalid.¶

An MSA, MTA, or MUA SHOULD NOT prevent a message from being received due to a missing signature. The MUA MUST warn the user if an expected signature is missing or invalid, and SHOULD provide feedback as specified in the following sections.¶

"Expect-Signed-Failure" ":" failure-reason CRLF

failure-reason =  (   "no-signature"
                    / "signature-invalid"
                    / "signature-not-verified"
                    / "signature-expired"
                  )

5. Common UX for Absent and Invalid Signatures

FIXME: explain why receiving MUAs should display the same thing when a signature is missing as when it is absent.¶

6. Related Work

This draft is inspired by (and similar to) HSTS, MTA-STS, TLSRPT, etc.¶

FIXME: include references¶

7. IANA Considerations

IANA might need to register the e-mail headers Expect-Signed and Expect-Signed-Failure.¶

Appendix A. Acknowledgements

FIXME¶

Appendix B. Mapping the Solution Space

[ RFC Editor: please remove this section before publication ]¶

The range of possible solutions in this problem space is potentially quite wide.¶

The draft attempts to make some decisions, but they can be revisted. This appendix tries to document some distinct axes along which the problem can be resolved.¶

The completed draft should provide a clear choice along each axis, or a mechanism for some active participant in the protocol to select a choice.¶

Appendix C. Document Considerations

[ RFC Editor: please remove this section before publication ]¶

Authors' Addresses