Key discovery vision (was: Preserving non-central and privacy..)
Vincent Breitmoser
look at my.amazin.horse
Wed Jul 10 20:39:19 CEST 2019
> A key on a keyserver should never be searchable by user-id. It is not
> required and only an attractor to use the keyserver as free and
> searchable data storage. We only need lookups by fingerprint. Keys
> should in general be discovered by other reliable mail to key mapping
> services.
I agree with this, mostly.
Ideally, key discovery should always work in-band alongside regular e-mail
communications (-> Autocrypt), aided by a priori discovery from the target
domain (-> WKD). This latter method must be optional, because not everybody
wants to publish their email/pubkey binding. And for good reason: e2e spam is
only not an issue right now because it's too obscure.
However - for the time being, neither Autocrypt nor WKD are deployed widely
enough to actually fulfill this role. Thus, we do need some kind of
"wkd-lookaside" that just works™.
> If that is not possible there is always the fallback to first send a signed
> mail and the recipients tool can then lookup the key via the fingerprint
> (which is embedded in the signature) at a keyserver.
Attachments are userspace. No user wants to have "signature.asc" or
"publickey.asc" attachments on their email messages. It makes you look like
a nerd. If we want to have users who aren't comfortable with looking like
a nerd, we must stop trespassing on their message content.
This might sound extreme, because it means dropping or changing every mechanism
we have that relies on MIME thingies that accidentally look like attachments,
notably pgp/mime signatures and attached keys. I don't think it is. Users care
about stuff like this, and deferring the issue to user education does not scale.
- V
More information about the Gnupg-devel
mailing list