[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
no spki meeting in Chicago
Because the next IETF meeting conflicts with CRYPTO '98 -- and hence
poses a serious conflict for several crucial members of the working
group -- we will not be meeting in Chicago. Some new drafts are in
progress; these will be announced on the mailing list as usual.
From ???@??? Thu Jul 02 08:44:04 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 EAA13777
for <cme@clark.net>; Thu, 2 Jul 1998 04:36:46 -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 EAA36172; Thu, 2 Jul 1998 04:28:42 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id BAA03745 for spki-outgoing; Thu, 2 Jul 1998 01:19:30 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <25983782061AD111B0800000F86310FE08A23A29@red-msg-42.dns.microsoft.com>
From: Paul Leyland <pleyland@microsoft.com>
To: "'Carl Ellison'" <cme@acm.org>
Cc: "'spki@c2.net'" <spki@c2.net>
Subject: RE: http://techpolicy.lse.ac.uk/csrc/sig/lawsoc.html
Date: Thu, 2 Jul 1998 01:18:56 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Sender: owner-spki@c2.net
Precedence: bulk
Status:
> From: Carl Ellison [mailto:cme@acm.org]
...
> At 03:42 AM 7/1/98 -0700, Paul Leyland wrote:
> >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
>
> Paul,
>
> this is a wonderful paper. How was it received?
That's an ambiguous question. I received it in a mail sent by Nicholas Bohm
to UKcrypto. Somehow, I don't think that's what you meant 8-)
The other interpretation is: what did the community think of the paper? I
can't really answer that one. I like it, as it tallies with my views. Much
the same paper was presented at the Scrambling for Safety conference in
London a month ago. Judging by the questions and comments from the
audience, I'd say many people present also liked it. On the other hand, the
Department of Trade and Industry are proposing legislation which seems to be
largely irrelevant and unnecessary if the lawyers are right. On the third
hand, the legal systems in many European countries differ significantly to
British law, and the DTI's approach may be needed for consistent Europe-wide
applicability. IANAL.
Paul
From ???@??? Thu Jul 02 08:44: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 EAA10600
for <cme@clark.net>; Thu, 2 Jul 1998 04:20:45 -0400 (EDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id EAA21646 for <cme@acm.org>; Thu, 2 Jul 1998 04:12:41 -0400
Received: by INET-IMC-05 with Internet Mail Service (5.5.2328.0)
id <3B28W7X1>; Thu, 2 Jul 1998 01:18:58 -0700
Message-ID: <25983782061AD111B0800000F86310FE08A23A29@red-msg-42.dns.microsoft.com>
From: Paul Leyland <pleyland@microsoft.com>
To: "'Carl Ellison'" <cme@acm.org>
Cc: "'spki@c2.net'" <spki@c2.net>
Subject: RE: http://techpolicy.lse.ac.uk/csrc/sig/lawsoc.html
Date: Thu, 2 Jul 1998 01:18:56 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Status:
> From: Carl Ellison [mailto:cme@acm.org]
...
> At 03:42 AM 7/1/98 -0700, Paul Leyland wrote:
> >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
>
> Paul,
>
> this is a wonderful paper. How was it received?
That's an ambiguous question. I received it in a mail sent by Nicholas Bohm
to UKcrypto. Somehow, I don't think that's what you meant 8-)
The other interpretation is: what did the community think of the paper? I
can't really answer that one. I like it, as it tallies with my views. Much
the same paper was presented at the Scrambling for Safety conference in
London a month ago. Judging by the questions and comments from the
audience, I'd say many people present also liked it. On the other hand, the
Department of Trade and Industry are proposing legislation which seems to be
largely irrelevant and unnecessary if the lawyers are right. On the third
hand, the legal systems in many European countries differ significantly to
British law, and the DTI's approach may be needed for consistent Europe-wide
applicability. IANAL.
Paul
From ???@??? Thu Jul 02 08:44:04 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 EAA13643
for <cme@clark.net>; Thu, 2 Jul 1998 04:36:09 -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 EAA53532; Thu, 2 Jul 1998 04:28:04 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id BAA03772 for spki-outgoing; Thu, 2 Jul 1998 01:22:52 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <25983782061AD111B0800000F86310FE08A23A2A@red-msg-42.dns.microsoft.com>
From: Paul Leyland <pleyland@microsoft.com>
To: "'Bob Jueneman'" <BJUENEMAN@novell.com>
Cc: "'spki@c2.net'" <spki@c2.net>
Subject: RE: RE: RE: Final Year Thesis : SPKI
Date: Thu, 2 Jul 1998 01:22:19 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Sender: owner-spki@c2.net
Precedence: bulk
Status:
> Interesting, and reflective of some approaches being taking
> or espoused in the US.
> But for an opposing view, look at the German digital
> signature legislation.
> Laws that are actually passed and implemented count for more
> than pontificating by
> learned societies and individuals (myself included).
To some extent I agree with you. However, I also take the view that it's
more cost-effective to debug an implementation (in this case a law) before
release than to patch it afterwards. Given that digital signature
legislation is not yet widely fielded, the Law Society's contribution would
seem to be valuable debugging.
Paul
From ???@??? Thu Jul 02 08:44:15 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 HAA17189
for <cme@clark.net>; Thu, 2 Jul 1998 07:09:06 -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 HAA172704; Thu, 2 Jul 1998 07:01:01 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id EAA05465 for spki-outgoing; Thu, 2 Jul 1998 04:00:29 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <359B682A.5C56C43D@DataFellows.com>
Date: Thu, 02 Jul 1998 13:59:54 +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: spki@c2.net
CC: Carl Ellison <cme@acm.org>
Subject: Re: Digital Signature laws
References: <3.0.3.32.19980701063827.0337d8c8@pop3.clark.net> <3.0.3.32.19980701174524.032fa698@pop3.clark.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-spki@c2.net
Precedence: bulk
Status:
Carl Ellison wrote:
> Meanwhile, VeriSign isn't the authority on any of the pieces of
> information I care about.
>
> One piece I care about is the binding between keyholder and any logo
> on the page -- e.g., a trademark. The authority on that information
> is the USPTO or some state trademark office.
I brought up SET once in this context, and I still thinks it warrants some
thought. Now, you are right about what you might want to care about when
doing some browsing/shopping. However, with SET, I found that some of the
X.509 deficiencies are addressed.
* The CPS is actually part of my contract with the credit card issuer.
Thus, I can trust it in "meatspace" (great word, BTW, love it) and
inherently trust it in cyberspace. This relation can be debated,
but let's disregard the argument for now.
* When I initiate a SET transaction (not that I have, yet), the
transaction itself meets some important criteria. I know that
the other party is SET certfied [authorization]. I know what to
do if defrauded [subpoena certificate]. And I know that my
credit card information is safe [confidentiality].
However, my first thought when I really saw this in action was "How nice, I
could have done that much easier with SPKI". Disregarding about a billion
technical differences, I think that SET is a (good?) example of what SPKI
eventually will/might be.
> The main piece I care about is the company's business practice
> summary: its reputation. I know of no authority on that, except word
> of mouth from satisfied customers.
In SET, I have indirect access to this authority. *Certified* by the fact
that the company has a SET certificate. If enough customers yell fraud,
the company will have it certificate revoked and get hit with enough
lawsuits to keep it busy for the next decade or so.
Now that I've praised SET for a while, I think some criticism is in order.
The transfer of trust from "meatspace" to cyberspace mirrors existing
meatspace structures. It may be a straightforward solution, but I don't
think it is the best solution. Businesses adjust their trust and
authorization networks according to the situation at hand. I believe the
same should be done when business enters cyberspace. Duplicating old
structures will only get you that far.
Regards,
Camillo
--
Camillo Särs <Camillo.Sars@DataFellows.com> Data Fellows Ltd.
http://www.Europe.DataFellows.com/ Aim for the impossible and you
http://www.iki.fi/ged will achieve the improbable
From ???@??? Thu Jul 02 08:44:14 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 HAA15305
for <cme@clark.net>; Thu, 2 Jul 1998 07:02:10 -0400 (EDT)
Received: from intra.datafellows.com (intra.datafellows.com [194.197.29.10]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA172574 for <cme@acm.org>; Thu, 2 Jul 1998 06:54:05 -0400
Received: from DataFellows.com (dfp100.datafellows.com [194.197.29.149])
by intra.datafellows.com (8.8.5/8.8.4) with ESMTP
id NAA10079; Thu, 2 Jul 1998 13:59:47 +0300
Message-ID: <359B682A.5C56C43D@DataFellows.com>
Date: Thu, 02 Jul 1998 13:59:54 +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: spki@c2.net
CC: Carl Ellison <cme@acm.org>
Subject: Re: Digital Signature laws
References: <3.0.3.32.19980701063827.0337d8c8@pop3.clark.net> <3.0.3.32.19980701174524.032fa698@pop3.clark.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Status:
Carl Ellison wrote:
> Meanwhile, VeriSign isn't the authority on any of the pieces of
> information I care about.
>
> One piece I care about is the binding between keyholder and any logo
> on the page -- e.g., a trademark. The authority on that information
> is the USPTO or some state trademark office.
I brought up SET once in this context, and I still thinks it warrants some
thought. Now, you are right about what you might want to care about when
doing some browsing/shopping. However, with SET, I found that some of the
X.509 deficiencies are addressed.
* The CPS is actually part of my contract with the credit card issuer.
Thus, I can trust it in "meatspace" (great word, BTW, love it) and
inherently trust it in cyberspace. This relation can be debated,
but let's disregard the argument for now.
* When I initiate a SET transaction (not that I have, yet), the
transaction itself meets some important criteria. I know that
the other party is SET certfied [authorization]. I know what to
do if defrauded [subpoena certificate]. And I know that my
credit card information is safe [confidentiality].
However, my first thought when I really saw this in action was "How nice, I
could have done that much easier with SPKI". Disregarding about a billion
technical differences, I think that SET is a (good?) example of what SPKI
eventually will/might be.
> The main piece I care about is the company's business practice
> summary: its reputation. I know of no authority on that, except word
> of mouth from satisfied customers.
In SET, I have indirect access to this authority. *Certified* by the fact
that the company has a SET certificate. If enough customers yell fraud,
the company will have it certificate revoked and get hit with enough
lawsuits to keep it busy for the next decade or so.
Now that I've praised SET for a while, I think some criticism is in order.
The transfer of trust from "meatspace" to cyberspace mirrors existing
meatspace structures. It may be a straightforward solution, but I don't
think it is the best solution. Businesses adjust their trust and
authorization networks according to the situation at hand. I believe the
same should be done when business enters cyberspace. Duplicating old
structures will only get you that far.
Regards,
Camillo
--
Camillo Särs <Camillo.Sars@DataFellows.com> Data Fellows Ltd.
http://www.Europe.DataFellows.com/ Aim for the impossible and you
http://www.iki.fi/ged will achieve the improbable
From ???@??? Thu Jul 02 08:44:18 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 HAA21373
for <cme@clark.net>; Thu, 2 Jul 1998 07:24:10 -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 HAA167716; Thu, 2 Jul 1998 07:16:05 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id EAA05628 for spki-outgoing; Thu, 2 Jul 1998 04:16:32 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <359B6BEF.88A653A4@DataFellows.com>
Date: Thu, 02 Jul 1998 14:15:59 +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>, spki@c2.net
Subject: Re: Legal aspects of certs (Was: Re: Final Year Thesis : SPKI)
References: <s59a05c9.037@novell.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-spki@c2.net
Precedence: bulk
Status:
Bob,
Bob Jueneman wrote:
> >>>> "Camillo S (FÓrs" <Camillo.Sars@DataFellows.com> 07/01 4:38 AM
[That's a new way of spelling my name. I've seen a few. :-)]
> > [...] 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.
>
> He's not the only one. I've made a few jokes about 80 pages of
> legalese myself. But frankly, when I start to think about how I would
> write a CPS to protect Novell if we were to start issuing
> certificates, all the saame thoughts and concerns pop up.
Of course they do. And as I understand it, the US way of justice makes all
the nitty-gritty detail very important. I'm not at all challenging the
fact that X.509 CA structures seem to require complex CPSs. I'm trying to
challenge the X.509 CA structures *because* they require complex CPSs to
use certificates.
> Eventually, most of this stuff will be covered as background
> boilerplate by regs such as the UCC. Can you imagine what a UPS
> shipping contract would be if such basic terms as FOB had to be
> spelled out in detail?
You're definitely right. But I (and some others, including Carl) seem to
believe that you can do without much of that legalese in the certificate
structure itself. Keeping the legal details out of the system seems
reasonable. Instead, implement a system where authorization semantics are
encoded in the certificates and the legal interpretations simply focus on
the legalese defining those authorizations.
Seems to make sense to me.
> When was the last time you actually read the fine print ont he back of
> your car rental contract, or even read your car or house insurance
> policy?
I'm probably the wrong person to ask, because I make policy of reading
everything I sign. Except for the cases where I know that the thing I sign
is not the thing I will challenge in case of dispute. But law in Finland
is different from law in the US. At least it used to be.
> We'll get there, but it won't be quite as fast a trip as we might
> like.
What's the rush? Some of the more technology-oriented authorities in
Finland are already rolling out X.509-based systems. In most cases they
have even had enlightened people giving advice, so they are fairly nice
from a privacy point of view. I wouldn't trust that trend to hold
world-wide. Especially if we rush into things.
Regards,
Camillo
--
Camillo Särs <Camillo.Sars@DataFellows.com> Data Fellows Ltd.
http://www.Europe.DataFellows.com/ Aim for the impossible and you
http://www.iki.fi/ged will achieve the improbable
From ???@??? Thu Jul 02 14:51:11 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 KAA28839
for <cme@clark.net>; Thu, 2 Jul 1998 10:19:47 -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 KAA09596; Thu, 2 Jul 1998 10:11:41 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id GAA07161 for spki-outgoing; Thu, 2 Jul 1998 06:44:10 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
From: Lynn.Wheeler@firstdata.com
X-Lotus-FromDomain: FDC
To: "Camillo Sõrs" <Camillo.Sars@DataFellows.com>
cc: spki@c2.net, Carl Ellison <cme@acm.org>
Message-ID: <88256635.004ABCE8.00@lnsunr02.firstdata.com>
Date: Thu, 2 Jul 1998 06:41:03 -0700
Subject: Re: Digital Signature laws
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-spki@c2.net
Precedence: bulk
Status:
for another way of doing account-based financial transactions
see X9.59 .... there is a mapping of X9.59 to credit-card (ISO 8583)
flow at http://www.garlic.com/~lynn/ ... as well as great deal of
discussion of digital signature infrastructure backing it up.
The ISO 8583 review is also working on adding the X9.59
field to the international standard (x9.59 hasn't yet been
presented to ISO ... but the requirement for the x9.59 field in
8583 revision has been presented). Also, in the X9.15 (POS)
review, X9.59 field requirement is also presented.
At the moment this is the only work on account-based
standard for financial transaction.