[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Digital Signature laws


>Subject:  Re: RE: Final Year Thesis : SPKI

Hi Bob.

At 12:32 AM 7/1/98 -0600, Bob Jueneman wrote:
>Oh, well, at least we have fun.  No personal insult intended.

and of course, none intended on my side either.

>I would argue that the Utah and similar laws were really intended to 
>protect and facilitate business to business interchange, including 
>interactions that were not directly financial in nature, such as contracts, 
>amendments, invoices, receipts, etc.

I would agree that that is the intention of such laws.

I would also argue that this is misguided, to say the least.  It seems to be 
a result of lawyers, law makers and companies (CAs) rushing off to implement 
something that was initially just idle speculation by cryptographers in 
technical papers.  There is no reason to believe a cryptographer understands 
business.  I should know :)

What I discovered when I actually started talking to real businesses who do 
real EDI is that there is always a paper contract before people start doing 
purchase orders and shipments of goods.  In that paper contract, there is 
plenty of room to establish one another's keys.  Therefore, for real EDI, 
CAs are irrelevant -- and in fact reduce security by adding a link in the 
process that can go bad.

In the glorious future I see before us, with relationships forming on the 
net rather than in 3D space, there will be some bits-only version of this 
process.  However, that process does not involve a CA and especially not an 
ID certificate.  The use of a name as identifier is limited to small 
communities.  Furthermore, it's not a name businesses care about when 
deciding whether or not to enter into a contract with someone else.  They 
care about past performance, financial stability, quality of products, etc.  
These are facts that can be certified by digital signature, in the bits-only 
world, but the authorities on such facts will not be commercial CAs [unless 
you decide to defend a pre-decided announcement that CAs are necessary and 
so call any of these intermediaries "CAs"].

The details of how business relationships form will be a fascinating study.  
I expect Organizational Behavior students to spend years figuring that out.  
Mapping that to cyberspace will be another interesting challenge.  I can't 
say offhand how it will all turn out, but I have my guesses.  Those guesses 
are flimsy enough that I won't share them on this list.

In short, I see the rush to establishing CAs as an interference in this 
process.  It does not address what really needs to be accomplished.  It 
follows the assumption of a handful of cryptographers (starting with Diffie 
and Hellman) who used improper analogies (the phone book) and claimed that 
with that taken care of, all introduction requirements were fulfilled.  I 
know, they didn't say that explicitly, but that's how people took what was 
said -- and then came this rush to X.500 (that failed), X.509 (that is an 
albatross), Dig Sig laws (that are just waiting to cause trouble and don't 
speak to business needs), commercial CAs (desperate to make money somehow, 
even though the initial product (ID cert) is valueless), ....

It's interesting times.

 - Carl

Version: PGP for Personal Privacy 5.5.3


|Carl M. Ellison       cme@acm.org    http://www.clark.net/pub/cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+-Officer, officer, arrest that man. He's whistling a dirty song.--+
From ???@??? Wed Jul 01 07:16:28 1998
Received: from mail.acm.org (mail.acm.org [])
	by ice.clark.net (8.8.8/8.8.8) with ESMTP id GAA14981
	for <cme@clark.net>; Wed, 1 Jul 1998 06:40:28 -0400 (EDT)
Received: from intra.datafellows.com (intra.datafellows.com []) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA171870 for <cme@acm.org>; Wed, 1 Jul 1998 06:32:25 -0400
Received: from DataFellows.com (dfp100.datafellows.com [])
          by intra.datafellows.com (8.8.5/8.8.4) with ESMTP
	  id NAA14554; Wed, 1 Jul 1998 13:38:30 +0300
Message-ID: <359A11AD.A3969E1@DataFellows.com>
Date: Wed, 01 Jul 1998 13:38:38 +0300
From: "Camillo Särs" <Camillo.Sars@DataFellows.com>
Organization: Data Fellows Ltd.
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: Bob Jueneman <BJUENEMAN@novell.com>
CC: cme@acm.org, spki@c2.net
Subject: Legal aspects of certs (Was: Re: Final Year Thesis : SPKI)
References: <s59983a2.028@novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> But my point was really that that you as an individual, given a 
> reasonably definitive statement of the law (pick Utah, Illinois, or 
> what have you, but not, I would advise, one of the "minimalist' states 
> such as California), and at least you know what the ground rules are, 
> and what your reasonable expectations are.


