[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openpgp] comments on draft-mccain-keylist-02



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/openpgp