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

[Michael Tokarev]

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

$ gpg --list-sigs       (names edited)
-------------------------
pub   1024R/A8983CE7 2005-01-27
uid                  f0501
sig 3        A8983CE7 2005-01-27  f0501
sub   1024R/8BB2CB48 2005-01-27
sig          A8983CE7 2005-01-27  f0501

pub   1024R/DC42DA4C 2005-01-27
uid                  rconf
sig 3        DC42DA4C 2005-01-27  rconf
sig   L      A8983CE7 2013-06-21  f0501
sub   1024R/468E35BC 2005-01-27
sig          DC42DA4C 2005-01-27  rconf


(I tried to re-sign rconf key with my f0501 key locally which
resulted in A8983CE7 - it was signed before the same way, back
in 2005, -- but it made no difference).


This error message is referenced alot in the 'net, google finds
many examples, including gnupg mailinglists.  And there are
basically two solutions:

Users suggested to [l]sign the key in question.  As you see, it
is already signed and has been signed for many years, so this
does not work.

Users suggested to indicate ultimate trust to the key in question.
This works, I verified that, but this seem to be wrong.  As asked
by --edit-key `trust' subcommand:

 Please decide how far you trust this user to correctly verify other users' keys
 (by looking at passports, checking fingerprints from different sources, etc.)

I do NOT trust that other party with their verifications of other
user's keys, at all.  It never verifies that trust, it is a robot
which collects files sent to it by other robots, and there's no
trust at all in it.  So I don't want to build my trustdb based on
that.

However, I really want to send encrypted data to that robot, even
if I don't trust its decisions in verifying users.

So it looks to me like in 1.4.12 at least, this trust model is used
wrongly -- it should not disallow encrypting data to users who's
users verification I don't trust.  I already signed their key and
thus indicated that I know who that other party is, and I want to
send encrypted data to that party -- for this, there's no need to
verify my trust to them, it is their business what they will do
with that data -- I already indicated my wish to send that data
to them, and just want it to be out of reach of spies while in-
transit.

Yes I know there's --always-trust (or --trust-model always), but
again, this - to me anyway - looks like the wrong place to use
this option, I'm not verifying someone else's signature, I'm
just sending them encrypted data.

Do I misunderstand something?

Thanks!

/mjt