[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Welcome to spki
--
Welcome to the spki mailing list!
Please save this message for future reference. Thank you.
If you ever want to remove yourself from this mailing list,
you can send mail to <Majordomo@c2.net> with the following
command in the body of your email message:
unsubscribe spki cme@acm.org
If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-spki@c2.net> .
This is the general rule for most mailing lists when you need
to contact a human.
Here's the general information for the list you've subscribed to,
in case you don't already have it:
[Last updated on: Thu Feb 22 19:21:15 1996]
The SPKI mailing list exists as a place for discussions by the
proposed Simple Public Key Infrastructure (SPKI) working group of the
Internet Engineering Task Force (IETF).
The group will be meeting as a BOF at the Los Angeles IETF; it is
hoped that it will be approved as an official working group soon
thereafter.
The following is a draft of the proposed charter of the working group:
------------------------------------------------------------
Simple Public Key Infrastructure (SPKI) Working Group (Proposed)
Proposed Charter
Chair
* Perry E. Metzger <perry@piermont.com>
Security Area Director(s):
* Jeffrey Schiller <jis@mit.edu>
Mailing List Information
* General Discussion: spki@c2.org
* To Subscribe: majordomo@c2.org
o In Body: subscribe spki <email address>
* Archive: ftp://TBA/TBA
Description of Working Group
Many Internet protocols and applications which use the Internet employ
public key technology for security purposes and require a public key
infrastructure to manage public keys.
The task of the working group will be to develop Internet standards
for an IETF sponsored public key certificate format, associated
signature and other formats, and key acquisition protocols. The key
certificate format and associated protocols are to be simple to
understand, implement, and use. For purposes of the working group, the
resulting formats and protocols are to be known as the Simple Public
Key Infrastructure, or SPKI.
The SPKI is intended to provide mechanisms to support security in a
wide range of internet applications, including IPSEC protocols like
Photuris and SKIP, encrypted electronic mail and WWW documents,
payment protocols, and any other application which will require the
use of public key certificates and the ability to access them. It is
intended that the Simple Public Key Infrastructure will support a
range of trust models.
Goals and Milestones
Feb 96
Agree on working group charter.
Mar 96
Examine applicable technologies.
First meeting at Los Angeles IETF.
Jun 96
Complete initial specification.
Aug 96
Submit SPKI specifications to IESG for consideration as a
Proposed Standard.
------------------------------------------------------------
From ???@??? Mon Jun 29 20:48:04 1998
X-Persona: <home>
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 TAA05797
for <cme@clark.net>; Mon, 29 Jun 1998 19:01:37 -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 SAA45152; Mon, 29 Jun 1998 18:53:37 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id PAA22813 for spki-outgoing; Mon, 29 Jun 1998 15:49:20 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
From: DoWneR@mail.dma.be
Message-Id: <199806292242.AAA05213@bewoner.dma.be>
To: spki@c2.net
Date: Tue, 30 Jun 1998 00:41:50 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Final Thesis - 2-
Sender: owner-spki@c2.net
Precedence: bulk
Status: O
First of all, I want to thank all of you for all the ideas and the
URLs you gave me. I feel less alone now ;)
About setting objectives , I didn't decide that I wanted to
demonstrate that SPKI was better than X.509.
Let me explain you my thesis more in details.
I have to set up a strategic policy aiming at selling SPKI
certificates. After playing the troubleshooter during some days
(weeks?), I noticed that the main problem with certification was the
lack of understanding of basic concepts like public key
cryptography, digital signature, ...
So, to allow a company to sell its certificates, they first need
to explain in a very simple way what a certificate really is.
So, the first part of my thesis was to simplify those concepts and
to write an "easy-to-read" version of all the concepts around the
certificate. This part is almost over.
Now, I have to try to define what a SPKI certificate is and I have to
look at competitors, i.e. other products able to do the same things
i.e. to ensure that someone (or a company) is who he says he is.
Because I don't have (and I'm not able) to compare all those products
on a technical level, I have to find out concepts that a company
could explain to its client to show them their SPKI certificates are
better e.g. than the X.509 ones.
It is on a commercial level and I have to keep in mind that the
future customers may not understand all the concepts. So, after
reading the first part of my thesis, those customers should normally
(I hope so!?!) feel more confortable with those ideas but I can not
use very technical concepts because everybody should be able to
understand that SPKI is better on the basis of those arguments.
The problem for me being that I don't know if SPKI is better and if
yes, why. You should consider my thesis as a paper to convince people
on the basis of real concepts and arguments that something is better
than something else.
That's it and if you red through all the mail, thank you very much
for your time!!!
Have a nice day and good work
Olivier
___________________________________________________
DELLICOUR Olivier
UCL - IAG - INGE23
Av. de Mai, 272
1200 Brussels
BELGIUM
___________________________________________________
From ???@??? Tue Jun 30 01:11:57 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 BAA07684
for <cme@clark.net>; Tue, 30 Jun 1998 01:10:08 -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 BAA154074; Tue, 30 Jun 1998 01:02:09 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id VAA27773 for spki-outgoing; Mon, 29 Jun 1998 21:47: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.19980630001829.04c56ee8@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 00:18:29 -0400
To: cme@acm.org
From: Carl Ellison <cme@acm.org>
Subject: change of address
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
I am moving from CyberCash.
Until I get the new work account set up in a month or so, please replace
cme@cybercash.com
with
cme@acm.org
Thanks,
Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZhnFJSWoQShp/waEQJYKwCeIDZe9E67VOL2fin2L2unLYJfhCQAnRfL
HFncaiI5a/n/rpBAEO2zgavF
=pU5t
-----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 01:22:01 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 BAA09969
for <cme@clark.net>; Tue, 30 Jun 1998 01:18:51 -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 BAA153994; Tue, 30 Jun 1998 01:10:53 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id WAA27935 for spki-outgoing; Mon, 29 Jun 1998 22:03:14 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-Id: <3.0.3.32.19980630010123.0326ad00@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 01:01:23 -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: <000801bda3a0$df963560$01060606@goedel>
References: <3.0.3.32.19980629134038.0317edd0@mailhost.reston.cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-spki@c2.net
Precedence: bulk
Status: O
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 04:59 PM 6/29/98 -0400, Phillip Hallam-Baker wrote:
>> It's not clear to me that the CPS (+ Utah-like law) approach to
>> building a
>> legal infrastructure is either workable or desirable. That
>> approach tends
>> to violate the spirit of Reg.E. The heavy fine print in a CPS tends to
>> absolve a CA from all responsibility -- far from a useful thing for
>> keyholders.
>
>I have never quite been able to persuade you that the CPS
>is there to define liability precisely and not to avoid it.
I'm convinced and always have been. That's what a CPS does for a living. I
just don't like the way the liability is precisely apportioned.
>The model I think most useful for a CPS is that of an
>insurance contract. The person drafting such a contract
>has to understand that accepting certain forms of liability
>is the function of the CA.
Perhaps I'm struggling under a revulsion in the face of legalese.
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).
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.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNZhxIpSWoQShp/waEQIYhgCfaaBM6mpfkI6B/wZFDJD1GADz21EAoJwx
RoaHR8JVkOsOJ0H8sviqw8rf
=NlHE
-----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 11:01:01 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 KAA17819
for <cme@clark.net>; Tue, 30 Jun 1998 10:40:12 -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 KAA47768; Tue, 30 Jun 1998 10:32:10 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id HAA04581 for spki-outgoing; Tue, 30 Jun 1998 07:27:44 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Reply-To: <hallam@ai.mit.edu>
From: "Phillip Hallam-Baker" <hallam@ai.mit.edu>
To: "Carl Ellison" <cme@acm.org>, <hallam@ai.mit.edu>
Cc: <spki@c2.net>
Subject: RE: Final Year Thesis : SPKI
Date: Tue, 30 Jun 1998 10:25:13 -0400
Message-ID: <000901bda432$e53c5b60$01060606@goedel>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <3.0.3.32.19980630010123.0326ad00@pop3.clark.net>
Sender: owner-spki@c2.net
Precedence: bulk
Status:
> 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?
> 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
From ???@??? Tue Jun 30 11:46:34 1998
Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender
Bob_Geiger-CBG003@email.mot.com )
Sender: Bob Geiger-CBG003 <Bob_Geiger-CBG003@email.mot.com>
Date: Tue, 30 Jun 1998 10:33:09 -0500
From: Bob Geiger <geiger@areaplg2.corp.mot.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/715)
To: Carl Ellison <cme@acm.org>
CC: spki@c2.net
Subject: Re: Final Year Thesis : SPKI
Carl Ellison wrote:
>
>
> Perhaps I'm struggling under a revulsion in the face of legalese.
>
> 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.
>
>
> 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
theycontrol how the key is stored, no? 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).
Bob Geiger
Motorola