Re: Choose signing key



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]