autocrypt/protected-headers

Protected headers for cryptographically-secure e-mail

Autocrypt -- E-Mail Encryption for Everyone

This is the source repository from which the https://autocrypt.org website and Autocrypt specifications are generated.

The Autocrypt Level 1 spec was created in 2019 and subsequently implemented in various MUAs and enjoys wide active use.

The following was agreed during the OpenPGP Summit in June 2024 by rough consensus:

• For 2024/2025 multiple parties in the OpenPGP space are interested to evolve the Autocrypt spec towards a Level 2 version.
• We close all historic issues and PRs (they remain accessible in the search).
• We implement a strict new issue/PR-creation policy (see below).

Strict Issue/PR creation policy

As of June 2024, there is only a loose set of people paying attention and caring for the Autocrypt repository. Therefore, this respository does not invite feature suggestions or bug reports and roughly has the following issue and PR creation policy:

Both Issues and PRs should typically only be opened if two parties agree on it before-hand and assign themselves which indicates they are committing to caring for resolving/merging.

You are however always warmly welcome to submit PRs to update the website, documentation and development-status pages, as well as the continous-integration machinery.

Working on a checkout of the autocrypt spec/pages

If you want to read and work on the docs locally checkout the doc directory which contains a sphinx documentation project. You can install sphinx and then run make html in the doc directory to regenerate docs locally.

Implementation development repositories

For implementation development repos, see https://autocrypt.org/dev-status.html

Copyright 2016-2024, the Autocrypt team, CC0 license.

protected-headers's Issues

Address how `...` appears to speakers of non-alphabetic, non-occidental languages

@juga0 points out in #14 that we don't actualy know whether an ellipsis really language-agnostic. What about non-western languages? what about non-alphabetic languages?

My suspicion is that if users of those languages are using e-mail they are at least exposed to US ASCII at some level, but i have no data to back that up. and i also don't know anything about the cultural implications of the ellipsis (outside of western writing), broadly speaking.

Document structure is still confusing

The structure of the document is still a bit confusing.

We have Message Composition and Message Interpretation, which both sandwich the Legacy Display part, which itself includes both composition and interpretation instructions.

It'd be nice for a future revision of the draft to have a clearer organizing principle.

text/plain legacy display parts should not be RFC 2047-encoded

The draft probably needs some explanatory text about how to craft a decent-looking legacy display part. for example, it doesn't need to be RFC 2047-encoded, etc.

dealing with headers that affect how a message is replied to or bounced

there are non-user-facing headers that are actionable during reply (e.g. that shift the behavior of the MUA somehow), like Reply-To and Mail-Followup-To. (and maybe Sender and Return-Path) ?

I worry that if we don't call these out specifically, then we are vulnerable to (at least) recipient-modification attacks.

I'm not sure how to characterize or exhaustively enumerate all such headers, or where in the spec such a mention belongs. The concept is subtly different from user-facing headers.

cover S/MIME as well as PGP/MIME

Speaking with Alexey Melnikov at IETF 106, he says that he thinks this approach should be fine with S/MIME.

At the LAMPS WG session there was agreement that we wanted:

• Test vectors of messages (including S/MIME):
• Screenshots of how these messages render in multiple clients

So the next revision of this draft should try to at least include the S/MIME examples.

define "transit-oriented" header

in #14, @juga0 points out that "transit-oriented" header isn't well-defined. should we add such a definition?

fwiw, i have only a fuzzy definition of this idea myself, and was originally using the idea in only a vague/intuitive sense, hoping that it was only used in an advisory sense, not in an explicit or normative sense. That is, it would be really bad if an undefined term was used to direct implementers to make specific choices. But if it's used mainly for flavor/intuition/insight, maybe it's ok to leave it undefined?

Dead draft?

I'm guessing by the age of last modifications of this repository that this draft has died?

I'm assuming one of the goals of this proposal was to be able to protect the Autocrypt: header from tampering (i.e. MitM attack). Is that correct?

Is there some subsequent work meant to replace this dead draft in achieving the above goal (among others)?

Does the sender need to identify the cryptographic payload as containing protected headers?

We still have this FIXME:

• FIXME: Enigmail adds protected-headers="v1" parameter to the Content-Type: of the Cryptographic Payload. Is this necessary?

My question is: do we need this? If its presence would be actionable in some way, then yes, i think we need it.

If it is not actionable, then i don't see what we gain from it.

Until today, i didn't understand any actionable behavior from it. But reading @BjarniRunar 's "Reverse-Copying" explanation, i realized that maybe it could be used as a clear signal to a receiving MUA that it should drop missing Exposed Headers.

Consider content-type for legacy-display part

given that:

• the purpose of the legacy display part is purely decorative, and
• the legacy display part will never be rendered by any non-legacy client, and
• more legacy clients are likely to actually render a text/plain part instead of a text/rfc822-headers part,

should we consider changing the legacy display part to use Content-Type: text/plain?

Also, if protected-headers="v1" is used to identify a cryptographic payload as containing protected headers (see #21), does it make sense to use the same parameter to identify the legacy display part? Shouldn't it be something like legacy-display="v1" or protected-headers="legacy-display" ?

Part of my reluctance to make either change is that some messages containing legacy display parts as described in the current document already exist. Do we want to discourage clients from dealing with them well by specifying only a new way to identify legacy display parts going forward?

We could specify for generating clients to generate the new form, and for receiving clients to handle both forms, but that sort of defeats the cleanliness rationale for having the "right" kind of markings.

On the other hand, if the only cost is that some encrypted messages from a couple of years render a little bit uglier than they used to, but we get cleaner signalling going forward, that might be a nice win.

On the third hand, legacy display is (hopefully) only useful for a limited time as it is transitioned away. So perhaps doing this cleanup would be more pain than benefit.

document "MIME leaf part" and "MIME tree" and "MIME part" and "MIME subtree"

terms about MIME structure are thrown around in the document without explicit definitions. maybe add to the Terminology section?

For example, "MIME leaf part" and "MIME tree" and "MIME part" and "MIME subtree"