fingerprint of key

[Daniel Kahn Gillmor]

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 :(

> 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?

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?

> 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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170817/0dbfdb00/attachment.sig>