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

RE: RE: RE: Final Year Thesis : SPKI




>> 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).

True, but you can count with negative numbers as well as positive ones.
Legislators seldom have a deep understanding of either technical issues
or of the implications of policies they write, and premature legislation
tends to favor one particular set of interests rather than letting a 
market develop, because it's usually pushed by somebody with either
an agenda (bad) or a Good Idea (often worse :-).  Some legislation,
like Massachusetts', is deliberately minimalist, and does little more
than specify that digital signatures aren't illegal - this is good.
Other legislation makes assumptions about the business relationships
between various players, or about the semantics of signatures, and 
SPKI in particular can be affected, since it assumes more general semantics
rather than the "Key Specifies True Name" model.


At 01:22 AM 7/2/98 -0700, Paul Leyland wrote:
>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.

On the other hand, while I strongly agree with the Axes it's grinding
about Key Escrow/Recovery/Surrender/etc., it is clearly grinding them.

				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639
From ???@??? Wed Jul 15 01:36: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 AAA29985
	for <cme@clark.net>; Wed, 15 Jul 1998 00:33: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 AAA27954; Wed, 15 Jul 1998 00:24:33 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id VAA19206 for spki-outgoing; Tue, 14 Jul 1998 21:15:47 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <D1A949D4508DD1119C8100400533BEDC04CAB8@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'spki@c2.net'" <spki@c2.net>
Subject: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Wed, 15 Jul 1998 13:58:40 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-spki@c2.net
Precedence: bulk
Status:   


