Mailing List Archive

Thomas Roessler <roessler@guug.de> writes:

> Anyway, I'm getting more and more confused about the trust model of
> gpg. All over the code, I'm finding remarks about the trust into a

Maybe the reason for your confusion are the words: Originally I
used
ownertrust - trust value you assign a key hold howfar you
trust him to correctly sign other keys.
trust - the calculated trust level

Now I'll try to switch to the words used with PGP:

trust == ownertrust
validity == trust

> particular key. But that's just some kind of "weight" which should
> be used when calculating the more interesting trust information,

Gnupg does this and does this in (I hope so) a very similar way to
PGP.

> (BTW, I don't see any way to get this information out of gpg, should
> it be present - and it's the trust information I need from within

$ gpg --list-keys --with-colons
pub:q:2048:1:D2262944CE6AC6C1:1997-12-23::216:f:Thomas Roessler

2. Field: A letter describing the calculated trust, see doc/FAQ
This is a single letter, but be prepared that additional
information may follow in some future versions.
(not used for secret keys)
number to access keys later.
9. Field: Ownertrust (primary public keys only)
This is a single letter, but be prepared that additional
information may follow in some future versions.


Hope this helps,


Werner

On 1999-01-25 20:43:19 +0100, Werner Koch wrote:

> Maybe the reason for your confusion are the words: Originally I
> used

No. My problem lies in the fact that gpg assigns trust ("validity")
values to public keys, not to the association between a key and a
specific user ID, as far as I can tell. (At least I don't see any
code in list_keyblock() which looks like it dumps trust information
for a _uid_ packet, see keylist.c around line 221.)

> $ gpg --list-keys --with-colons
> pub:q:2048:1:D2262944CE6AC6C1:1997-12-23::216:f:Thomas Roessler

This is only information about the key and, maybe, about one user ID
of that key.

That doesn't suffice. Think about keys like this one:

------------------------------

% pgp -kcc 0x93478f6b

Type Bits/KeyID Date User ID
pub 2048/93478F6B 1997/06/17 Fake alert. Don't use this key. % f-1
sig! DD08DD6D 1997/06/19 Roland Rosenfeld <roland@spinnaker.rhein.de>
sig!* 593238E1 1997/06/19 Thomas Roessler <roessler@guug.de>
in-ca@individual.net SIGN EXPIRE:1998-12-31 Root CA des Individual Network e.V. <in-ca@individual.net>
sig! 93478F6B 1997/06/17 Fake alert. Don't use this key. % f-1
sig! 9D4AED4B 1997/06/17 Fake alert. Don't use this key. % f-2

------------------------------

Or think about a key which has a certified user ID and self-signs
another, bogus ID. The user must be able to tell the trusted ID
from the untrusted one.

tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi! I'm Signature Virus 99! Copy me into your signature and join the fun!

Thomas Roessler <roessler@guug.de> writes:

> No. My problem lies in the fact that gpg assigns trust ("validity")
> values to public keys, not to the association between a key and a
> specific user ID, as far as I can tell. (At least I don't see any

Right. We had a discussion about this a long time ago and this is
definetly the right way to do it. I assume that a signator always
takes the same precautions when signing a user id regardless of the
form of user id. If you think he does not - don't trust the signator.

> > $ gpg --list-keys --with-colons
> > pub:q:2048:1:D2262944CE6AC6C1:1997-12-23::216:f:Thomas Roessler
>
> This is only information about the key and, maybe, about one user ID
> of that key.

You get all the user ids

$ gpg --list-keys --with-colons 0C9857A5
pub:u:768:1:1D19F4C10C9857A5:1995-09-30::83:-:Werner Koch <werner.koch@guug.de>:
uid:::::::::Werner Koch (mein alter key) <wk@computer.org>:

> Type Bits/KeyID Date User ID
> pub 2048/93478F6B 1997/06/17 Fake alert. Don't use this key. % f-1
> sig! DD08DD6D 1997/06/19 Roland Rosenfeld <roland@spinnaker.rhein.de>
> sig!* 593238E1 1997/06/19 Thomas Roessler <roessler@guug.de>
> in-ca@individual.net SIGN EXPIRE:1998-12-31 Root CA des Individual Network e.V. <in-ca@individual.net>

A revocation certificate is the way to do this and not assigning
another user id.

> Or think about a key which has a certified user ID and self-signs
> another, bogus ID. The user must be able to tell the trusted ID

A self-signed but bogus user id ??

I know that we should have user id and certification revocations.


Werner