Re: Choose signing key
- From: Bruno Miguel <brunoalexandremiguel gmail com>
- To: Albrecht Dreß <albrecht dress arcor de>
- Cc: balsa-list gnome org
- Subject: Re: Choose signing key
- Date: Sat, 02 Aug 2008 14:13:17 +0100
Em 02-08-2008 14:02:00 Albrecht Dreß escreveu:
> Hi Bruno:
>
> Am 02.08.08 13:36 schrieb(en) Bruno Miguel:
> > I have two openpg keys, but that doesn't allow me to choose the one
> I
> > want to use.
>
> Balsa automatically chooses the key from the e-mail address of your
> identity. Each key contains at least one User ID (UID; == mail
> address), but you may add more for other mail addresses you have
> (this
>
> is a quite common case, try "gpg --list-keys"). If you have more
> than
>
> one key for the same mail address (which is an unusual case!), Balsa
> will pop up a dialogue and ask you which key you want to use for
> signing.
>
> You can use either gpg or a tool like Seahorse to add more UID's to
> your keys, which would leave you with more than one key containing
> some
> or all of your e-mail identities. However, now Balsa will pop up the
>
> dialogue to choose the key every time, which may be quite annoying.
>
> As I said before, this setup is rather unusual, so I don't think
> adding
> an identity setup option for this would have high priority... Maybe
> you can describe your use case somewhat more detailed, in particular
> why it doesn't fit into the scheme described above, so I get a little
>
> more insight?
>
> > It would be really useful to have the ability to create signing
> > filters, that is, create a filter to sign an email sent to specific
>
> > addresses, avoiding forgetting to sign an important message.
>
> Why don't you want to sign each and every message you send? I
> recommend to use the GnuPG MIME mode for that; Balsa will create a
> multipart/signed which should be compatible with all current MUA's
> (read: people still using elm on an ancient pdp-11 will have
> problems...), and those not knowing about security (like M$ Outlook
> or
>
> web mailers) will simply ignore it. Or didn't I get your point here?
>
> A different thing is the /encryption/ of messages, as many recipients
>
> still don't have GnuPG keys, so it's a problem to activate it by
> default. I added an option "remind me if messages can be encrypted"
> to
> the identities a while ago. I have this option activated, and "sign
> with GPG/MIME" as default. Now every message I send will be signed
> (unless I explicitly deactivate it for a specific message), and a
> dialogue will ask me if I want to encrypt if keys exist for all To:
> and
> Cc: recipients (note that messages with bcc: recipients cannot be
> encrypted, as it would break their privacy). IMO, this is really
> useful so I don't forget to encrypt if it would be possible.
>
> Please remember that /signing/ the message does *not* protect your
> privacy. The message body is still readable for everybody
> (sysadmins,
>
> police, whoever) like a postcard. The signature is just a proof for
> the recipient that it was really you who wrote the message. As to
> protect you privacy, you must *encrypt* messages (have a look at the
> source of signed vs. encrypted messages).
>
> > Also, that could be complemented with an option to choose specific
> > keys for the filters, because you probably don't sign all your
> emails
> > with the same key; some need a key only shared with close people.
>
> What is the reason behind that? The idea of GnuPG is that you can
> share your *public* key with everybody, preferably using a key
> server.
>
> There is absolutely no reason to keep it secret! Of course, you
> *must*
> protect your private key...
>
> Hope this helps,
> Albrecht.
>
What I'm writing about is levels of trust. I'm helping some projects
and want to sign the emails I send to those addresses with a specific
key I don't want to share with all the other addresses. Also, to some
other addresses, I'll want to sign with other key. Different keys with
the same email = different levels of trust, so I can also encrypt some
emails that only a small amount of people will be able to decrypt.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]