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 ke
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 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
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 t
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, 0
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 u
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
>
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 s
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;
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 a
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 ke
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
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
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 no
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 mat
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 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/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 def
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 worl
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 misunders
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
mat
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
-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
>
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 user ID, whether or irrespective of the calculated validity of
the User ID in
-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 ei
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 impo
-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 inf
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.
28 matches
Mail list logo
