EU DIRECTIVE ON SIGNATURES

Sun, 23 Aug 1998 10:16:48 -0500

-----BEGIN PGP SIGNED MESSAGE-----

In <3.0.3.32.19980822075159.032eca98@spiritone.com>, on 08/22/98 
   at 09:51 AM, Carl Ellison <cme@acm.org> said:

>	The first question identifies the contents of the certificate and the 
>second question identifies the certificate issuer.  In the SET cardholder
> case, for example, the issuer must be the bank that issued the credit
>card  in question.

SET is not the best of protocols to use as an example. It's design has
been heavily influenced by the NSA to meet *their* needs.

>	From this process, in all protocols we've been able to analyze, *none*
>has  produced a need for a globally unique name as the thing in the
>certificate  and none of the issuers have turned out to be commercial
>CAs.

These are 2 important issues:

In most day to day transactions there is *no* need for the seller to know
who I am.

The design of having a few uber-CA's that can satisfy all the needs of the
e-comm world is plain silly. I have long advocated the position of every
man is his own CA and his certificate is his identity. This certificate
contains no information about the holder but is just a link back to a
database of the issuer.

So lets take this concept to Credit Card transactions:

John Doe generates a public key pair and has it signed by his bank that
issues Visa's (your certificate).

Visa requires all kinds of personal information (name, address,
employment, credit history ...ect). All this information goes into the
banks database and is cross-linked to the cert id.

Now John Doe want's to make some purchases on-line with his new credit:

John goes to Widgets Inc. and orders 20 of the deluxe widgets for $50 and
want's to pay for it with Visa. 

Widgets Inc. sends John a form with a list of information that they will
request from Visa to put the transaction through.

John signs this form and returns it to Widgets Inc.

Widget Inc. sends this form to Visa who then verify the sig, looks up the
data in their data base and returns the info to Widget Inc.

Widget Inc. examines the data and if all is acceptable they approve the
transaction.

Part of the flaw of several certificate designs is putting volatile data
into the cert or putting personal data that need not be included in the
cert (and thus having it exposed on every transaction).

By making the cert only a link to a database record we provide the best of
both worlds. The data about John Doe is released only if John Doe approves
it's release. The Merchant, Widget Inc. gets real time information needed
to process the transaction.

>	There will be a need to control some certificate issuers -- perhaps to 
>license them -- but as long as you define them as having the function of 
>binding a name string to a key, you're missing the point.

I disagree here. There is *no* reason for government
intervention/regulation of CA's other than it's traditional role as
mediator of contract disputes. In my above example the merchant, Widget
Inc., will have entered into a contract with Visa outlining the rules and
policies for on-line transactions. The customer will also have entered
into a contract with Visa regarding the rules and policies for on-line
transactions. No need for *any* government intervention unless one of the
parties violates their contracts, and then this would be a matter for the
civil courts. There would be the issues of fraud and theft but as with the
contract violations, there are traditional remedies for this that CA's and
e-comm bring nothing new to the table.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------

Tag-O-Matic: Windows: The Gates of hell.