> The accounts and peers table in the autocrypt spec describe one way
> to get to the deterministic query of "what OpenPGP certificate should
> I use for this peer?" [...] Do you think your script's implementation
> would yield the same result for these queries, even without maintaining
> a table? That would be a very nice result.

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.

I am also not sure if it would be worth it to follow the autocrypt spec
to the letter. Delta Chat recently moved away from the autocrypt spec
to the extend that one could be tempted to argue that they broke their
autocrypt support. I know very little about how close other email clients
follow the letter of the autocrypt spec, but I think I once read that
Thunderbird does not use the encryption recommendation algorithm either.
I therefore view the current state as one where the format of autocrypt
headers is well supported; while for encryption recommendations,
every client does its own thing. I also don't think that following the
autocrypt spec more closely would provide any palpable benefits. In my
view, the security aspects of autocrypt boil down to something like:
"At least using this key won't be worse privacy than using no key at
all." And interoperability is mostly about what other clients do and
less about what the spec says (even if there may be cases where those
two aspects correlate).

> > This UI deliberately mirrors gpg, where you can run `gpg --locate-keys`
> > to retrieve keys from a WKD. [...]
> 
> I'm a long-time user of (and contributor to) GnuPG but i gotta say i
> would *not* try to deliberately mirror the UI of gpg.  it's kind of a
> mess.

I myself started only this year to actually use gpg -- I had previously
heard that it was hard and unpleasant -- and I was very surprised by
what I perceived to be a very straight-forward UX. Obviously, I am only
using a very small subset of gpg. Basically, the only thing I use it for
is importing and listing keys. First, I imported my secret key via what
is now available as

    notmuch autocrypt --import-secret-key

I then started importing other peoples' keys via one of

    gpg --locate-external-keys EMAIL...
    notmuch autocrypt --locate-keys EMAIL...
    curl URL | gpg --import
    cat FILE | gpg --import

Finally, I sometimes have a look at my two keyrings via

    gpg --list-secret-keys
    gpg --list-keys

Everything else (i.e. message encryption, signing, decryption, signature
verification) is already handled very well by notmuch and bower (the
notmuch frontend I use). I also entirely ignore the trust level of keys;
and my manual key handling is mostly a mix of TOFU and delegation of
trust to the CA certificate infrastructure of HTTPS requests. But at
least it works(tm) pretty well in practice.

> I've found notmuch's interface to be better organized -- it seems like
> it might be better to try to extend notmuch's interface to map to the
> queries supported by autocrypt, and then backfill from that to figure
> out whether we need to change the database at any infrastructural level.
> [...] This script also seems devoted to working with gpg. [...]

Yes, notmuch-autocrypt is entirely dependent on working with gpg. Since
gpg is already supported in both notmuch and bower, this was a natural
decision to make. I am not generally opposed to making notmuch-autocrypt
work with other kinds of OpenPGP tooling (e.g. sq), but as long as this
tooling is not supported by both notmuch and bower, I don't see much of a
point in supporting it in notmuch-autocrypt. I also think that it makes
sense to prioritize support for a single setup first, before thinking
about supporting additional backends.

> [...] it'd be cool if this tooling just extracted the Autocrypt
> recommendation (certificate plus default choice of encrypted), and
> the user could plug the relevant certificate and policy information
> into their own OpenPGP tooling.

One nice feature of the tight integration between notmuch-autocrypt and
gpg is that I can actually use autocrypt keys, even if bower and notmuch
are entirely unaware of autocrypt. Notmuch and bower only need to know
if a key can be found in the keyring, which they already do. The more
abstract the tooling becomes, the more changes are required to both
notmuch and its frontends to make use of this tooling. E.g. providing
a recommendation according to the autocrypt spec is only useful if the
frontend also uses this recommendation in some way. For reference, here
is a link to my own earlier efforts at implementing autocrypt for notmuch,
which also stalled before I could get them anywhere near a usable state:

    https://tilde.club/~seifferth/repos/notmuch-autocrypt-old/

> I think this is a great starting point.  I love the simplicity of it,
> but i also think the simplicity might be a bit risky (e.g.
> https://github.com/seifferth/notmuch-autocrypt/issues/1).

Yes, the security implications of using notmuch-autocrypt in its current
form are pretty daunting. I figured that this might be acceptable for a
rough prototype. But if notmuch-autocrypt sees any real use, we should
definitely add proper input validation -- which would require parsing the
OpenPGP certificate to confirm that it conforms to the subset specified
in the autocrypt spec; and that the OpenPGP certificate actually specifies
the same User ID we would expect from its context.

There are also some low hanging fruit in terms of making notmuch aware
of autocrypt headers. The following changes to libnotmuch, for instance,
could help make notmuch-autocrypt more feature complete:

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.

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.

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.
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org