fingerprint of key

[Duane Whitty]

-----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 user at 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 duane at 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 at alice:~$ gpg --search duane at nofroth.com gpg: data source:
> https://145.100.185.229:443 (1)	Arlen Duane Whitty (Duane)
> <duane at nofroth.com> 2048 bit RSA key E25FA6BF14571B64, created:
> 2016-06-09 Keys 1-1 of 1 for "duane at nofroth.com".  Enter number(s),
> N)ext, or Q)uit > 1 gpg: key E25FA6BF14571B64: public key "Arlen
> Duane Whitty (Duane) <duane at nofroth.com>" imported gpg: Total
> number processed: 1 gpg:               imported: 1 0 dkg at 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
duane at 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-----