1992-11-30 - Secure key exchange

Header Data

From: strat@intercon.com (Bob Stratton)
To: cypherpunks@toad.com
Message Hash: 3371d93c0fe44cc570eeb71fd28c11b17b3936b3ddc1fbe5c00f2e459c78ec9a
Message ID: <9211300930.AA00855@intercon.com>
Reply To: <9211292203.AA17336@servo>
UTC Datetime: 1992-11-30 09:30:00 UTC
Raw Date: Mon, 30 Nov 92 01:30:00 PST

Raw message

From: strat@intercon.com (Bob Stratton)
Date: Mon, 30 Nov 92 01:30:00 PST
To: cypherpunks@toad.com
Subject: Secure key exchange
In-Reply-To: <9211292203.AA17336@servo>
Message-ID: <9211300930.AA00855@intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> On Sun, 29 Nov 92 14:03:25 -0800, karn@qualcomm.com (Phil Karn) said:


	Phil> People need to be very selective about the signatures
	Phil> they sign, otherwise they will become meaningless. I've
	Phil> already had people sign my public key without any
	Phil> verification that it is legit. This is a no-no.  I am
	Phil> bothered by the message that PGP currently generates
	Phil> when it reads in some new public keys asking if you'd
	Phil> like to certify each new key. Even though the default is
	Phil> "no", it makes it too easy to sign a key without really
	Phil> verifying its authenticity.

I have to echo Phil's comments here. One of the things that might be
worth a few minutes is for this group to hash out (pun intended) a set
of guidelines for "when it's o.k. to sign a key". I have been
talking to some people about personal applications of cryptographic
technology, and I'm frequently surprised when even people with a DP
security background want to rush to certify keys they've received via
email, etc. 

I'm thinking something along the lines of "If I'm in a real-time
communications mechanism, and on the phone at the same time, and I
receive their key at the moment when they told me they hit the return
key - then it's probably theirs"...It would be prohibitive to list all
of the possible permutations, but it might go a long way toward
building the right habits if we brainstormed about a few firm
guidelines for the uninitiated as to what constitutes responsible key
management. 

I confess to some personal bias, because I know the PEM folks are
watching to see how robust our key distribution "web" becomes over the
course of its evolution, and I'd like to be able to show them a
convincing argument against centralized key management, empirically...

--Strat







Thread