Michael J Gruber [off-list ref] writes:
Jeff King venit, vidit, dixit 27.01.2016 09:09:
quoted
The bigger issue is that gpg seems to give us only _one_ uid, when there
may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
sub-key that has several uids associated with it. The one that "git
verify-tag --raw" shows from gpg is gitster@pobox.com, which is good,
but I think that's just because it happens to be the first uid. Or maybe
there is some gpg arcana going on that I don't know about.
You do not sign with a uid, you sign with a (sub)key, and the tag is
signed with Junio's primary key. His subkey is encryption only.
Hmm, actually I meant to sign my tags with signing subkey, not the
primary one, but I may have made a mistake.
You do sign a uid.
So, if you want to be sure that a tag is signed "with a specific uid" by
relying on signatures from a set of signers, you would really need to
check that the key that signed the tag has a signature on the correct
uid. Having a signed key with the right uid in it doesn't mean much
unlss the right uid is signed.
E.g., I have a key with many signatures, and I could have Junio's uid on
it in a minute without invalidating any of those signatures.
I have signatures on my primary key from others, and my signing key
is signed by my primary key and by no other keys. Here is an
abbreviated output from running "gpg --list-sigs 96AFE6CB":
pub 4096R/713660A7 2011-10-01
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 93674C40 2011-10-04 Theodore Y. Ts'o [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sig C11804F0 2011-10-04 Theodore Ts'o [off-list ref]
sig 02A80207 2011-10-05 Andrew Morton (akpm) [off-list ref]
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sig C11804F0 2011-10-04 Theodore Ts'o [off-list ref]
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sub 4096R/833262C4 2011-10-01
sig 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
sig 713660A7 2015-09-21 Junio C Hamano [off-list ref]
sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
sig 713660A7 2014-09-20 Junio C Hamano [off-list ref]
So I understand that the way you trust 96AFE6CB has to be indirect.
You may have somebody's key you know belongs to that somebody you
trust (say, Linus) in the list of signers of 713660A7 (my primary),
and you know 96AFE6CB is a key I use because it is signed by my
primary key.
You can add a subkey to your keyring a uid that says "Junio", but
the signature on that subkey would not have a signature by me you
can verify by following the web of trust. You are correct to point
out that "this key claims to be by somebody, and it has some
signature" is not a sufficient reason for you to trust it.
That one is easy already by setting "GNUPGHOME" to a special dir with a
small keyring and tight trust settings (or having a dedicated account on
the incoming side in the first place).
Yes, I understand that the above is how automated services per
project should be set up, with a dedicated verification keyring that
holds keys the project trusts.
Junio C Hamano venit, vidit, dixit 27.01.2016 19:10:
Michael J Gruber [off-list ref] writes:
quoted
Jeff King venit, vidit, dixit 27.01.2016 09:09:
quoted
The bigger issue is that gpg seems to give us only _one_ uid, when there
may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
sub-key that has several uids associated with it. The one that "git
verify-tag --raw" shows from gpg is gitster@pobox.com, which is good,
but I think that's just because it happens to be the first uid. Or maybe
there is some gpg arcana going on that I don't know about.
You do not sign with a uid, you sign with a (sub)key, and the tag is
signed with Junio's primary key. His subkey is encryption only.
Hmm, actually I meant to sign my tags with signing subkey, not the
primary one, but I may have made a mistake.
Oops, I needed to refresh my copy of your key, sorry. You did sign 2.7.0
with the subkey 0xB0B5E88696AFE6CB
quoted
You do sign a uid.
So, if you want to be sure that a tag is signed "with a specific uid" by
relying on signatures from a set of signers, you would really need to
check that the key that signed the tag has a signature on the correct
uid. Having a signed key with the right uid in it doesn't mean much
unlss the right uid is signed.
E.g., I have a key with many signatures, and I could have Junio's uid on
it in a minute without invalidating any of those signatures.
I have signatures on my primary key from others, and my signing key
is signed by my primary key and by no other keys. Here is an
abbreviated output from running "gpg --list-sigs 96AFE6CB":
pub 4096R/713660A7 2011-10-01
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 93674C40 2011-10-04 Theodore Y. Ts'o [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sig C11804F0 2011-10-04 Theodore Ts'o [off-list ref]
sig 02A80207 2011-10-05 Andrew Morton (akpm) [off-list ref]
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sig C11804F0 2011-10-04 Theodore Ts'o [off-list ref]
uid Junio C Hamano [off-list ref]
sig 3 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sig F3119B9A 2011-10-01 Junio C Hamano [off-list ref]
sig 493BACE4 2011-10-04 H. Peter Anvin (hpa) [off-list ref]
sig 00411886 2012-07-20 Linus Torvalds [off-list ref]
sub 4096R/833262C4 2011-10-01
sig 713660A7 2011-10-01 Junio C Hamano [off-list ref]
sub 4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
sig 713660A7 2015-09-21 Junio C Hamano [off-list ref]
sub 4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
sig 713660A7 2014-09-20 Junio C Hamano [off-list ref]
So I understand that the way you trust 96AFE6CB has to be indirect.
You may have somebody's key you know belongs to that somebody you
trust (say, Linus) in the list of signers of 713660A7 (my primary),
and you know 96AFE6CB is a key I use because it is signed by my
primary key.
You can add a subkey to your keyring a uid that says "Junio", but
the signature on that subkey would not have a signature by me you
can verify by following the web of trust. You are correct to point
out that "this key claims to be by somebody, and it has some
signature" is not a sufficient reason for you to trust it.
"subkey" and "uid" are different things. You bind a subkey to your
primary key with that self-signature. subkeys don't carry any other
signatures.
A primary key "carries" the uids, and whenever someone "signs your key"
they in fact sign a specific uid - usually all, resulting in multiple
signatures, one for each uid of the (primary) key.
A key is usually considered trusted if it carries "a" signature from a
trusted key.
So, assuming my key carries a signature from a trusted key to at least
one uid, it would be trusted no matter what (fake) uids I add to it later.
quoted
That one is easy already by setting "GNUPGHOME" to a special dir with a
small keyring and tight trust settings (or having a dedicated account on
the incoming side in the first place).
Yes, I understand that the above is how automated services per
project should be set up, with a dedicated verification keyring that
holds keys the project trusts.
Michael
On Wed, Jan 27, 2016 at 09:09:31PM +0100, Michael J Gruber wrote:
"subkey" and "uid" are different things. You bind a subkey to your
primary key with that self-signature. subkeys don't carry any other
signatures.
A primary key "carries" the uids, and whenever someone "signs your key"
they in fact sign a specific uid - usually all, resulting in multiple
signatures, one for each uid of the (primary) key.
A key is usually considered trusted if it carries "a" signature from a
trusted key.
So, assuming my key carries a signature from a trusted key to at least
one uid, it would be trusted no matter what (fake) uids I add to it later.
Right. I think I didn't do a good job of explaining myself earlier, so
let me try to rephrase.
When we look at the v2.7 tag, GPG sees that we are signed by Junio's
subkey, 96AFE6CB. It then knows that belongs to the main public key
713660A7, because the main key signed the subkey. And then it sees that
there are several uids for that main key, each with their own signatures
by other people.
So of the three uids that I have for that key:
pub 4096R/713660A7 2011-10-01
uid Junio C Hamano [off-list ref]
uid Junio C Hamano [off-list ref]
uid Junio C Hamano [off-list ref]
it reports back to git only one (the pobox.com), which we relay to the
user via --raw. If we wanted to check that the key matches the "tagger"
header, that works. But why did gpg return that first uid, and not any
of the others? We would ideally see all of them, and consider it OK if
it matches any uid (assuming that uid is sufficiently signed for gpg to
consider it valid).
Weirder, if you _don't_ use "--raw", the human-readable output gives us
all of the uids as "aka" lines:
$ git verify-tag v2.7.0
$ git verify-tag v2.7.0
gpg: Signature made Mon 04 Jan 2016 05:08:12 PM EST using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano [off-list ref]"
gpg: aka "Junio C Hamano [off-list ref]"
gpg: aka "Junio C Hamano [off-list ref]"
$ git verify-tag --raw v2.7.0
[GNUPG:] SIG_ID xFANmHj+QJ1gwIcoRuT5BF/y8H4 2016-01-04 1451945292
[GNUPG:] GOODSIG B0B5E88696AFE6CB Junio C Hamano [off-list ref]
[GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2016-01-04 1451945292 0 4 0 1 2 00 96E07AF25771955980DAD10020D04E5A713660A7
[GNUPG:] TRUST_FULLY
It seems like we should be able to get the raw-output to tell us all of
those uids. I guess it is not the end of the world to go back to gpg and
say "give me all of the valid uids that match this signing key", but it
seems silly to have to do so.
-Peff