Daniel Kahn Gillmor dkg at
Wed Oct 14 23:40:41 CEST 2009

Hi Connie--

I'm glad that was useful.

On 10/14/2009 05:07 PM, CONNIE RODRIGUEZ wrote:
> I attempted key signing but was not successful.  I received the following output:
> [lawhr at lsftest1/usr/local/bin # ./gpg --edit-key REWARD
> pub  1024D/C2126D6D  created: 2009-02-23  expires: never       usage: SC
>                      trust: unknown       validity: unknown
> sub  2048g/4D5AFE2E  created: 2009-02-23  expires: never       usage: E
> [ unknown] (1). REWARD data interchange 2009
> Command> sign
> gpg: no default secret key: secret key not available
> Command>
> Any help is appreciated!

It sounds to me like you might be confusing validity with ownertrust.
In my earlier note, i suggested that you *trust* the keyholder of some
key that will certify the keys you are encrypting to.

Instead, it looks to me like you've chosen to try to *sign* one of the
keys you're encrypting to directly from the server.

It helps me to separate out these concepts into two ideas:

 0) who do you know (i.e. who can you identify)?

 1) who do you trust to identify others?

And since you're dealing with two different gpg installations (one on
the server and one that you control elsewhere) you probably want to
think about those from separate perspectives.

I don't know what you're planning to do on your server, but i'll pretend
for the moment that you're working with a web application which is
expected to recieve information over the web, and then encrypt it to
someone.  I'll refer to that someone as the "encryption target".

from the webapp's view, how does it know it's encrypting info to the
right person?

let's say you're the administrator of such a system, and you want the
webapp to believe you when you certify that a certain key belongs to a
given person.  Then you (as the admin) would have your own OpenPGP key,
stored off of the server (probably on your own workstation someplace).
Let's assume that key is key ID 0xDECAFBAD. You'd upload the public part
of 0xDECAFBAD to the server, and import it into the webapp's keyring.
After import *as the webapp user* you'd say "i trust the sysadmin to
identify encryption targets" by doing:

  gpg --edit-key 0xDECAFBAD

and then designate "ultimate" ownertrust.

Then, you'd use your own key to certify the key belonging to the
encryption target -- you'd "sign the target's public key" with your own
key.  Then you'd upload the target's public key (with your
certification) to the server, and import it into the webapp's keyring.

Does this make sense?  The advantage of this arrangement is that now
your webapp can be used to encrypt to a variety of people -- you'll just
need to sign their keys, and they can be encryption targets as well.

hope this helps,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091014/5f62d664/attachment.pgp>

More information about the Gnupg-users mailing list