encrypting to a user, "There is no assurance this key belongs to the named user"

[Michael Tokarev]

21.06.2013 14:00, Henry Hertz Hobbit wrote:
> On 06/21/2013 07:50 AM, Michael Tokarev wrote:
>> Hello.
>>
>> Recently I upgraded a Debian machine from squeeze to wheezy,
>> which lead to upgrading gnupg from 1.4.10 to 1.4.12.  And
>> immediately noticed that many automated tools I used stopped
>> working, refusing to encrypt with the error indicated in the
>> subject.
>>
>> $ gpg --batch -q --encrypt --recipient rconf < foo > foo.enc
>> gpg: 468E35BC: There is no assurance this key belongs to the named user
>> gpg: [stdin]: sign+encrypt failed: unusable public key
> 
> Who or what is "gconf"?  If that is what is actually used then
> it is neither an email address or the keyid.  I suggest as your
> first step replacing "rconf" with the actual key-id (number) you
> want to encrypt for to see if that works. It is just that GnuPG
> seems to be having problems with the supplied user name.  If
> rconf was meant to be an email address either it doesn't match
> that field completely or maybe you had a define in your
> ~/.gnupg/gpg.conf that is now missing.

Well.. I didn't think this might be relevant.  As I wrote further
in my original email, the problem goes away when I mark this
key as 'trusted', so it didn't look like marking some key as
trusted will help gpg to establish relationship between that
key and its name.

Actual command line and keys are (domain name replaced with
example.com):

 $ gpg --batch -q --encrypt --sign --recipient '<rconf at example.com>' < test > test.sign

 $ gpg --list-sigs | sed 's/domain/example.com/g'
 pub   1024R/A8983CE7 2005-01-27
 uid                  f0501.example.com (main key) <radm at f0501.example.com>
 sig 3        A8983CE7 2005-01-27  f0501.example.com (main key) <radm at f0501.example.com>
 sub   1024R/8BB2CB48 2005-01-27
 sig          A8983CE7 2005-01-27  f0501.example.com (main key) <radm at f0501.example.com>

 pub   1024R/DC42DA4C 2005-01-27
 uid                  rconf receiver <rconf at example.com>
 sig 3        DC42DA4C 2005-01-27  rconf receiver <rconf at example.com>
 sig   L      A8983CE7 2013-06-21  f0501.example.com (main key) <radm at f0501.example.com>
 sub   1024R/468E35BC 2005-01-27
 sig          DC42DA4C 2005-01-27  rconf receiver <rconf at example.com>

Note that gpg mentions 468E35BC which is a subkey of DC42DA4C, as
far as I can understand.

> We can go from there if this doesn't work.

Well, quite expectedly it doesn't work... ;)

Using either DC42DA4C, or DC42DA4C, as --recipient, makes no difference,
it still complains as in $subject unless I also use --trust-model=always.

Thanks,

/mjt