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

hhhobbit at securemecca.net hhhobbit at securemecca.net
Sun Jun 23 18:44:35 CEST 2013


> On June 22, 2013 at 4:52 AM Michael Tokarev <mjt at tls.msk.ru>
> wrote:
>
>
> 22.06.2013 11:56, Peter Lebbing wrote:
> > On 21/06/13 12:34, Michael Tokarev wrote:
> >> It says "validity: unknown"
> >
> > I just thought of something. If for some reason your /own/
> > key is no longer
> > trusted, you can make signatures all day but it won't
> > increase validity.
> >
> > If you do --edit-key A8983CE7, what does its trust say?
>
> That was it.
>
> $ gpg ... --edit-key A8983CE7
> Secret key is available.
>
> pub 1024R/A8983CE7 created: 2005-01-27 expires: never usage:
> SC
> trust: unknown validity: unknown
> sub 1024R/8BB2CB48 created: 2005-01-27 expires: never usage: E
> [ unknown] (1). f0501...
>
>
> After setting trust to it:
>
> pub 1024R/A8983CE7 created: 2005-01-27 expires: never usage:
> SC
> trust: ultimate validity: ultimate
> sub 1024R/8BB2CB48 created: 2005-01-27 expires: never usage: E
> [ultimate] (1). f0501...
>
> and it now does not complain anymore when encrypting data to
> other
> keys, without re-signing anything.
>
> Wow.
>
> WOW!
>
> Thank you very much for this, awesome guess.
>
> I think in quite some other cases when users had to trust
> _other_
> keys to be able to encrypt data to them the actual problem was
> the
> same as in my case.
>
> And it's interesting that this prob only manifested itself now
> after
> upgrade from 1.4.10 to 1.4.12.
>
> I think I've seen similar issue myself before in other
> situation, it
> was very much like that, so I too had to indicate ultimate
> trust for
> other keys like that. But it was several years ago.
>
> Thanks you guys!

Well, it was Peter's thinking that saved you.  Great job!  I
will file that
tidbit of information away because I have some similar upgrades
in
the future and want my keys to last 8 more years or until there
is a
paradigm shift that makes the present keys obsolete, which ever
comes first.

Kudos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130623/97ea2657/attachment.html>


More information about the Gnupg-users mailing list