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

RE: Final Year Thesis : SPKI


At 12:26 PM 6/29/98 -0400, Phillip Hallam-Baker wrote:
>In point of fact X.509 and SPKI may well converge at some future point.

we might..especially when the X.509 folks get tired enough of ASN.1 :)

Actually, I can imagine an X.509v4 that would facilitate such a
convergence.  All it has to do is drop the distinguished-name definition
from the ASN.1, and drop all references to it.  That would be a major
start at convergence.

>I would not suggest that someone who is not a 100% tech guy embark upon
>such a project however. Comparing X.509 with SPKI is unlikely to be
>usefull without an understanding of the underlying technology. A more
>feasible project might well be to focus on the business and legal 
>issues. For example there is an established legal infrastructure for
>X.509 based on the use of a Certificate Practices Statement and
>Relying party agreement. How does the SPKI model relate to such 
>constructs? What liability and risk models are practical? What role
>is there for trusted third parties and what business models are

Actually, these areas are addressed by the work of Jane Winn and Cem Kaner, 
probably among others -- both coming at it as lawyers.


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

I am far more comfortable with a certificate infrastructure whose legal 
basis is contractual, on paper, as under to the old EDI model.  This can 
easily be done (e.g., as with SET).  That practice does not rely on a 

 - Carl

Version: PGP for Personal Privacy 5.5.3


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
From ???@??? Mon Jun 29 16:43:29 1998
Received: by mis01.reston.cybercash.com; id PAA22474; Mon, 29 Jun 1998 15:07:28 -0400 (EDT)
Received: by callandor.cybercash.com; id PAA22052; Mon, 29 Jun 1998 15:06:30 -0400
Received: from blacklodge.c2.net( by callandor.cybercash.com via smap (3.2)
	id xma021984; Mon, 29 Jun 98 15:06:07 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id LAA18349 for spki-outgoing; Mon, 29 Jun 1998 11:58:13 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Date: Mon, 29 Jun 1998 15:56:46 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Carl Ellison <cme@cybercash.com>
cc: Lynn.Wheeler@firstdata.com, Judie Mulholland <judiemul@kc-inc.net>,
        DoWneR@mail.dma.be, spki@c2.net
Subject: Re: Final Year Thesis : SPKI
In-Reply-To: <>
Message-ID: <Pine.LNX.3.95.980629154332.13732u-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-spki@c2.net
Precedence: bulk

On Mon, 29 Jun 1998, Carl Ellison wrote:

>IMHO, one of the most important contributions of the SPKI work has been the 
>discovery that the old idea of global name (DN) as identifier (upon which 
>X.500/X.509/PEM was originally based) has been shown to be seriously flawed,
>not just philosophically but via concrete security flaws.


I do not want to beat an old horse twice ;-)  but what you affirmed
above was denied even in this list. 

First, the DN scheme of X.500 was self-abandoned perhaps +5 years ago
in favor of an ad hoc X.500-like scheme which allowed CAs to make
X.509 work. The reasons why it was abandoned are several: it was
never fully defined, it was never well-defined to beguin with, etc.
But that has nothing to do with the X.509 issues of today -- which
does not use X.500 as you would take it out of the box (which box?).

Second, the DN scheme that the CAs actually implemented in order to
proceed with X.509 had its positive and negative points. But they are
not "security flaws". Rather, they are "privacy flaws".  Quite
different points. I fail to see one "security flaw" in X.509 name

Third, the original name scheme that SPKI/SDSI used did not work
because collisions would quickly surface. Then, the new SPKI/SDSI
name scheme that was presented this year is not without problems
either and quieting that will not make it sound. 


Ed Gerck
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Follow-Ups: References: