importing PGP keys

[Eric Abrahamsen]

So someone just emailed me their public PGP key. I can save the MIME
attachment to a file, then call "gpg --import thekey.key", but the
resulting key isn't associated with their email address, and therefore
I'm not able to send them encrypted emails, at least not by default.

Does anyone have a clever function for importing an attached key and
automatically associating it with the email address which sent it? Or
somehow doing it after the fact? I've been googling for a while now, and
haven't found the answer...

Thanks,
Eric

[Greg Troxel]

Post by Eric Abrahamsen
So someone just emailed me their public PGP key. I can save the MIME
attachment to a file, then call "gpg --import thekey.key", but the
resulting key isn't associated with their email address, and therefore
I'm not able to send them encrypted emails, at least not by default.
Does anyone have a clever function for importing an attached key and
automatically associating it with the email address which sent it? Or
somehow doing it after the fact? I've been googling for a while now, and
haven't found the answer...

There are three separate issues lurking here:

1) getting the key to gpg --import
2) how to record an email address -> pubkey mapping
3) how to do (2) automatically

1 and 3 are certainly useful code to share, but don't seem super tricky.
I am curious what people are doing for 2. bbdb?

Also, are you using epg? It seems that is the preferred way (over pgg)
these days, and it's what I use.

[Russ Allbery]

Post by Greg Troxel
1 and 3 are certainly useful code to share, but don't seem super tricky.
I am curious what people are doing for 2. bbdb?

GnuPG does this itself using the email address published in the key ID,
and I normally just rely on that and don't retain keys in my personal
public keyring that violate my expectations there. (Admittedly, I'm not
great about checking this.)

Are you running across keys where the address at which you contact the
person isn't represented in the key IDs? Or are just not wanting to trust
the information GnuPG retains?

I think the default Gnus behavior is to use GnuPG to check for a key ID
matching the target email address.

[Eric Abrahamsen]

Post by Russ Allbery

Post by Greg Troxel
1 and 3 are certainly useful code to share, but don't seem super tricky.
I am curious what people are doing for 2. bbdb?

GnuPG does this itself using the email address published in the key ID,
and I normally just rely on that and don't retain keys in my personal
public keyring that violate my expectations there. (Admittedly, I'm not
great about checking this.)
Are you running across keys where the address at which you contact the
person isn't represented in the key IDs? Or are just not wanting to trust
the information GnuPG retains?
I think the default Gnus behavior is to use GnuPG to check for a key ID
matching the target email address.

In my case, the problem was that the person just sent me the raw public
key block; ie not the output of gpg --export, which would include the
UIDs along with the key itself. Now I have this key in my public keyring
with no email address associated with it at all, so when I get an
encrypted email from this person, there's no immediate way to tell Gnus
which key to use when decrypting the email.

I was sure that the gpg key management interface would provide some way
of manually adding an email address to someone else's public key, but
I'm not finding it...

[Jens Lechtenboerger]

Post by Eric Abrahamsen

Post by Greg Troxel
1 and 3 are certainly useful code to share, but don't seem super tricky.
I am curious what people are doing for 2. bbdb?

I’m using jl-encrypt ;)
http://www.emacswiki.org/emacs/DefaultEncrypt

Post by Eric Abrahamsen
In my case, the problem was that the person just sent me the raw public
key block;

I’m surprised that this is possible. How, actually?
You might want to warn him/her not to do this.

Without uid, you must remember the key fingerprint if you want to
use the key. This does not appear to be human friendly. Moreover,
as any link between key and e-mail address is missing, e-mail
software cannot offer automatic encryption.

Post by Eric Abrahamsen
I was sure that the gpg key management interface would provide some way
of manually adding an email address to someone else's public key, but
I'm not finding it...

An owner of the secret key can use the gpg command adduid.

You must not be able to add uids to other people’s keys. Otherwise,
you could redirect e-mails encrypted to them.

Best wishes
Jens

[Eric Abrahamsen]

Post by Jens Lechtenboerger

Post by Eric Abrahamsen

Post by Greg Troxel
1 and 3 are certainly useful code to share, but don't seem super tricky.
I am curious what people are doing for 2. bbdb?

I’m using jl-encrypt ;)
http://www.emacswiki.org/emacs/DefaultEncrypt

Interesting, thanks for the link! But that doesn't look like it can tell
Gnus to use a certain key for certain contacts. I assume I'd need some
sort of BBDB-based thing to work well.

Post by Jens Lechtenboerger

Post by Eric Abrahamsen
In my case, the problem was that the person just sent me the raw public
key block;

I’m surprised that this is possible. How, actually?
You might want to warn him/her not to do this.
Without uid, you must remember the key fingerprint if you want to
use the key. This does not appear to be human friendly. Moreover,
as any link between key and e-mail address is missing, e-mail
software cannot offer automatic encryption.

I think I was confused -- it's not that the key has no uid, but that
the uid is just a string of letters, not an email address. Not human
friendly, indeed! But I guess not actually a malformed public key. Still
makes it very hard to exchange encrypted emails.

Post by Jens Lechtenboerger

Post by Eric Abrahamsen
I was sure that the gpg key management interface would provide some way
of manually adding an email address to someone else's public key, but
I'm not finding it...

An owner of the secret key can use the gpg command adduid.
You must not be able to add uids to other people’s keys. Otherwise,
you could redirect e-mails encrypted to them.

Very good point!