trust, ownertrust, secret keys, --status-fd, --trusted-key

[Hauke Laging]

Hello,

after playing around with unfamiliar gpg features for hours I am confused now. 
You may already have guessed from the subject...

Those hours ago I believed to have understood the concept of trust and 
ownertrust. I don't use the WoT thus I never cared much about ownertrust. 
Important to me was only that gpg considered keys valid when checking 
signatures. My understanding was that keys are valid if

1) you have their secret key
2) they are marked trusted by --trusted-key (important to me due to offline 
mainkeys and smartcards)
3) they are signed by a trusted key
4) their ownertrust is set to ultimate

My confusion started when playing with --status-fd and reading the DETAILS 
file. It says:

##################################
TRUST_UNDEFINED <error token>
TRUST_NEVER     <error token>
TRUST_MARGINAL  [0  [<validation_model>]]
TRUST_FULLY     [0  [<validation_model>]] 
TRUST_ULTIMATE  [0  [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
##################################

Now the problems arise. To me these are ownertrust values. But a signature can 
IMHO be valid or invalid only (depending on its key's signatures and the 
configuration). What is needed for a valid signature, TRUST_ULTIMATE? This is 
what I get with successful verifications.

LC_ALL=C gpg --list-options show-uid-validity --list-sigs
shows me [ultimate], [  full  ] and [ unknown] only (and [ expired]). That may 
be caused by me not using the WoT. Is this "full" the same as with ownertrust? 
If --completes-needed is set above 1 then a key can be signed by a fully 
trusted user and is then what? "[  full  ]" but not valid?

Perhaps you can point me at some good online recource for understanding this. 
I had a look at gnupg.org but the explanation I found was not in much detail.


I just noticed that calling gpg once with --trusted-key writes to the trustdb. 
If you leave out that option in the next call the key still has ultimate trust 
(even if the secret key is not available). That does not make sense to me. If 
I want a permanent change then I change the trustdb (or put this option in the 
config file). Furthermore I consider a verification a pure read-only 
operation. If this behaviour is not considered a bug then I recommend a 
suitable hint (read: warning) in the documentation.

There's another problem with --trusted-key or its documentation. It says:

"Assume  that  the specified key (which must be given as a full 8 byte key ID) 
is as trustworthy as one of your own secret keys."

Due to this description it does not make sense to me that this option changes 
the calculated trust for a key which has a secret key available. Perhaps this 
is not intended but just a result of the empty trustdb (--check-trustdb 
doesn't change that though). Either the documentation should be changed or the 
secring be checked (in addition to the trustdb).


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120229/fa9542c9/attachment.pgp>