-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 17-08-17 09:18 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote: >> I perceive keys in my keyring as being ones I trust because of >> out-of-band confirmation and used for two-way communications. > > You're not the only person with this perception. But i'm afraid i > think it's a mistake, unfortunately. > > Actually safely curating an OpenPGP keyring with GnuPG is a > non-trivial task. As an example, here's a damned-if-you-do, > damned-if-you-don't conundrum: > > -------- Do you refresh the OpenPGP certificates in the keyring > regularly (e.g. from the keyservers)? if you do not, then you risk > missing notice of revocations, so you probably have some revoked > keys in your keyring which you didn't know you had. > > If you do refresh them regularly, then it's possible that things > (new user IDs, etc) get added to the certificates in your keyring > during the refresh (or possibly whole new certificates get added > entirely), and it contains things you've never actually vetted. > -------- > > > So, how to resolve this? > > The short version is that you should treat your GnuPG keyring as > an untrusted collection of OpenPGP certificates that you know > about. But you can explicitly mark the certificates that you think > are legitimate by certifying them ("signing the keys"). In > particular, you can make non-exportable ("local") signatures over > the key+userid combinations that you have actually confirmed > out-of-band. > > Even better, if you do that with a key which you have marked with > "ultimate" ownertrust, then GnuPG will report a "validity" for > those user IDs you've signed that matches what you intended to do, > which is to curate a list of known-valid key+userid combinations. > > But treating the whole local keyring as a curated store is a > mistake. GnuPG doesn't work that way, and it doesn't expect to work > that way :( Sounds like a good approach but for someone who has more public keys stored than me. I only exchange encrypted email with a very, very small group of people and I am in regular voice communication with them. But I definitely see the merit in what you describe and believe that it is a cautious way of proceeding. I may even try working that way just to practice for the day when perhaps I consider it necessary to exchange encrypted mail with people I don't know well and don't talk with in person or on the telephone regularly. I guess using that approach I could import public keys from users on this list and then assign them various levels of trust, right down to no trust and not locally signed at all. > >> I think the VirtualBox key is just to give people assurance that >> they are downloading what they intended to download from the >> source they expected, in this case via apt or apt-get, etc. from >> an Oracle repo. > > If you fetch the key each time you download something that you want > to check against the key, how do you know it's the right key over > time? If it's "the right key" because it was fetched over a secure > channel from Oracle, why not just fetch the software over that > channel? > I suppose I chose to use apt or apt-get because it seems like a more convenient way to update things as opposed to getting it straight from Oracle. > The advantage of having a key stored locally is that you only have > to risk that network-fetch once; then you can make a local > certification over its sensible VirtualBox User ID, to mark it as > the expected key (If the User ID is *not* sensible, please complain > to VirtualBox!). Then all future updates can be verified against > the same key. > > Do you see how that's better than fetching the key each time? > Well, I see it potentially as less work but not less risk. I downloaded the key using wget and https. Then I check the validity of the key by comparing the fingerprint generated by GnuPG with what Oracle publishes on the VirtualBox site. Downloading the key once works if I implement your previous key/keyring management solution. Also, bear in mind, no software gets updated automatically on my system. I get notified of updates but when the update happens is up to me. >> I'm not exactly sure what a good suggestion would be. Would it >> be correct to say that going forward usability changes would >> probably be more likely to happen in the 2.1 branch? If so I >> guess I should upgrade to the 2.1 branch. > > If a major change is going to happen in GnuPG, it will be in the > 2.1 branch (or in 2.3 once 2.2 is released). the older branches of > GnuPG (1.4.x and 2.0.x) receive very few changes from upstream. > >> I can say that what I usually end up being challenged by is >> importing keys into my keyring and on being able to choose which >> UID I want to sign with. Maybe that just means I don't know the >> software well enough. > > You don't sign with a UID, you sign with a key. > >> The approach I took was "gpg2 --search u...@domain.com" and >> "gpg2 - --recv-keys key-fingerprint". Then I did a "gpg2 >> --edit-key key-fingerprint" to sign the key with my default UID. >> I thought I would get a menu to select options from when I used >> --edit-key but instead I was presented with the prompt "gpg>" and >> I had to type the sign command. It worked but I might have >> chosen to sign the key with a key from a different UID. > > Again, i'm not sure what you mean by "sign from a UID". can you be > more clear? You're signing your friend's key+uid, from (or "with") > your primary key. > What I mean is that I have 2 email addresses which each have a different private key. The key for du...@nofroth.com has is associated with private counterpart to the key you fetched. I have another email address with a different private key associated to it. >> Not sure if my method of importing to my keyring and signing the >> new public key was the usual or easiest method but it worked. > > Sounds reasonable to me, except that you had to use --recv-keys, > rather than just selecting the key to fetch from the --search > interface. > > here's a transcript of me fetching a key that appears to be yours > from the keyservers: > > 0 dkg@alice:~$ gpg --search du...@nofroth.com gpg: data source: > https://145.100.185.229:443 (1) Arlen Duane Whitty (Duane) > <du...@nofroth.com> 2048 bit RSA key E25FA6BF14571B64, created: > 2016-06-09 Keys 1-1 of 1 for "du...@nofroth.com". Enter number(s), > N)ext, or Q)uit > 1 gpg: key E25FA6BF14571B64: public key "Arlen > Duane Whitty (Duane) <du...@nofroth.com>" imported gpg: Total > number processed: 1 gpg: imported: 1 0 dkg@alice:~$ > > > Note that i just typed "1" at the prompt, and it pulled your key > in directly (no need for a subsequent --recv-keys invocation). > > Regards, > > --dkg > As always, thank you for illuminating the finer points of GnuPG. Best Regards, Duane - -- Duane Whitty du...@nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZlkVCAAoJEOJfpr8UVxtkr90H/0mbZePGIdLGjxJUcAxSK8Jz X8jblhmDaeQRrcubdE3jUdg4YSO2sL++oBATJt34i4NoThD7EA5t89CjOaARioW5 2dU6wQVkVcPoYG4n8cjAqJNtmbsAr8ZnYTNIDoQllbSuPE7zMyT7gqXKFv8HWID/ gfAFx1u8sIwqDDOw3q+hOtJa+/1P3VjgmnRY3Ern11zaWCBIdGes+GxV5Ptx/kOD rfjA8s3sFml2ttNBPydGHtd6Q8Kv1u0qbP9Hy3X/gH5kw644nJBNXxXRAq+NoSB4 iLfpY2U6bzAoLy9eA+j4pyQ/KNt/CNmh9nk6FoEtjLrq5HXNdYPiV9AKAW5fkbQ= =EiCQ -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users