On Thursday 01 October 2009, Daniel Kahn Gillmor wrote:
On 09/30/2009 05:32 PM, Ingo Klöcker wrote:
Hmm, AFAIU, for someone who does not blindly certify such keys this
shouldn't be a problem since those malicious keys wouldn't be valid
and thus wouldn't take preference over a valid key ...
On Wednesday 30 September 2009, Daniel Kahn Gillmor wrote:
Thanks for the discussion, Ingo! This is really useful to me, and i
appreciate the thought you've obviously put in here.
Thank you, the same to you! You really make me thinking.
On 09/29/2009 04:32 PM, Ingo Klöcker wrote:
She
On 09/30/2009 05:32 PM, Ingo Klöcker wrote:
Hmm, AFAIU, for someone who does not blindly certify such keys this
shouldn't be a problem since those malicious keys wouldn't be valid and
thus wouldn't take preference over a valid key ... unless somebody else
this person trusts is trying to
On Monday 28 September 2009, Daniel Kahn Gillmor wrote:
On 09/25/2009 02:40 PM, Ingo Klöcker wrote:
0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo
Klöcker went to the same school and the same university as I did.)
0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99,
Thanks for the discussion, Ingo! This is really useful to me, and i
appreciate the thought you've obviously put in here.
On 09/29/2009 04:32 PM, Ingo Klöcker wrote:
She creates a new key, but Bob
continues to use the old key. Unless Bob automatically imports unknown
keys, he will notice
On 09/25/2009 02:40 PM, Ingo Klöcker wrote:
0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker
went to the same school and the same university as I did.)
0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9
(this last one is definitely still in use)
On 09/24/2009 04:56 PM, Ingo Klöcker wrote:
Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with
PGP 6 (or earlier) where the user ID is not UTF-8 encoded?
hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and 0xAB1BC4E6
doesn't appear to be available on the public
On Sep 25, 2009, at 10:04 AM, Daniel Kahn Gillmor wrote:
Since most of
these tools rely on gpg as a backend, implementing a more-reasonable
choice in gpg seems like a good idea.
What troubles me about this sort of behavior is that it is genuinely
good and helpful in some cases and baffling
On Friday 25 September 2009, Daniel Kahn Gillmor wrote:
On 09/24/2009 04:56 PM, Ingo Klöcker wrote:
Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created
with PGP 6 (or earlier) where the user ID is not UTF-8 encoded?
hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and
On 09/25/2009 11:06 AM, David Shaw wrote:
What troubles me about this sort of behavior is that it is genuinely
good and helpful in some cases and baffling and off-putting in others.
For example, someone has two different Alice keys in their keyring.
Both keys have a single UID, which is
On Friday 25 September 2009, Daniel Kahn Gillmor wrote:
On 09/25/2009 11:06 AM, David Shaw wrote:
What troubles me about this sort of behavior is that it is
genuinely good and helpful in some cases and baffling and
off-putting in others. For example, someone has two different Alice
keys
On Wed, 23 Sep 2009 19:04, d...@fifthhorseman.net said:
Has this been made this clear to collaborating MUA/plugin developers? I
think the auto select a key step for MUAs or plugins is often
implemented as let gpg pick the key based on the user ID.
I added PGP/MIME crypto to several MUA and
On Thursday 24 September 2009, Daniel Kahn Gillmor wrote:
On 09/23/2009 06:04 PM, Ingo Klöcker wrote:
I'm pretty sure that this will break horribly as soon as the user
ID contains non-ASCII characters (as does my user ID). For exactly
this reason I made KMail use the key ID instead of the
On 09/22/2009 07:16 PM, David Shaw wrote:
It doesn't work that way. The default is the first valid key. It's
been that way in the PGP world since before GPG as a product was
written. If you want to propose a specific alternative, I'm ready to
listen, but I'm not going to defend the default
On Wed, 23 Sep 2009 15:34, d...@fifthhorseman.net said:
OK; if i'm proposing one specific alternative, it would be:
Please keep in mind that using a user ID is just to help the user in the
most common case. Any proper mail tool won't accept such a solution but
either presenr the user a list of
On 09/23/2009 12:17 PM, Werner Koch wrote:
Please keep in mind that using a user ID is just to help the user in the
most common case. Any proper mail tool won't accept such a solution but
either presenr the user a list of matching keys and let him select a key
or auto select the key based on
On Wednesday 23 September 2009, Daniel Kahn Gillmor wrote:
On 09/23/2009 12:17 PM, Werner Koch wrote:
Please keep in mind that using a user ID is just to help the user
in the most common case. Any proper mail tool won't accept such a
solution but either presenr the user a list of matching
On 09/23/2009 06:04 PM, Ingo Klöcker wrote:
I'm pretty sure that this will break horribly as soon as the user ID
contains non-ASCII characters (as does my user ID). For exactly this
reason I made KMail use the key ID instead of the user ID about 7 years
ago.
What makes you think that
when encrypting messages to a user ID with multiple matching keys with
full calculated validity, gpg seems to just choose the first matching
key, for some definition of first -- i think it's decided by
chronological age of first import into the local keyring.
This does not seem to be the best
Daniel Kahn Gillmor wrote:
when encrypting messages to a user ID with multiple matching keys with
full calculated validity, gpg seems to just choose the first matching
key, for some definition of first -- i think it's decided by
chronological age of first import into the local keyring.
IIRC,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
John Clizbe wrote:
IIRC, it's the first usable key with a matching User ID. Period. First one it
can use.
My usual 'solution' for this is to 'Disable' the non-preferred or unused
Key until such time as it is Revoked or I have been otherwise
On Sep 22, 2009, at 1:11 PM, Daniel Kahn Gillmor wrote:
when encrypting messages to a user ID with multiple matching keys with
full calculated validity, gpg seems to just choose the first
matching
key, for some definition of first -- i think it's decided by
chronological age of first import
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
David Shaw wrote:
[1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the
same way any longer. I don't have my copy of PGP command line online at
the moment, so I can't check what it does, but I'd be surprised if it
didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Daniel Kahn Gillmor wrote:
On 09/22/2009 04:57 PM, John W. Moore III wrote:
Like GPG it utilizes the 1st encountered Key that matches the Send To:
address is valid.
this is not what gpg does. gpg simply chooses the first key with a
matching
On 09/22/2009 04:09 PM, John W. Moore III wrote:
John Clizbe wrote:
IIRC, it's the first usable key with a matching User ID. Period. First one it
can use.
thanks for catching that, John. It appears that if the first key with a
matching User ID doesn't have full calculated validity, the user
On Sep 22, 2009, at 4:40 PM, Daniel Kahn Gillmor wrote:
On 09/22/2009 04:09 PM, John W. Moore III wrote:
John Clizbe wrote:
IIRC, it's the first usable key with a matching User ID. Period.
First one it
can use.
thanks for catching that, John. It appears that if the first key
with a
On 09/22/2009 06:30 PM, David Shaw wrote:
I think the current behavior is the right one. Otherwise we break
however many baked-in uses out there (scripts, etc), to say nothing of
having to explain to people why a particular key was chosen. We pick
the first valid key cannot be misunderstood
On Sep 22, 2009, at 6:54 PM, Daniel Kahn Gillmor wrote:
Can you give me an example of a script
that has this behavior baked in to the point where adopting a better
heuristic would break it?
It doesn't work that way. The default is the first valid key. It's
been that way in the PGP world
28 matches
Mail list logo
