Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site spp2.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!sdcrdcf!trwrb!trwspp!spp2!jhull From: jhull@spp2.UUCP (Jeff Hull) Newsgroups: net.news.stargate Subject: Re: how to verify an article's submitter Message-ID: <439@spp2.UUCP> Date: Mon, 18-Feb-85 16:25:15 EST Article-I.D.: spp2.439 Posted: Mon Feb 18 16:25:15 1985 Date-Received: Sun, 24-Feb-85 02:12:05 EST References: <462@aquila.noao.UUCP> <12022@gatech.UUCP> Reply-To: jhull@spp2.UUCP (Jeff Hull) Organization: TRW, Redondo Beach CA Lines: 45 Summary: In article <12022@gatech.UUCP> spaf@gatech.UUCP (Gene Spafford) writes: >Jay presents a very nice solution to the verfication problem except for >a few problems -- one of which makes it unworkable. > >... First, >Don't put the key in a file, you say? Make me. I can't prevent you from leaving your checkbook lying around with signed but otherwise blank checks in it either. But if I find it, fill one of the checks out & cash it, you have no legal recourse against me. I think the same principle applies here. Second, >Sorry. Digital signature protocols generally assume that (at least) >the identity og the sender or the privacy of the key are a given. >We have a situation where both are not secure. That turns the >situation into one that is much more difficult to deal with. I think we have a slightly different situation that the one Gene envisions. I think the net at large can leave to the individual sites the problem of dealing with individual users at each site. Presumably the security needs of TRW are different than those of someone accessing the net from his home computer. If (the legal eagles think the net/satellite carrier can afford to) set the limit of the net's concern for liability to the originating site & let the site worry about the local user base, then we have a situation where the identity of the originator is known. And system administrators can be required to properly handle encryption keys. (BTW, I envision keys being changed frequently [daily? more often?] and the key files themselves being encrypted a la /etc/passwd. Key updates being passed between sites using keys that are never stored in digital form. etc Complete details on request. If we ever get that far.) The cost of administration is automatically spread around. Each site is concerned only with those sites that feed it. -- Blessed Be, Jeff Hull {decvax,hplabs,ihnp4,scdrdcf,ucbvax} 13817 Yukon Ave. trwrb!trwspp!spp2!jhull Hawthorne, CA 90250