> > 1. If `notmuch new` would add `tag:autocrypt` to messages that contain
> > an autocrypt header, I could a) use this tag to make the query for
> > `notmuch autocrypt --locate-keys` more efficient and b) I could easily
> > notice that a peer is using autocrypt even if my notmuch frontend knows
> > nothing of autocrypt semantics.
> 
> This ought to be a fairly straightforward and achievable task.  The only
> issue is that it might need to trigger a re-indexing (if someone wants
> to evaluate their old mailstore).  But you could also just start
> indexing new messages and be OK with the fact that you'll only start
> identifying Autocrypt messages going forward.  That's still "probably
> better than not doing it".
> 
> Want to try to produce such a patch for notmuch?  I'd be happy to
> collaborate on it.
> 
> > 2. If `notmuch show` could be used to dump the effective header of an
> > encrypted message (e.g. inlining protected headers), notmuch-autocrypt
> > would not need to do this kind of message parsing itself.
> 
> I like this as well -- what if it produced the per-message output when
> --format is sexp or json?  we could have a simple "autocrypt" label that
> contains keydata and prefer-encrypt.  Doing this fix here would also
> mean that we could include Autocrypt headers from inside the
> cryptographic envelope, on an encrypted message.
> 
> I'd also be happy to collaborate on this.
> 
> > 3. If notmuch was aware of Autocrypt-Gossip headers, notmuch-autocrypt
> > could potentially use the key gossip extension to autocrypt to
> > find even more autocrypt keys. The problem with "Autocrypt-Gossip"
> > headers is that they can appear in any message (whereas "Autocrypt"
> > headers for peer@example.net should only appear in messages
> > `from:peer@example.net`). If I could query notmuch with something like:
> >
> >     notmuch search property:autocrypt-gossip=peer@example.net
> >
> > this would allow notmuch-autocrypt to efficiently locate such headers.
> 
> I like this one too, but i think it maybe we can tackle it once the
> other two pieces are complete.

That sounds great. I hope I can make some time to try and work on these
issues rather sooner than later. I think requiring `notmuch reindex` to
catch old messages would be quite reasonable.

> The Autocrypt spec itself proposes that it is a "recommendation"
> (not mandatory) [0], and has guidance about diverging from it.
> 
> [0] https://docs.autocrypt.org/level1.html#provide-a-recommendation-for-message-encryption

I suppose there's no harm in making this recommendation available. Maybe
we should add it to the list above as a low-ish priority item 4.

> [...] Then i suppose we also need to be able to reason about what
> other inputs might be modifying this shared state, and how (or whether)
> we update the state if we receive new certificates from a given peer.

This is a kind of complexity that I did not even try to tackle ;) I kind
of like the fact that `notmuch-autocrypt` allows me to treat autocrypt
headers as one of multiple available key distribution mechanisms. Which
then allows me to manually use heuristics like: Check if I already have
a key in my keyring; otherwise try to use WKD; otherwise try to use
autocrypt; if I feel like it, maybe look up the key on some website;
otherwise send an email without end-to-end encryption.

For simplicity, we might want to restrict `notmuch-autocrypt` to answering
active queries like

* Give me the current autocrypt key for PEER
* Give me the encryption recommendation for LIST OF PEERS

while consciously rejecting any notion of proactively updating any state.
As long as `notmuch-autocrypt` is reasonably performant (which it should
be), it would still be feasible to simply invoke

    notmuch autocrypt --locate-keys PEER

every time we want to send a message to PEER -- and in case that kind of
behaviour fits well into the UI used by the notmuch frontend in question.

> We also need to be able to identify that newer messages *without* an
> Autocrypt header have come in from the same sender, so that a peer can
> safely turn Autocrypt off.

I believe this issue is only relevant for computing the encryption
recommendation. That being said, it should be quite easy to locate both
the last message received from PEER and the last message from PEER that
also contains an autocrypt header and to check if these messages' dates
are more than 35 days apart (Autocrypt Spec 1.1.0, sec. 3.4.2).

> > I believe that in theory it should be possible to model the behaviour
> > described in the autocrypt spec as a notmuch query. However, at the very
> > least, this would require the "first seen" date to be made available in
> > the notmuch query syntax.
> 
> Hm, does notmuch even store that information about each Message-ID or file?

I have to confess that I know nothing about notmuch internals (yet),
but I would suppose that it does not. Another question would be what
"first seen" even means in a setup where separate programs are used
for message delivery and indexing. Maybe we should approximate "first
seen" using the file creation timestamp? Or maybe the last modified
timestamp? Note that Delta Chat also seems to have issues with message
re-delivery[1], so in practice the "first seen" timestamp might not be
as static as one could expect when only reading the spec.

[1] https://github.com/chatmail/core/issues/7170

Anyway, I suggest that solving the question of message timestamp handling
should also be a low priority issue compared to the issues described
above. For starters, using the message date used by notmuch seems good
enough for me (even if this might introduce some nasty edge cases that
could potentially be abused by malicious actors, as you mention).

> My understanding is that Deltachat is moving away from the e-mail
> address as the primary identifier for a peer contacts [...]

It's complicated. See e.g. https://support.delta.chat/t/4010. But yes,
they are starting to use key fingerprints as identifiers. If we wanted
to bring this concept to notmuch, we could also introduce something like:

    notmuch search signed-by:B280419AA8EE19B8645C8FDECAC590E4BF6815AE

and

    notmuch search encrypted-for:B280419AA8EE19B8645C8FDECAC590E4BF6815AE

which is obviously not particularly human readable.

> But if we're talking about a subcommand named "notmuch autocrypt" it'd
> be nice to make sure that at least that subcommand identifies the the
> Autocrypt recommendation, even if some other part of a notmuch-based MUA
> decides to vary from it.
> 
> Alternatively, we could choose to name it something else :)

One could indeed argue that the `notmuch-autocrypt` prototype I wrote is
actually more about gpg than it is about notmuch or even autocrypt. I do
care a lot about having nice UI porcelain for the interaction between
notmuch and gpg. That being said, once `notmuch-autocrypt` becomes
sufficiently complex, it might be an option to split the script into a
generic backend and a gpg-specific frontend. On the other hand, if we
pursue the thoughts outlined above, we might discover that a few minor
tweaks to `notmuch new`, `notmuch show`, and the like are already enough
to turn all autocrypt functionality into one-liners; which could be easily
duplicated across frontends. In this latter case, `notmuch-autocrypt`
might very well turn into a collection of notmuch-specific autocrypt
frontends for various OpenPGP backends (e.g. gpg, sq, ...).
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org