> Everything can and should stay in balance if everyone understands the 
> rules.

But I think that's the fundamental problem with most X.509-based systems
envisioned today.  Not everyone understands the rules.  As a matter of
fact, the rules themselves are so unclear that they can mean just about
anything.  As Ed Gerk has occasionally pointed out, the usual basic
VeriSign CPSs are so obscure that they are virtually meaningless.

I hold a production-use SET certificate, and for once I actually feel that
the CPS does carry some signifigance.  However, I'd be much more
comfortable if the same policy would be coded in the cert itself in a way
that is *meaningful* to a computer.

> It's like the old adage -- good fences make good neighbors.

Yes, but on the Internet today, I can't even recognize a fence, yet alone
determine who's a good neighbor and who's not.

From ???@??? Wed Jul 01 07:16:30 1998
Received: from mail.acm.org (mail.acm.org [])
	by ice.clark.net (8.8.8/8.8.8) with ESMTP id GAA15887
	for <cme@clark.net>; Wed, 1 Jul 1998 06:44:22 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com []) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA26580 for <cme@acm.org>; Wed, 1 Jul 1998 06:36:19 -0400
Received: by INET-IMC-01 with Internet Mail Service (5.5.2328.0)
	id <N4RY77DX>; Wed, 1 Jul 1998 03:42:33 -0700
Message-ID: <25983782061AD111B0800000F86310FE08A23A23@red-msg-42.dns.microsoft.com>
From: Paul Leyland <pleyland@microsoft.com>
To: "'Bob Jueneman'" <BJUENEMAN@novell.com>, cme@acm.org
Cc: spki@c2.net
Subject: RE: RE: Final Year Thesis : SPKI
Date: Wed, 1 Jul 1998 03:42:32 -0700 
X-Mailer: Internet Mail Service (5.5.2328.0)

The Subject: of this thread really has very little to do with its subject,
but for the sake of continuity...

> But my point was really that that you as an individual, given 
> a reasonably 
> definitive statement of the law (pick Utah, Illinois, or what 
> have you, but not,
> I would advise, one of the "minimalist' states such as 
> California), and at least 
> you know what the ground rules are, and what your reasonable 
> expectations 
> are.

For a British lawyers' professional body's view on what should, should not
and might be in digital signature legislation, I'd recommend taking a look
at http://techpolicy.lse.ac.uk/csrc/sig/lawsoc.html

From ???@??? Wed Jul 01 07:16:37 1998
Received: from mail.acm.org (mail.acm.org [])
	by ice.clark.net (8.8.8/8.8.8) with ESMTP id GAA19296
	for <cme@clark.net>; Wed, 1 Jul 1998 06:57:10 -0400 (EDT)
Received: from blacklodge.c2.net (blacklodge.c2.net []) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA167796; Wed, 1 Jul 1998 06:49:07 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id DAA20353 for spki-outgoing; Wed, 1 Jul 1998 03:45:49 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
X-Mailer: exmh version 1.6.6 3/24/96
To: Ben Laurie <ben@algroup.co.uk>
cc: spki@c2.net
Subject: Re: Final Year Thesis : SPKI
X-PGPKey: www.cs.ucl.ac.uk/staff/F.AbdulRahman/farezpgp.asc
In-reply-to: Your message of "Wed, 01 Jul 1998 09:46:52 BST." <3599F77C.1C97FEB0@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 01 Jul 1998 11:45:40 +0100
Message-ID: <7466.899289940@cs.ucl.ac.uk>
From: Alfarez <F.AbdulRahman@cs.ucl.ac.uk>
Sender: owner-spki@c2.net
Precedence: bulk


> Perhaps we should get back to barter. After all, money is just a token
> for goods, services, etc. Hmmm ... eBarter. Tell you what, for a hundred
> eChickens, I'll give you an eDay of programming :-)

eChickens are kinda rare 'round here parts. hows about a couple of eLlama's 
for that eDay of programming. how do we figure the exchange rate for that?

i remember coming across a paper on ecash and stuff related to minting your 
own ecurrency and exchange rate issues but can't remember it now. does anyone 
know a good paper on the subject?


Dept of Computer Science, University College London