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

[Wiktor Kwapisiewicz <[e-mail]>]

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