> Dear All -
> 
> In light of the work on security re authentication, access controls
> and TLS and SASL, etc I thought I would comment on this doc on this
> list and the LDAPext list  - as it could affect the work - Badly
> 
> <draft-ietf-spki-cert-theory-02.txt> - note its theory....
> 
> .
> 
> Item 1 the text of the document
> 
> "2.2 The X.500 dream and its failure"
> 
>  It was approximately ten years after Kohnfelder that the X.500
>  proposal took form in the ISO.  X.500 was to be a global, distributed
> database of named entities: people, computers, printers, etc.  In
> other words, it was to be a global, on-line telephone book.  The
> organizations owning some portion of the name space would maintain
> that portion and possibly even provide the computers on which it was
> stored.  To record the permission to modify nodes in this global name
> space X.509 certificates were defined.  An X.509 certificate bound a
> so-called distinguished name to a public key.  The distinguished name
> was a path in the X.500 database, identifying a node in that database.
> 
> It is now obvious that the X.500 dream can not succeed.
> 
> ((Alan: One cannot see what one does not recognise - De Bono - the art
> of lateral thinking" ))
>   
> The designers had overlooked the fact that organizations consider
> their name spaces (e.g., their employee lists) to be confidential.
> For example, does anyone really believe that the CIA will put its
> employee list up on the web, in the form of a globally accessibleX.500
> database?  Will IBM?
> 
> Alan - Comment:
> On this section may I suggest the Authors revisit the role of X.500
> and assume X.500 is about distributed, object oriented name based
> transaction systems. I will be happy to provide documents, workshop
> material and presentations if required. 
> 
> It seems totally illogical to make a statement eg.  that because the
> CIA don't publish all its employee list that X.500 wont work and has
> failed.
> 
> This is like saying that because some Defence organisations write down
> Top Secret orders with pen and paper - on some pieces of paper and
> keep them private - within the whole world that runs on paper - that
> the worlds Books and News papers don't work, should not be written, be
> published or read....
> 
> Logic - wherefore art thou ?
> 
> 
> 
> 
> NEXT
> Item 2 the text of the document
> 
> "4.1.2 SPKI global identifiers"
> One of the fundamental realizations behind SPKI is that every user of
> a public key has a global name: the public key itself.  The name may
> not be pronounceable and certainly not easily typed, but it is
> globally unique.  It also has the advantage of not needing a
> certificate to tie it to the user's public key.
>  If a given cryptographic hash function is collision-free, then the
> hash of the public key is also a globally unique identifier for the
> keyholder.  The base64 representation of that hash is a text string
> that is a globally unique identifier for the keyholder.  Neither of
> these needs a certificate to tie it to the corresponding public key.
> 
> 
> Alan Comment:
> This section promotes the situation that my public key can be held by
> a funny self defined number in some funny defined space. This
> obviously helps the globally dispersed recipients of my transactions
> to find the key material - and in fact verify the trust of the issuer.
> :-)))
> 
> For EC- authenticated signatures systems need to scale - Key material
> has to be tied commercially recognised names within a vertical market
> (banks, telecoms, car rental, etc -) and held in a directory so people
> who do not understand ASN.1, UTF 8 and hexadecimal notation can buy
> pots and pans with a "certficate/plastic card" from a store that also
> does not understand ASN.1, UTF8, etc.. I don't understand why this
> basic issue is still in doubt. Perhaps the mis understanding re X.500
> is to blame.
> 
> 
> 
> 
> 
> 
> NEXT
> Item 3 the text of the document
> "7.1 Key and certificate storage"
>  The term PKI is generally assumed to refer to an X.500 style global
> directory of certificates.  We have rejected global directories of
> extended common names on security grounds, even though SPKI includes
> the substring PKI.  Instead, we take the term PKI to refer to a
> general, distributed use of public keys empowered by certificates
> rather than assume some structure for certificate storage or official
> Certificate Authorities.
> 
> 
> Alan Comment:
> This statement presents an opinion on the definition of PKI which is
> wrong and then pollutes it to make it meaningless.
> PKI = Public - in the context of Asymmetric Key systems - Public means
> the PUBLIC KEY - not the world or the public at large or a government
> institution.
> 
> PKI - Key is as before - concatenated with PUBLIC
>  
> Infrastructure - means the systems (functions, protocols, information
> sets), the procedures, the algorithms, etc (ie the machines) and the
> people-procedure collective) that form the distribution and management
> of the public keys. 
> 
> The polluted term is saying its only key USE - therefore the
> Infrastructure issues and design is lost and therefore we are all left
> wondering how these things are built, institutionalised and managed
> with people and machines in the global EC market place.
> 
> I see no value in representing a common, widely used term wrong -  and
> then depreciating it to end up with something which does not cover the
> scope or intent what the original term set out to do... and at the
> same time, leave uninformed readers confused and lacking the very
> system design perspectives we need for and embraced by the term PKI.
> 
> 
> 
> Alan - Common Threads
> Yet again the debate seems to be be - globally applied distributed
> systems are too complex and cannot be be built, that simpler things
> are are better (But as we all know they only solve simple problems).
> And in addition making keys have local identities for a local
> environment is promoted as the answer. Ie. It is simpler as a
> mechanism to protect my data in my environment for me to access.. This
> is not very valuable.
> But that is the LDAP approach isnt it. My data in my server for me.
> 
> May I beg the question - I seem to be commenting from the position
> that we  should develop scaleable technology and system designs to
> evolve the Internet. Whereas many of the arguments presented in draft
> document cite big is bad (when its not that big), X... has failed ...
> and simple - unscaleable, proprietary  is better. So is the task of
> this group purely to invent a concoction of single interface and
> proprietary data mechanisms that have inbuilt technical and
> operational scaling issues. Or can the work embrace debate on
> distributed system design, scaling and operational overhead matters. 
> When it comes to PKI - and the scaleability of key management - if
> that is not right one can put all the things like TSL, SASL and any
> other security mechanism proposed in the bin.
> 
> as for spki without an infrastructure design, a directory system and
> hexadecimally named certificates - good luck to all those who deploy.
> 
> regards alan
From ???@??? Wed Jul 15 13:28:58 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 NAA01092
	for <cme@clark.net>; Wed, 15 Jul 1998 13:04:29 -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 MAA54728; Wed, 15 Jul 1998 12:55:52 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id JAA23858 for spki-outgoing; Wed, 15 Jul 1998 09:49:29 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-Id: <3.0.3.32.19980715124847.0318fde0@pop3.clark.net>
X-Sender: cme@pop3.clark.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 15 Jul 1998 12:48:47 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Carl Ellison <cme@acm.org>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Cc: "'spki@c2.net'" <spki@c2.net>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC04CAB8@DSG1>
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 01:58 PM 7/15/98 +1000, Alan Lloyd wrote:
>
>> Dear All -
>> 
>> In light of the work on security re authentication, access controls
>> and TLS and SASL, etc I thought I would comment on this doc on this
>> list and the LDAPext list  - as it could affect the work - Badly
>> 
>> <draft-ietf-spki-cert-theory-02.txt> - note its theory....

Alan,

	thank you for the comments on the theory draft.  There is a new draft 
coming, but your comments will apply to it just as to the old one.

	The disconnect seems to be that you believe a global text name works as 
an identifier and that that name has meaning to people who might use it -- 
e.g., for electronic commerce.

	As long as you continue to believe that, it is unlikely that you will 
appreciate the value of the SPKI/SDSI work.

 - Carl


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQA/AwUBNazdb5SWoQShp/waEQKO/gCfSJVyCB4ONZEnVCJLjkFvbQNdMNsAoJEG
WVYG9za4YNrSABSAg7wNywlF
=ln79
-----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 ???@??? Fri Jul 17 19:26:53 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 QAA04042
	for <cme@clark.net>; Fri, 17 Jul 1998 16:13:28 -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 QAA26260; Fri, 17 Jul 1998 16:03:18 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id MAA08595 for spki-outgoing; Fri, 17 Jul 1998 12:59:12 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
From: fredette@theory.lcs.mit.edu (Matt Fredette)
Message-Id: <199807171958.AA22864@thrush.lcs.mit.edu>
Subject: new MIT software release
To: spki@c2.net
Date: Fri, 17 Jul 1998 15:58:55 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-spki@c2.net
Precedence: bulk
Status:   


A new release of the MIT SDSI/SPKI C software distribution is 
available.  Go to

http://theory.lcs.mit.edu/~cis/sdsi.html

and follow the software distribution links in the paragraph about 
SDSI/SPKI 2.0.  Note that you must be a US or Canadian citizen, etc., 
to get this software.  

The following binary builds are available:

sdsi20-0.4.0-sparc-sun-sunos4.1.4.tar.gz
sdsi20-0.4.0-sparc-sun-solaris2.5.1.tar.gz
sdsi20-0.4.0-i386-pc-solaris2.6.tar.gz
sdsi20-0.4.0-i386-unknown-netbsd1.1.tar.gz
sdsi20-0.4.0-mips-sgi-irix5.3.tar.gz

An Intel Linux build will hopefully be available soon.

These are all built from the source distribution:

sdsi20-0.4.0.tar.gz

As usual, many bugs were fixed in this release.  See ChangeLog in the source
distribution for the details.

More general notes from the 0.4.0 README:

Release 0.4.0
-------------

This code now requires (sequence )s to conform to the expected grammer
in the structure-06 draft, i.e., it supports the macro "def" and "ref"
mechanism, and, if threshold subject support is compiled in, the
"process-threshold" mechanism.  It will reject sequences that use
the old (do hash ) or old (do k-of-n) directives.

DSA support has been finished, and is compiled into the library by
default.  This means that SDSI2_FEATURE_STRUCTURE6_SIGS is defined by
default; since this changes the grammar for signatures to match what
is expected in the structure-06 draft, earlier signatures will break.
See the applicable blurb in the 0.3.0 notes of the README for details.

PGP support has been extended to handle what I believe to be the
majority of PGP 5.0 keyrings.  If your PGP private keyring uses IDEA
or CAST5 with MD5 or SHA1 to seal the secrets, sdsi2sh should be able
to read it.  PGP DSA keys are fully supported.

The SDSI distribution now includes MIT-written multi-precision integer
and DES libraries.  This means that you don't have to track down and
compile GNU MP and Eric Young's libdes if you don't want to.  If you
do still want to compile with one or both of these other libraries,
you can - see the main documentation for instructions on when you may
want to, and how.

The reduction code has been completely rewritten.  It's separated out
from sequences, in its own little internal API.  You step a reduction
with rules until you run out of them, and then you can get out the
conclusion that results from those rules.  It's possible to reduce
a whole (sequence ) into its equivalent (cert ), or to just reduce
two (cert )s into one.

The cache API has changed considerably, to present the face of a
generic S-expression cache.  sdsi2_cache_add_search_term is a single
function used for incrementally building a cache query, that works a
lot more intuitively than the old add_search_.._term functions did.
The actual cache format has not changed.

The ugly story of unparsing S-expressions, or filling a sdsi2Sexp, has
been completely retold.  It is now possible to allocate a new
sdsi2Stream, simply "push" canonical elements (like whole sdsi2Sexp *,
sdsi2ByteString *, integers, etc.) onto it, and then just call
sdsi2_sexp_parse to have it parse that into a new sdsi2Sexp.

Two new commands have been added to sdsi2sh: "load" and "save" allow
you to load a variable from and save a variable to a file.

Matt

-- 
Matt Fredette
fredette@bbnplanet.com, fredette@mit.edu, fredette@theory.lcs.mit.edu
http://mit.edu/fredette/www
"The first time the Rolling Stones played, three people came."
From ???@??? Sat Jul 25 23:25:42 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 SAA04161
	for <cme@clark.net>; Sat, 25 Jul 1998 18:12:54 -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 SAA58070; Sat, 25 Jul 1998 18:03:55 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id OAA02240 for spki-outgoing; Sat, 25 Jul 1998 14:53:08 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <D1A949D4508DD1119C8100400533BEDC06074B@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Carl Ellison '" <cme@acm.org>
Cc: "''spki@c2.net' '" <spki@c2.net>
Subject: RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 07:52:10 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-spki@c2.net
Precedence: bulk
Status:   


Thanks for that carl - I believe that names work in EC because to date
the way in which I go around this planet is with my name - its on my
amex, my air tickets, my passport, my birth certificate, my bank
accounts, my car insurance. But that is just my world and millions like
me...

First off all I DO NOT BELIEVE IN MISREPRESENTATION to the extent the
SPKI document promotes - IT IS NOT A SIMPLE PUBLIC KEY INFRASTRUCTURE as
this requires certificates and key issuers. The current document only
promotes taking a key and making a uniqueID number of it.

Therefore the document should be redrafted to "how to make a unique ID
from keys-draft-text.001"

The text that mis represents X.500 and what PKIs are about should be
corrected - in that way the document might get some credibility.


May I say it seems pointless inventing things that are pointless. 
regards alan
----------
From: Carl Ellison
To: Alan Lloyd
Cc: 'spki@c2.net'
Sent: 7/16/98 2:48:47 AM
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 01:58 PM 7/15/98 +1000, Alan Lloyd wrote:
>
>> Dear All -
>> 
>> In light of the work on security re authentication, access controls
>> and TLS and SASL, etc I thought I would comment on this doc on this
>> list and the LDAPext list  - as it could affect the work - Badly
>> 
>> <draft-ietf-spki-cert-theory-02.txt> - note its theory....

Alan,

	thank you for the comments on the theory draft.  There is a new
draft 
coming, but your comments will apply to it just as to the old one.

	The disconnect seems to be that you believe a global text name
works as 
an identifier and that that name has meaning to people who might use it
-- 
e.g., for electronic commerce.

	As long as you continue to believe that, it is unlikely that you
