Hello,
Excellent points and I'm glad that the draft has been published on this
ML for a discussion in a wider audience.
As far as I understood draft-mccain-keylist-02 its goals can already be
achieved with a combination of already existing features:
1. Discovering keys for company employees - using "e-mail to key" lookup
(e.g. WKD)
2. Trusting that these keys are authentic - by signing an Authority Key
and setting ownertrust to full. This can be done only once and it works
for all future keys. Even with draft-mccain-keylist-02 one needs to do
that to know which keys are trusted. There is one variation of this
scheme - by using Trust Signatures one can trust Authority Key to keys
from the company domain only.
3. Keeping keys up to date - why not just refresh all keys in the local
keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will
refresh expired keys over WKD if they were fetched with WKD [0]).
[0]: https://dev.gnupg.org/T2917
If the problem is that people verify signatures and the keys are not
present I think applications have appropriate options to fetch keys
automatically (e.g. `gpg --auto-key-retrieve`).
I like the point of using .well-known for a keyring of all people but
from what I've heard on GitHub the ability to host keylist on a
different domain is desired:
There's no reason to trust the server that hosts the keylist file. We already
don't trust it -- FLM hosts our keylist on GitHub.
Source:
https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-426846582
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp