[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Final Year Thesis : SPKI
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 10:33 AM 6/30/98 -0500, Bob Geiger wrote:
>Carl Ellison wrote:
>> I have yet to see a CPS that specifies that a CA does something *for* me,
>> the keyholder. What I have seen, until my patience with legalese trips
>> out, is a denial of liability by a CA -- and what I see in laws like
>> Utah's is an assignment of liability to the keyholder (e.g., by
>> a presumption of non-repudiation, even when the user is not using a
>> truly secure computing system in a truly secure room).
>
>This seems to be the business model for the "identity" industry right now.
>Witness the poor souls who are the victims of identity stealing and
>literally are held responsible for the easy credit, sloppy accounting, and
>downright criminal negligence of the easy money and credit reporting
>industries. Until these prople get stung by enough big lawsuits they are
>unlikely to change the practice of trying to force all liability onto the
user.
Hmmm. I hadn't thought about preventing this kind of abuse by lawsuit.
That might be more productive than passing laws to make them financially
responsible for the bad decisions they make.
>> For example, does a VeriSign certificate constitute a legal statement by
>> VeriSign that it is co-signing any financial instrument that I, the
>> keyholder, sign with my key? ...or any financial instrument up to $XXX ?
>
>The only way it makes sense for these guys to take on this liability is if
>they control how the key is stored, no?
Yes! Exactly!
They also need to control how it is accessed. This means not only
biometrics for key access, but also truly secure processors and operating
systems, so that no trojan horse code could do a Radar O'Reilly attack.
>For example if they provide key pairs
>generated on a tamper-resistant smart card with passphrase access the
>liability can be evaluated. Biometrics makes it safer. But for a key that I
>have no control over it seems hard to assess risk. It could be done but
>costs would likely be very high given the risk factors, so they are
>providing instead cheaper keys that have little or no protection. Perhaps
>when the technology becomes more accepted for general use the equivalent of
>key insurance will be offered, although I think the whole model of how we
>deal with ID in this country needs serious looking into (which is thankfully
>happening in SDSI/SPKI).
I also think we need to address the meaning of certificates and PK
Authentication if we remove the non-repudiation assumption. If a keyholder
can always and easily repudiate any signature he makes, then what use is PK
Crypto? The answer is that it has many uses.
I don't think that corner of the field has been studied enough.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZkJdJSWoQShp/waEQKj7ACdEdQh1rDnU+X9JS2daD7KvJTuO60AnjAv
Bm8+Pzwaby3GIu7lQZcMK8On
=V12Z
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 ???@??? Tue Jun 30 12:13:07 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id MAA24452
for <cme@clark.net>; Tue, 30 Jun 1998 12:08:07 -0400 (EDT)
Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA23050; Tue, 30 Jun 1998 12:00:04 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id IAA05942 for spki-outgoing; Tue, 30 Jun 1998 08:55:53 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-Id: <3.0.3.32.19980630115418.04c5c4e8@pop3.clark.net>
X-Sender: cme@pop3.clark.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Jun 1998 11:54:18 -0400
To: <hallam@ai.mit.edu>
From: Carl Ellison <cme@acm.org>
Subject: RE: Final Year Thesis : SPKI
Cc: <spki@c2.net>
In-Reply-To: <000901bda432$e53c5b60$01060606@goedel>
References: <3.0.3.32.19980630010123.0326ad00@pop3.clark.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-spki@c2.net
Precedence: bulk
Status:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 10:25 AM 6/30/98 -0400, Phillip Hallam-Baker wrote:
>> I have yet to see a CPS that specifies that a CA does something *for* me,
>> the keyholder. What I have seen, until my patience with legalese trips
>> out, is a denial of liability by a CA -- and what I see in laws like
>> Utah's is an assignment of liability to the keyholder (e.g., by
>> a presumption of non-repudiation, even when the user is not using a
>> truly secure computing system in a truly secure room).
>
>I'm not an expert on the Utah act but I believe the statement is
>rather stronger than the ABA guidelines position of 'it is rebuttably
>asssumed that..' The question is what forms of rebuttal are valid?
IANANL, myself.
>
>> For example, does a VeriSign certificate constitute a legal statement by
>> VeriSign that it is co-signing any financial instrument that I, the
>> keyholder, sign with my key? ...or any financial instrument up to $XXX ?
>
>Not in Class 1 through 3!
Yup. :)
>> A CPS saying that would specify a service that might truly greese
>> the wheels
>> of electronic commerce for people with no prior relationship.
>
>That is essentially what SET does.
Only half.
What SET does is bind a credit card number to a public key. That
certificate is issued, properly, by the authority on that relationship (the
card issuing bank).
The credit extended is via the credit card itself, not via the certificate.
Right?
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZkKKZSWoQShp/waEQJD5ACeOJhUzCsCQQZ9ILAfr7TuDAs4ZFoAoPJr
9nnI1Np1+Lm9T3UtGkIYGD8f
=cXc8
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 ???@??? Tue Jun 30 13:02:06 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id MAA24191
for <cme@clark.net>; Tue, 30 Jun 1998 12:07:43 -0400 (EDT)
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.acm.org (8.8.5/8.7.5) with SMTP id LAA76416 for <cme@acm.org>; Tue, 30 Jun 1998 11:59:38 -0400
Received: from INET-PRV-Message_Server by novell.com
with Novell_GroupWise; Tue, 30 Jun 1998 10:05:51 -0600
Message-Id: <s598b87f.090@novell.com>
X-Mailer: Novell GroupWise 5.2
Date: Tue, 30 Jun 1998 10:05:18 -0600
From: "Bob Jueneman" <BJUENEMAN@novell.com>
To: cme@acm.org, hallam@ai.mit.edu
Cc: spki@c2.net
Subject: Re: RE: Final Year Thesis : SPKI
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_0753A6CF.3D5C4BCA"
Status: RO
>> I have yet to see a CPS that specifies that a CA does something *for* me,
>> the keyholder. What I have seen, until my patience with legalese trips
>> out, is a denial of liability by a CA -- and what I see in laws like
>> Utah's is an assignment of liability to the keyholder (e.g., by
>> a presumption of non-repudiation, even when the user is not using a
>> truly secure computing system in a truly secure room).
Carl, I have to confess that I lose my patience with this kind of whining.
If your system isn't secure enough for the intended purpose, don't use it!
What both the various CPS's and at least the better legislation do for you,
the keyholder, is make it crystal clear what the presumptions and standard
of care that is expected of you.
The purpose of the legislation is NOT to give you or anyone else a free ride,
it is to facilitate commerce. To do this, it is absolutely necessary to balance
both the risks and the rewards of the use of digital signatures between the
CA, the key holder, and the relying party.
If the risks substantially outweigh the rewards for any of the three players
in this scenario, they will simply walk away from the table and refuse to play.
That, of course, is certainly your right, and arguably even your duty,
if for example you feel that your system is not sufficiently secure for the intended
use. Presumably you know better than anyone else.
But as opposed to some legislation, notably the wretched Calfornia act, which
might better be called the attorney's full employment act, the Utah/Illinos/ABA
Guidelines style acts attempt to clearly delineate who is responsible for what.
given a full disclosure of the rules of the road, as either a businessman or consumer,
I can decide for myself whether to take the risk of having a digital signature, or
as a relying party, deciding to accept and believe a digitally signed document.
If I don't think it's a reasonably balanced deal, I'm free to walk away. So are you.
Because the Utah Act only applies to certificates issued by licensed CAs, of
which there are only two so far (to my knowledge), it is reasonably clear that
it was not intended to apply to household or consumer protection act types of
scenarios. But the Illinois act makes this much more explicit, where it states that:
Section 10-130. Attribution of signature.
(a) Except as provided by another applicable rule of law, a secure electronic signature is attributable to the person to whom it correlates, whether or not authorized, if:
(1) the electronic signature resulted from acts of a person that obtained the
signature device or other information necessary to create the signature from
a source under the control of the alleged signer, creating the appearance
that it came from that party;
(2) the access or use occurred under circumstances constituting a failure to
exercise reasonable care by the alleged signer; and
(3) The relying party relied reasonably and in good faith to its detriment on
the apparent source of the electronic record.
(b) The provisions of this Section shall not apply to transactions intended primarily for
personal, family, or household use, or otherwise defined as consumer transactions
by applicable law, including but not limited to, credit card and automated
teller machine transactions, except to the extent allowed by applicable consumer law.
Finally, to take care of the 'grandma is careless with her keys and loses her house"
scenario, note that it is the responsibility of the relying party to apply a "commercially
reasonable" standard of care when deciging to accept a transaction.
If the transaction is to purchase a dishrag, probably no signature at all is required --
a FAXed "X" is probably sufficient. On the other hand, if grandma tries to buy an
oil tanker, or sell her house, using a certificate that only cost $10 to acquire and
therefore is presumably limited in the amount of due diligence that was invested in it by
the CA, never mind grandma's lack of a B3 computer and a FIPS-140-1 level 4
cyptosystem, the relying party who accepts that transaction basesd solely on the digital signature is a fool, and will be laughed out of court.
>I'm not an expert on the Utah act but I believe the statement is
>rather stronger than the ABA guidelines position of 'it is rebuttably
>asssumed that..' The question is what forms of rebuttal are valid?
The Utah Act uses the terminology "presume" without further qualification.
Without knowing more about Utah civil procedure law, I coudln't comment
on their standard for rebutable presumptions.
The Illinois Act, passed recently and awaiting signature by the Governor, is perhaps
a more reasonable reference, since it built on the Utah Act and others, and
takes into account some of the edifferences of opinion in this area. It says:
Section 10-120. Presumptions.
(a) In resolving a civil dispute involving a secure electronic record,
it shall be rebuttably presumed that the electronic record has not been
altered since the specific point in time to which the secure status relates.
(b) In resolving a civil dispute involving a secure electronic signature,
it shall be rebuttably presumed that the secure electronic signature
is the signature of the person to whom it correlates.
(c) The effect of presumptions provided in this Section is to place
on the party challenging the integrity of a secure electronic record or
challenging the genuineness of a secure electronic signature both
the burden of going forward with evidence to rebut the presumption
and the burden of persuading the trier of fact that the nonexistence
of the presumed fact is more probable than its existence.
(d) In the absence of a secure electronic record or a secure electronic
signature, nothing in this Act shall change existing rules regarding
legal or evidentiary rules regarding the burden of proving the authenticity
and integrity of an electronic record or an electronic signature.
>
>
>> For example, does a VeriSign certificate constitute a legal statement by
>> VeriSign that it is co-signing any financial instrument that I, the
>> keyholder, sign with my key? ...or any financial instrument up to $XXX ?
>
>Not in Class 1 through 3!
>
>> A CPS saying that would specify a service that might truly greese
>> the wheels
>> of electronic commerce for people with no prior relationship.
>
>That is essentially what SET does.
>
>
> Phill
>
Vis a vis the issue of rebuttable presumptions and what they mean, I had the pleasure of
having Prof. R. J. Robertson as my coauthor of our law review article "Biometrics and Digital Signatures" which was recently published by Jurimetrics.
I think you will find the first half, laying out the law of written signatures and comparing
them to digital signatures, rather itneresting. I'd also be interested in comments on the
biometrics vs. digital signatures section, inlcuding the risks of both.
bob
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com
"Architects, like prophets and saints, are
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be
right."
Attachment Converted: "C:\EUDORA\ATTACH\Biometrics and Digital Signatures in Electronic Commerce.pdf"
From ???@??? Tue Jun 30 13:03:12 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id MAA29931
for <cme@clark.net>; Tue, 30 Jun 1998 12:57:52 -0400 (EDT)
Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA12170; Tue, 30 Jun 1998 12:49:50 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id JAA06634 for spki-outgoing; Tue, 30 Jun 1998 09:49:01 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
From: "M. T. Hollinger" <myth@ucx.lkg.dec.com>
To: "Carl Ellison" <cme@acm.org>
Cc: <spki@c2.net>
Subject: Re: Final Year Thesis : SPKI
Date: Tue, 30 Jun 1998 12:43:24 -0400
Message-ID: <01bda446$32a6cc60$cf501410@BigBrain.ucx.lkg.dec.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: owner-spki@c2.net
Precedence: bulk
Status:
>For example, does a VeriSign certificate constitute a legal statement by
>VeriSign that it is co-signing any financial instrument that I, the
>keyholder, sign with my key? ...or any financial instrument up to $XXX ?
>...
>A CPS saying that would specify a service that might truly greese the
wheels
>of electronic commerce for people with no prior relationship.
>
>Of course, I'm inclined to see credit card companies and banks in that
role,
>effectively loaning money to the keyholder.
Huh? I find it difficult to understand why, in this age of ever more
ubiquitous connectivity, credit card companies and banks would take a step
backward and just guarantee any financial instrument up to a particular
dollar amount.
In order for my credit card to be useful to me online, I have to be able
to use it to buy stuff like computers, or plane tickets. So the
authorized dollar amount for a typical consumer would need to be at least,
say, $2500.
Now, someone steals my smart card, breaks into my computer, or otherwise
compromises my private key and begins to order merchandise. At $2500 a
pop, it would be easy to run up a tab in the hundreds of thousands of
dollars. Even with a $5 limit, some clever person could write a script to
place thousands of long-shot bets at offshore casinos and transfer the
proceeds from those which paid off before anyone detected the theft.
This is why banks and credit card companies today perform online
verification, rather than relying upon some sort of certificate (paper or
cryptographic) guaranteeing all transactions below a given threshold.
With online validation, I can get by with a $5000 credit limit and the
bank's per-loss liability is at least an order of magnitude lower.
Moreover, the bank's liability ends immediately when I report the key/card
compromised.
In order to get that with payment gurantee certificates, the vendor would
have to check the bank's CRL at the time of each transaction -- but then,
why not just just validate the transaction online? It's not particularly
faster or easier to ask Citibank to confirm that certificate X hasn't been
revoked than it is to ask Citibank to authorize a transaction for $9.43.
Or are you talking only about microcent transactions, where the
per-transaction threshold is so low that it wouldn't justify the cost of
real-time validation nor be particularly profitable for someone to steal a
key? Certificates might well have a role in that context, although with
networks getting faster and cheaper all the time, the CPU cost of parsing
and cryptographically verifying a certificate chain is in some cases
comparable to the cost of a network round-trip for online confirmation.
- Mark
From ???@??? Tue Jun 30 17:35:02 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id RAA25887
for <cme@clark.net>; Tue, 30 Jun 1998 17:36:18 -0400 (EDT)
Received: from ice.clark.net (ice.clark.net [168.143.0.12]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA170592 for <cme@acm.org>; Tue, 30 Jun 1998 17:28:16 -0400
Received: from carltecra (cme.clark.net [168.143.8.144])
by ice.clark.net (8.8.8/8.8.8) with SMTP id RAA25783;
Tue, 30 Jun 1998 17:36:07 -0400 (EDT)
Message-Id: <3.0.3.32.19980630160653.03249cb0@pop3.clark.net>
X-Sender: cme@pop3.clark.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Jun 1998 16:06:53 -0400
To: "Bob Jueneman" <BJUENEMAN@novell.com>
From: Carl Ellison <cme@acm.org>
Subject: Re: RE: Final Year Thesis : SPKI
Cc: cme@acm.org, hallam@ai.mit.edu, spki@c2.net
In-Reply-To: <s598b87f.090@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 10:05 AM 6/30/98 -0600, Bob Jueneman wrote:
>Carl, I have to confess that I lose my patience with this kind of whining.
>If your system isn't secure enough for the intended purpose, don't use it!
Bob,
I'm sorry you hear this as whining.
My system is secure enough for me, for the moment, and I work to make it
more secure.
Specifically, it's secure enough for *my* intended purpose. It's just not
secure enough for the Utah law's or even ABA-ISC's intended purpose.
I don't intend to achieve non-repudiation. Under those rules, I'm fine
with what I have. So are MasterCard, VISA and AMEX -- so I can get purchases
done. I have no intention of signing or accepting contracts (like buying a
house, for example) over the net based on anything loose like the Utah law,
so that's no problem. I can envision a full EDI solution, electronic
checking, etc., all without the non-repudiation assumption, so frankly I
don't see any reason to expand my intended purpose.
Meanwhile, thanks for the file and the rest of your message. I haven't
read them yet, but wanted to reply to this opening shot in your mail while
the mood was hot.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZlFXJSWoQShp/waEQIGHgCfejNDVWcsQvPlGGsuNV8KKJp9n8sAnjox
PDpkpw6ZUpwP6KQOvu65Ms7q
=Jo9e
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 ???@??? Tue Jun 30 17:35:03 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id RAA25997
for <cme@clark.net>; Tue, 30 Jun 1998 17:36:28 -0400 (EDT)
Received: from ice.clark.net (ice.clark.net [168.143.0.12]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA14734 for <cme@acm.org>; Tue, 30 Jun 1998 17:28:26 -0400
Received: from carltecra (cme.clark.net [168.143.8.144])
by ice.clark.net (8.8.8/8.8.8) with SMTP id RAA25859;
Tue, 30 Jun 1998 17:36:14 -0400 (EDT)
Message-Id: <3.0.3.32.19980630162800.03249cb0@pop3.clark.net>
X-Sender: cme@pop3.clark.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Jun 1998 16:28:00 -0400
To: "Bob Jueneman" <BJUENEMAN@novell.com>
From: Carl Ellison <cme@acm.org>
Subject: Re: RE: Final Year Thesis : SPKI
Cc: cme@acm.org, hallam@ai.mit.edu, spki@c2.net
In-Reply-To: <s598b87f.090@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 10:05 AM 6/30/98 -0600, Bob Jueneman wrote:
>What both the various CPS's and at least the better legislation do for you,
>the keyholder, is make it crystal clear what the presumptions and standard
>of care that is expected of you.
This might be clear to me, even though IANAL, because I've spent much time
in crypto and security and system development. I don't expect it to be
crystal clear to grandma who is in risk of losing her house.
It may take a test case or a dozen in which it is shown that the Internet
has two classes of users -- the 0.001% who understand security enough to
make a rational decision about their ability to protect private keys and
who, as a result, refuse to accept certificates from any CA blessed by such
a state law as Utah's -- and the remaining 99.999% who are not competent to
evaluate their own security and who might therefore accept such a certificate.
If the law in question assigns responsibility to the keyholder in that
99.999% case, then the law is faulty and needs to be struck down. If the
law assigns responsibility to the merchant, then any merchant who accepts
such a certificate is a fool. The problem is that the underlying model is
flawed. Legalese doesn't make the flaws go away.
>The purpose of the legislation is NOT to give you or anyone else a free ride,
>it is to facilitate commerce. To do this, it is absolutely necessary to
balance
>both the risks and the rewards of the use of digital signatures between the
>CA, the key holder, and the relying party.
I contest the claim that in order to facilitate commerce it is necessary
even to have a CA, much less to do anything in law to consider the risks and
rewards a CA might face.
I agree that there is much to be done before we have commerce in cyberspace
as fully as we have it in 3D space, but I don't believe CAs and identity
certificates are *the* necessary step. There is even a strong case that CAs
and ID certs are not *a* necessary step.
In whatever evolves from this work that needs to be done, there will
doubtless be parties serving as intermediaries. Today, for grandma betting
her house, it's VISA and compatriots. You might end up calling that set of
intermediaries "CAs", if you're bent on proving the necessity of CAs, and
any document they issue you might declare an "ID cert", but I believe there
will be more direct explanations, borrowing from the history of current EDI
practice.
The rest of this topic probably deserves a paper, so I'll spare the list the
resulting long e-mail.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZlKT5SWoQShp/waEQIOPgCgqVRXSnUrZyn4ni6ygtjSXLvpKIoAn13S
2M+nCP2YyazIW7mZuSBQaWSc
=Y0rB
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 ???@??? Tue Jun 30 17:38:43 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id RAA28042
for <cme@clark.net>; Tue, 30 Jun 1998 17:39:41 -0400 (EDT)
Received: from ice.clark.net (ice.clark.net [168.143.0.12]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA162730 for <cme@acm.org>; Tue, 30 Jun 1998 17:31:39 -0400
Received: from carltecra (cme.clark.net [168.143.8.144])
by ice.clark.net (8.8.8/8.8.8) with SMTP id RAA25961;
Tue, 30 Jun 1998 17:36:25 -0400 (EDT)
Message-Id: <3.0.3.32.19980630163259.03249cb0@pop3.clark.net>
X-Sender: cme@pop3.clark.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 30 Jun 1998 16:32:59 -0400
To: "M. T. Hollinger" <myth@ucx.lkg.dec.com>
From: Carl Ellison <cme@acm.org>
Subject: Re: Final Year Thesis : SPKI
Cc: "Carl Ellison" <cme@acm.org>, <spki@c2.net>
In-Reply-To: <01bda446$32a6cc60$cf501410@BigBrain.ucx.lkg.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 12:43 PM 6/30/98 -0400, M. T. Hollinger wrote:
>Huh? I find it difficult to understand why, in this age of ever more
>ubiquitous connectivity, credit card companies and banks would take a step
>backward and just guarantee any financial instrument up to a particular
>dollar amount.
[they would use on-line authentication and a cumulative credit limit]
You're right. I would expect any bank or credit card company to use on-line
tests and a credit-balance function. By analogy, any CA issuing a co-signer
cert should probably do the same. Of course, I don't expect to see CAs
issue co-signer certs any time soon.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZlLepSWoQShp/waEQKE1QCdHYtu4MMCNlFzaIx7XaALTWU3OHkAoOH7
xB2ACvIv4osxjT/8am9NLqJH
=/NqV
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 05:35:19 1998
Received: from mail.acm.org (mail.acm.org [199.222.69.4])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id BAA20164
for <cme@clark.net>; Wed, 1 Jul 1998 01:03:34 -0400 (EDT)
Received: from dfw-ix4.ix.netcom.com (dfw-ix4.ix.netcom.com [206.214.98.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id AAA45360 for <cme@acm.org>; Wed, 1 Jul 1998 00:55:32 -0400
Received: (from smap@localhost)
by dfw-ix4.ix.netcom.com (8.8.4/8.8.4)
id AAA29133; Wed, 1 Jul 1998 00:01:36 -0500 (CDT)
Received: from sjc-ca4-17.ix.netcom.com(207.94.249.145) by dfw-ix4.ix.netcom.com via smap (V1.3)
id rma028734; Wed Jul 1 00:00:18 1998
X-Sender: frantz@netcom5.netcom.com
Message-Id: <v03110795b1bf7de5942c@[207.94.249.99]>
In-Reply-To: <3.0.3.32.19980630162800.03249cb0@pop3.clark.net>
References: <s598b87f.090@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 30 Jun 1998 22:02:00 -0800
To: Carl Ellison <cme@acm.org>, "Bob Jueneman" <BJUENEMAN@novell.com>
From: Bill Frantz <frantz@netcom.com>
Subject: Re: RE: Final Year Thesis : SPKI
Cc: cme@acm.org, hallam@ai.mit.edu, spki@c2.net
Status: O
At 12:28 PM -0800 6/30/98, Carl Ellison wrote:
>If the law in question assigns responsibility to the keyholder in that
>99.999% case, then the law is faulty and needs to be struck down. If the
>law assigns responsibility to the merchant, then any merchant who accepts
>such a certificate is a fool. The problem is that the underlying model is
>flawed. Legalese doesn't make the flaws go away.
>
>...
>
>In whatever evolves from this work that needs to be done, there will
>doubtless be parties serving as intermediaries. Today, for grandma betting
>her house, it's VISA and compatriots. You might end up calling that set of
>intermediaries "CAs", if you're bent on proving the necessity of CAs, and
>any document they issue you might declare an "ID cert", but I believe there
>will be more direct explanations, borrowing from the history of current EDI
>practice.
I enjoyed reading this discussion after reading the following in the June
30, 1998 San Francisco Chronicle (pageA3), "Juvenile Pleads Guilty In AOL
Hacker Case -- New York -- An unidentified juvenile computer hacker pleaded
guilty yesterday to stealing the passwords of more than 500 America Online
Inc. users by using a computer program that recorded the keystrokes of AOL
users.
"The defendant sent e-mail to AOL subscribers, concealing a "Trojan Horse"
hacker program that recorded their passwords as they downloaded
innocuous-looking files he attached to the e-mail, the charges said."
Given that a kid can mount this kind of attack, any law which assumes
average people can protect their computer data from hostile attack will be
tried on the front pages of the newspapers the first time grandma loses her
house. I suspect that businesses that are closely identified with the law
will also have their problems. We professionals will be attacked for
failure to warn.
-------------------------------------------------------------------------
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting
(408)356-8506 | lock, then love must be | 16345 Englewood Ave.
frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA