Hi Micah,
Thanks a lot for the explanation. I was about to ask you these questions
previously on keylist ML but it never happened...
I'll skip parts that I don't have any comments for.
On 13.02.2019 21:31, Micah Lee wrote:
It's true that we could bootstrap a system like `gpg --refresh-keys`
combined with cron (or more realistically launchd on macOS) to keep keys
up-to-date. But 1) Not all OpenPGP users use gpg and cron,
I think one of the strengths of GpgSync, as an application, is that it
does the key refresh in the background, has a nice, simple UI and is
cross platform. I wouldn't definitely advise setting up crons but rather
having GpgSync do something like that (maybe not exactly invoking `gpg
--refresh-sync` but see my next point).
and 2) we
don't necessarily want to update all keys in every user's keychain, only
the keys on the keylists they're subscribed to. Only refreshing keys
listed on a keylist leaks less information to key servers than
refreshing all keys -- it leaks what keylists you're subscribed to.
Parcimonie [0] addresses that problem by using fresh Tor circuit for
each key.
[0]: https://github.com/EtiennePerot/parcimonie.sh#parcimoniesh
Not refreshing all keys may leave some other keys (for example people
that the journalist communicate with) stale. I don't have a problem with
that but I think it'd be good be aware of this.
But, most importantly, and in fact the reason we developed GPG Sync to
begin with (which ultimately lead to writing this draft RFC), what isn't
possible with existing tools is to get everyone in an organization to
automatically fetch*new* keys that they otherwise wouldn't be aware of.
Yes, but WKD keys are downloaded on demand when they are needed, e.g.
when you type a new message, or verify an unknown signature. Unless you
want to have the keys locally because someone is encrypting the file
while being offline and only later sends it out, then keys locally are a
nice thing to have.
For example, lets say we hire a new intern, and they generate a PGP key
for their mit.edu email address. How do we get hundreds of people's
computers to automatically fetch that key so they can email this intern
without having to do manually fetch it and verify it first?
As I said, the key could be fetched on demand. As for authorization it
already happens via Authority Key (that is lsigned by each user) signing
other users keys and that doesn't change regardless of how the key got
into local keyring in the first place.
Or, let's
say an employee loses their Yubikey, so they publish their revocation
certificate and generate a new key. How do we get those hundreds of
computers to fetch the revoked key, as well as the new key, so that the
next time someone sends an encrypted email to that person, it just works?
You can deliver both keys, revoked and new, also over WKD (see [1]).
That'll revoke the old key and make the new one active.
[1]: https://lists.gnupg.org/pipermail/gnupg-users/2019-January/061439.html
Of course, getting correct keys for unsupported or not controlled
domains (mit.edu/gmail.com) is a problem that having an official,
organization keylist solves quite nicely. I think emphasizing this in
the keylist abstract may be a good idea.
Thank you for your time!
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp