| gabriel rosenkoetter on 7 Feb 2004 16:22:02 -0000 |
|
On Fri, Feb 06, 2004 at 10:18:51PM -0500, David Shaw wrote: > This is a fairly standard policy. I do something similar. Yeah, but he wrote up an explanation of the "enciphered email of random strings" that it was easier for me to refer to than write up myself. :^> He got that part right, anyway. The weakness you refer to (can't know that the person you saw is still in control of the key when your enciphered email is received, right?) isn't, I don't think, something that can really be addressed in a disconnected communicant protocol, when it really comes down to it. There'll always be a timing attack. > His requirement that he is already connected to someone before he > signs their key is a little odd, but that's his priviledge. I thought that was rather snide too. But he's a member of the strong set, so maybe he gets a lot of random "could you sign my key so I can join the strong set?" requests. > I'll spare you all a rant on the subject, and content myself with > parsing the above statement: > > "I may sign keys when I have not met the person or verified the > key." > > This is a dreadful, dreadful idea. Remember that the check level > numbers are for human reading - the computer, when building the web of > trust, treats all signatures the same. I don't think he understands that. (I'll admit that I didn't when I first started assigning those values. It's maybe a bit misleading to even have the capability to do that, but it'd be hard to remove it now.) Is there any reason NOT to make strength-of-trust part of the trustdb calculations? (I'm guessing, "What, you were complaining about how long it took to run --check-trustdb just months ago, and now you want me to make it take LONGER?" would be your valid response... ;^>) > People who do this get an automatic "never trust" in my trustdb. Ditto. Not that I trust his key anyway, never having signed it. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgph9SsWhCFbU.pgp
|
|