will 
appreciate the value of the SPKI/SDSI work.

 - Carl


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQA/AwUBNazdb5SWoQShp/waEQKO/gCfSJVyCB4ONZEnVCJLjkFvbQNdMNsAoJEG
WVYG9za4YNrSABSAg7wNywlF
=ln79
-----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 ???@??? Sat Jul 25 23:25:34 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 RAA00203
	for <cme@clark.net>; Sat, 25 Jul 1998 17:54:13 -0400 (EDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA45212 for <cme@acm.org>; Sat, 25 Jul 1998 17:45:11 -0400
Received: by DSG1 with Internet Mail Service (5.0.1458.49)
	id <PLMM1QZA>; Sun, 26 Jul 1998 07:52:11 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC06074B@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Carl Ellison '" <cme@acm.org>
Cc: "''spki@c2.net' '" <spki@c2.net>
Subject: RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 07:52:10 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status:   


Thanks for that carl - I believe that names work in EC because to date
the way in which I go around this planet is with my name - its on my
amex, my air tickets, my passport, my birth certificate, my bank
accounts, my car insurance. But that is just my world and millions like
me...

First off all I DO NOT BELIEVE IN MISREPRESENTATION to the extent the
SPKI document promotes - IT IS NOT A SIMPLE PUBLIC KEY INFRASTRUCTURE as
this requires certificates and key issuers. The current document only
promotes taking a key and making a uniqueID number of it.

Therefore the document should be redrafted to "how to make a unique ID
from keys-draft-text.001"

The text that mis represents X.500 and what PKIs are about should be
corrected - in that way the document might get some credibility.


May I say it seems pointless inventing things that are pointless. 
regards alan
----------
From: Carl Ellison
To: Alan Lloyd
Cc: 'spki@c2.net'
Sent: 7/16/98 2:48:47 AM
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 01:58 PM 7/15/98 +1000, Alan Lloyd wrote:
>
>> Dear All -
>> 
>> In light of the work on security re authentication, access controls
>> and TLS and SASL, etc I thought I would comment on this doc on this
>> list and the LDAPext list  - as it could affect the work - Badly
>> 
>> <draft-ietf-spki-cert-theory-02.txt> - note its theory....

Alan,

	thank you for the comments on the theory draft.  There is a new
draft 
coming, but your comments will apply to it just as to the old one.

	The disconnect seems to be that you believe a global text name
works as 
an identifier and that that name has meaning to people who might use it
-- 
e.g., for electronic commerce.

	As long as you continue to believe that, it is unlikely that you
will 
appreciate the value of the SPKI/SDSI work.

 - Carl


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQA/AwUBNazdb5SWoQShp/waEQKO/gCfSJVyCB4ONZEnVCJLjkFvbQNdMNsAoJEG
WVYG9za4YNrSABSAg7wNywlF
=ln79
-----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 ???@??? Sat Jul 25 23:25:46 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 SAA06231
	for <cme@clark.net>; Sat, 25 Jul 1998 18:23:25 -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 SAA19430; Sat, 25 Jul 1998 18:14:23 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id PAA02368 for spki-outgoing; Sat, 25 Jul 1998 15:08:47 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <D1A949D4508DD1119C8100400533BEDC06074C@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '"
	 <cme@acm.org>
Cc: "''spki@c2.net' '" <spki@c2.net>
Subject: RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 08:07:52 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-spki@c2.net
Precedence: bulk
Status:   

 
Carl and the list FYI

I think as soon as one realises that one needs to authenticate users in
specific business domains and that those domains will issues "tokens"
with names and keys on -- like certficates, like amex cards, like
membership cards - and one needs to support that system with global
directories such as X.500 which has distributed operations (NOT LDAP)
and a system such as X.500 that also supports mutual authentication for
users around the system - like mobile phones do.. the quicker one might
realise that X.500 and 509 and PKI IS NOT A DREAM that failed `- 

what has failed is the belief that one can take a complex problem like
designing  distributed global information infrastructures which enable
EC through authentication of mobile users that can apply different
privileges in different business domains...And do this by making a key
into a unique ID....

One cannot solve a complex problem with a simple solution - and one
cannot deploy a simple very resticted solution to the bigger problem -
Especially when the real solution IS BEING DEPLOYED - GLOBALLY.

regards alan


FYI


  Feds want a digital certificate in every
  pot 

  By Ellen Messmer
  Network World, 7/13/98 

  Washington, D.C. - The federal government is starting to get downright
  geeky. While many technically savvy organizations are only toying with
the
  idea of digital certificates, the feds seem ready to jump in whole
hog. 

  In fact, the government may be offering a digital certificate to
everyone in
  the country in the not too distant future, at least according to Marty
  Wagner, associate administrator for government IT and electronic
  commerce policy at the General Services Administration (GSA). 

  "We need a security infrastructure that protects the citizens and
  corporations," Wagner said in his keynote presentation at last week's
  E-Gov conference, which highlighted efforts the government is making
to
  make online purchases from suppliers and make government services
  available to the public via the Internet. 

  X.509 digital certificates let Internet users identity themselves to
each
  other remotely, and the government is considering offering everyone in
the
  country a certificate if they want it, he said. "We're thinking about
having
  multiple contracts to the companies that provide digital certificates,
and
  these companies would give out the certificates for free," Wagner
said.
  The idea is that the federal agencies would reimburse the companies
for
  the certificates when they are used in agency applications. 

  The Feds may have a special interest in the widespread use of
certificates.
  For instance, the Social Security Administration (SSA) earlier this
year
  faced criticism from the press for allegedly not having sufficient
  authentication security on its Web site. The SSA Web site was allowing
  Web visitors to see personal financial information via passwords;
using
  certificate-based authentication would be far more secure. However,
this
  practice could become expensive because under some scenarios the
  government would end up paying a vendor $1 for each time a certificate
is
  validated online, Wagner acknowledged. 
From ???@??? Sat Jul 25 23:25:36 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 SAA03582
	for <cme@clark.net>; Sat, 25 Jul 1998 18:09:58 -0400 (EDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA09060 for <cme@acm.org>; Sat, 25 Jul 1998 18:00:53 -0400
Received: by DSG1 with Internet Mail Service (5.0.1458.49)
	id <PLMM1QZB>; Sun, 26 Jul 1998 08:07:54 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC06074C@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '"
	 <cme@acm.org>
Cc: "''spki@c2.net' '" <spki@c2.net>
Subject: RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 08:07:52 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Status:   

 
Carl and the list FYI

I think as soon as one realises that one needs to authenticate users in
specific business domains and that those domains will issues "tokens"
with names and keys on -- like certficates, like amex cards, like
membership cards - and one needs to support that system with global
directories such as X.500 which has distributed operations (NOT LDAP)
and a system such as X.500 that also supports mutual authentication for
users around the system - like mobile phones do.. the quicker one might
realise that X.500 and 509 and PKI IS NOT A DREAM that failed `- 

what has failed is the belief that one can take a complex problem like
designing  distributed global information infrastructures which enable
EC through authentication of mobile users that can apply different
privileges in different business domains...And do this by making a key
into a unique ID....

One cannot solve a complex problem with a simple solution - and one
cannot deploy a simple very resticted solution to the bigger problem -
Especially when the real solution IS BEING DEPLOYED - GLOBALLY.

regards alan


FYI


  Feds want a digital certificate in every
  pot 

  By Ellen Messmer
  Network World, 7/13/98 

  Washington, D.C. - The federal government is starting to get downright
  geeky. While many technically savvy organizations are only toying with
the
  idea of digital certificates, the feds seem ready to jump in whole
hog. 

  In fact, the government may be offering a digital certificate to
everyone in
  the country in the not too distant future, at least according to Marty
  Wagner, associate administrator for government IT and electronic
  commerce policy at the General Services Administration (GSA). 

  "We need a security infrastructure that protects the citizens and
  corporations," Wagner said in his keynote presentation at last week's
  E-Gov conference, which highlighted efforts the government is making
to
  make online purchases from suppliers and make government services
  available to the public via the Internet. 

  X.509 digital certificates let Internet users identity themselves to
each
  other remotely, and the government is considering offering everyone in
the
  country a certificate if they want it, he said. "We're thinking about
having
  multiple contracts to the companies that provide digital certificates,
and
  these companies would give out the certificates for free," Wagner
said.
  The idea is that the federal agencies would reimburse the companies
for
  the certificates when they are used in agency applications. 

  The Feds may have a special interest in the widespread use of
certificates.
  For instance, the Social Security Administration (SSA) earlier this
year
  faced criticism from the press for allegedly not having sufficient
  authentication security on its Web site. The SSA Web site was allowing
  Web visitors to see personal financial information via passwords;
using
  certificate-based authentication would be far more secure. However,
this
  practice could become expensive because under some scenarios the
  government would end up paying a vendor $1 for each time a certificate
is
  validated online, Wagner acknowledged. 
From ???@??? Sun Jul 26 08:54: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 IAA12510
	for <cme@clark.net>; Sun, 26 Jul 1998 08:00: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 HAA34602; Sun, 26 Jul 1998 07:51:54 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id EAA09329 for spki-outgoing; Sun, 26 Jul 1998 04:34:19 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <006401bdb889$3ae8af40$995895c1@uymfdlvk>
From: Ian Brown <I.Brown@cs.ucl.ac.uk>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '" <cme@acm.org>
Cc: spki <spki@c2.net>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 12:27:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-spki@c2.net
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ice.clark.net id IAA12510
Status:   

>I believe that names work in EC because to date
>the way in which I go around this planet is with my name

Your examples actually support the SPKI case -- they are most definitely not name certificates.

>amex

Nope -- the merchant cares about the payment authorised by your account number, not your name.

>my air tickets

No. Access token issued by air company after payment. Name is to comply with govt. regulations (matching your drivers license/passport) not to support e-commerce.

>my passport

Government access token to other countries. Name is largely irrelevant -- passport number may be used to access a CRL (wanted list). And since when was a passport vital for e-commerce?

>my bank accounts

Account number is important, not name.

>my car insurance.

Certificate issued by insurance company promising to pay you or others in case of accident. If you crash into someone, they don't care what your name is, they just want you to pay up.

>May I say it seems pointless inventing things that are pointless. 


I think this is better said to the PKIX group.

Ian.
From ???@??? Sun Jul 26 08:54:38 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 HAA09476
	for <cme@clark.net>; Sun, 26 Jul 1998 07:35:25 -0400 (EDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.acm.org (8.8.5/8.7.5) with SMTP id HAA56622 for <cme@acm.org>; Sun, 26 Jul 1998 07:26:27 -0400
Received: from thames.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09044-0@bells.cs.ucl.ac.uk>; Sun, 26 Jul 1998 12:34:03 +0100
Received: from uymfdlvk (actually userj388.uk.uudial.com) 
          by thames.cs.ucl.ac.uk with SMTP (PP);
          Sun, 26 Jul 1998 12:33:40 +0100
Message-ID: <006401bdb889$3ae8af40$995895c1@uymfdlvk>
From: Ian Brown <I.Brown@cs.ucl.ac.uk>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '" <cme@acm.org>
Cc: spki <spki@c2.net>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 12:27:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ice.clark.net id HAA09476
Status:   

>I believe that names work in EC because to date
>the way in which I go around this planet is with my name

Your examples actually support the SPKI case -- they are most definitely not name certificates.

>amex

Nope -- the merchant cares about the payment authorised by your account number, not your name.

>my air tickets

No. Access token issued by air company after payment. Name is to comply with govt. regulations (matching your drivers license/passport) not to support e-commerce.

>my passport

Government access token to other countries. Name is largely irrelevant -- passport number may be used to access a CRL (wanted list). And since when was a passport vital for e-commerce?

>my bank accounts

Account number is important, not name.

>my car insurance.

Certificate issued by insurance company promising to pay you or others in case of accident. If you crash into someone, they don't care what your name is, they just want you to pay up.

>May I say it seems pointless inventing things that are pointless. 


I think this is better said to the PKIX group.

Ian.
From ???@??? Sun Jul 26 08:54:42 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 HAA10850
	for <cme@clark.net>; Sun, 26 Jul 1998 07:46:25 -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 HAA43158; Sun, 26 Jul 1998 07:37:18 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id EAA09335 for spki-outgoing; Sun, 26 Jul 1998 04:34:43 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Message-ID: <006501bdb889$3cf10260$995895c1@uymfdlvk>
From: Ian Brown <I.Brown@cs.ucl.ac.uk>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '" <cme@acm.org>
Cc: spki <spki@c2.net>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 12:29:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-spki@c2.net
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ice.clark.net id HAA10850
Status:   

>  Feds want a digital certificate in every pot

And regardless of other issues, I know I would rather live in a SPKI world than one with the great privacy implications of a govt.-issued "e-passport."

I would *love* the government to know every Web page I ever read or purchase I ever made.

Ian. 
From ???@??? Sun Jul 26 08:54:39 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 HAA09529
	for <cme@clark.net>; Sun, 26 Jul 1998 07:35:51 -0400 (EDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.acm.org (8.8.5/8.7.5) with SMTP id HAA45164 for <cme@acm.org>; Sun, 26 Jul 1998 07:26:53 -0400
Received: from thames.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.09044-0@bells.cs.ucl.ac.uk>; Sun, 26 Jul 1998 12:34:04 +0100
Received: from uymfdlvk (actually userj388.uk.uudial.com) 
          by thames.cs.ucl.ac.uk with SMTP (PP);
          Sun, 26 Jul 1998 12:33:44 +0100
Message-ID: <006501bdb889$3cf10260$995895c1@uymfdlvk>
From: Ian Brown <I.Brown@cs.ucl.ac.uk>
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '" <cme@acm.org>
Cc: spki <spki@c2.net>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Sun, 26 Jul 1998 12:29:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ice.clark.net id HAA09529
Status:   

>  Feds want a digital certificate in every pot

And regardless of other issues, I know I would rather live in a SPKI world than one with the great privacy implications of a govt.-issued "e-passport."

I would *love* the government to know every Web page I ever read or purchase I ever made.

Ian. 
From ???@??? Sun Jul 26 14:01:35 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 KAA03650
	for <cme@clark.net>; Sun, 26 Jul 1998 10:20:18 -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 KAA20148; Sun, 26 Jul 1998 10:11:18 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id GAA11089 for spki-outgoing; Sun, 26 Jul 1998 06:57:41 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Date: Sun, 26 Jul 1998 10:57:11 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
Reply-To: Ed Gerck <egerck@laser.cps.softex.br>
To: Ian Brown <I.Brown@cs.ucl.ac.uk>
cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>,
        "'Carl Ellison '" <cme@acm.org>, spki <spki@c2.net>
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
In-Reply-To: <006401bdb889$3ae8af40$995895c1@uymfdlvk>
Message-ID: <Pine.LNX.3.95.980726104400.26808D-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-spki@c2.net
Precedence: bulk
Status:   

On Sun, 26 Jul 1998, Ian Brown wrote:

>
>>amex
>
>Nope -- the merchant cares about the payment authorised by your account number, not your name.


Ian:

While I strongly disagree with Alan Lloyd's wording about SPKI, and
while I have almost one year ago already discussed here the
inapropriate name of SPPKI since it is not a PKI and the bad
consequences it would bring by such "misrepresentation", I must say
that your line above is an old dead-beaten horse.  From [1]: 

Regarding cyber-world misconceptions, some think that by escaping
names one can escape reality.  Others think that credit-cards deals
would not need names or any real-life id, just assets. Surely, the
merchant gets paid regardless, even if you use a false name.  But
this is not the end of id fraud. The bank still goes after the
money...and uses the law against fraudulent practices to enforce the
cardholder agreement, or criminal statues.  If Mr. X uses his wife's
credit-card, Mr. X is technically committing id fraud, and
wire-fraud. Of course it works most of the time... But when it does
not, and someone comes enforcing, someone will ask, did you Mr X,
uses Mrs X's credit-card, and represent yourself thereby as Mrs X? 

The other points of your message suffer from the same bias. Again,
using a wrong argument (such as the credit-card name/asset issue) is
not the best way to show that names are references that are locally
interpreted.

Cheers,

Ed Gerck

Reference:

[1] http://www.mcg.org.br/trusdef.htm or 
    http://www.conexware.com/mcg/trustdef.htm
______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
-- Internet saves trees, WebBoy UMC saves PCs, you save time and money