Tim wrote:
> John Doe <johndoe@xxxxxxxxxxx> creates his own key, signs his messages,
> publishes his key. You receive his message, you check the key, it's
> confirmed.
Part of checking the key includes verifying the key id and
fingerprint. After verifying this info I would sign the key to make
it valid. (A signature can be marked as non-exportable, for keys you
want to sign but don't want your signature to be exported along with
that key if you sent it to someone else.)
With a signature from my trusted key on John Doe's key, gpg now treats
this key as valid.
> Moriarty decides to be a pain, creates an email account to
> masquerade as John as well "John Doe" <johndoe@xxxxxxxxxxx>, creates
> his own key, signs his message, publishes his key. You receive his
> message, you check its key (automatically fetched by using the ID
> code present in the signed message), it confirms the message and
> signature go together.
And since this key is not signed by a trusted key, gpg will flag this
signature with something like this:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs
gpg: to the owner.
This info is propgated in the output sent to any plugin as well. If a
mail plugin doesn't make it visible in some way to the user, then that
plugin is pure shit and it's authors should be hounded for making
security software.
I use mutt and I see the gpg output directly. I've played around with
thunderbird and kmail to help friends and both have indicators for
this sort of thing. I'd be a little surprised it evolution doesn't
handle it in some way as well.
This is all not that different from signatures on paper. If I sign a
document as John Doe and you trust it without any other verification
that I am the John Doe you wish to do business with, you can be easily
fooled.
(As far as keys being automatically fetched, that's a choice each user
can make. It's not enabled by default in gpg. I don't automatically
fetch keys for every message. I don't need my keyring to be that
large and I have no plans to verify most keys.)
> That's how every co-operative mail/PGP client I've used works.
I think that you may be looking past the various visual clues that the
plugins give to indicate the validity of the key used to sign a
message. If not, you've see some very poor plugins. :)
> There really is nothing that either person can do to invalidate the
> other key. It'd take a war of words between the two people in a
> common forum for someone else to tell them apart. Even then, some
> will believe they're the same person, just playing at trolling
> games. It's common enough for users to have multiple addresses, and
> they may use separate PGP keys.
No one has to invalidate anyone else's key. I sign my messages with a
key that has the following properties:
pub 2048R/BEAF0CE3 2006-07-04
Key fingerprint = 2067 23CE 8C4A 9D39 9FFF B8E7 4325 938B BEAF 0CE3
uid Todd M. Zullinger <tmz@xxxxxxxxx>
sub 4096R/8550ADF3 2006-07-04 [expires: 2012-12-21]
Import and sign that key on your keyring (--lsign-key in gpg). Then,
in another user account, generate a key with the same user id. Export
this key to a file somewhere and then import it to your normal users
keyring (otherwise you'll have the secret key in your keyring and thus
the key will also be marked as valid, which will make the effects of
the test less visible to you).
Send yourself a message signed by this fake key from the user account you
generated the key in, and check it in your mail client as your normal
user. You should notice right away that the message isn't signed by a
valid key.
> I don't want to test whether a keyserver will accept being given two
> different keys for the same address (e.g. Moriarty faking mails sent
> as johndoe@xxxxxxxxxxx rather than the second address). It's just
> too hard to take things out the system, it doesn't have a real
> delete functionality. But I suspect it will.
Most keyservers definitely will. (The PGP Global Directory won't, but
it has different goals than other keyservers.)
> In the past I've submitted keys to keyserver, and that's included
> two different keys that include a common e-mail address. A mail
> client wanting a key would be asking for the key by ID not e-mail
> address. It'll get the key that matches the message they're
> checking.
If you're just verifying a signature via a downloaded key which you've
not checked out in any other way, then you'll get the big fat WARNING
like the one above. If you choose to ignore that and trust the signed
message anyway, then that's not a failing of the system, it's a user
failure. (It's a large software failure if that warning doesn't make
it to you in some form.)
> Most aren't, I've got a few that do. Just doing a quick search, I
> found an old one, and attached it to this message.
Ahh. Thanks. That one was from the FC3 era. I don't know much about
how the process worked then, I wasn't paying any attention to it at
that point. I'm sure that a lot has changed since then about how
update notices are sent out. I know the process has changed with the
merging of core and extras, as far as updates to F7 are handled.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nothing is so simple that it cannot be misunderstood.
-- Teague's Paradox
Attachment:
pgpvRDsm3UwD8.pgp
Description: PGP signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
