SDSI/SPKI background

[Carl Ellison]

At 12:00 PM 6/13/2003 +0200, Stefan Mink wrote:
>
>Hi Carl,
>
>On Wed, Jun 11, 2003 at 09:56:12PM -0700, Carl Ellison wrote:
>> There's one draft that should have gone on to RFC, but people were
>> using it from the draft instead.  It's my fault that we left it at
>> that stage and didn't publish the RFC.  That's still on my list of
>> things to do :-)  It seems that other work kept getting in the
>> way. 
>
>I guess its the draft about the certificate structure?

There were two: the certificate structure draft and the examples
draft.  But, you're right, it's the certificate structure that we
used from the draft without waiting for the RFC.

>
>> stand-alone product like PGP.  It's a tool to be used within other
>> products.  It's also almost exclusively for a closed authorization
>> infrastructure, rather than an open naming infrastructure.  In
>> fact, 
>
>Is there a special reason why the authorisation system can't or
>shouldn't be open here? Most systems and services are distributed
>and are developed independently, so an open standard would be
>reasonable here too, wouldn't it?

Of course, you're correct.  If we knew we were using all the same
language rather than local dialects, we might have some common tools
that people would be encouraged to write: e.g., a certificate viewer,
a certificate path discovery service, ...

>
>> under SPKI/SDSI thinking, a global naming instructure is not a
>> proper use of one's time and energy.  This is doubtless why the
>> PKI Vendors react with hostility toward SPKI/SDSI.
>
>agreed :)
>
>> Yes.  Check out KeyNote and PolicyMaker.  There are links to those
>> from my web page.
>
>I couldn't access the latter one but found a copy on citeseer

You can't access my SPKI web page?

http://theworld.com/~cme/html/spki.html

It works for me.

>> Of course, you don't have to use certificates for authorization. 
>> You can bind an authorization to a key in a protected database (a
>> key-based ACL, in SPKI/SDSI terminology).  Samples of that are SSH
>> and X9.59.
>
>sure, but I like the idea of storing the privileges independent of
>the service instance; of course there are drawbacks (revocation)...

I owe a paper on this.  I've been looking into this heavily for a
couple of years.  See my section on the CAP Theorem on the SPKI web
page.  Since everything we do with certificates can be done equally
with local protected memory (ACLs, Directories) or with services out
on the net (holding their own protected memory), you have to have a
reason to choose one over the other at design time.  Network
partition tolerance is one of those reasons, but you have to
sacrifice either consistency or availability when you do that.  There
is also an advantage in revocation with the two ACL models (local
ACL; networked service) since there are no freely copied certificates
in use.  However, you're not home free.

We're not designing systems that have only computers connected by
communications channels.  Our systems perforce include human beings
(e.g., as policy administrators).  It is a human being who decides to
do a revocation.  That human doesn't live in the local machine
granting access.  Even if she did live right next door, she would
soon quit if every access request required her personal interaction. 
So, when you draw the "network" to include all those humans, you
still have network partition problems and still have the possibility
of a revocation problem.


>
>> We went on to use it in products and research.
>>
>> We were and are a group of developers and researchers, not
>> standards writers.  Standards writing is fundamentally boring.
>
>:)
>
>Thanks &&
>   tschuess
>             Stefan Mink
>--
>Stefan Mink, Schlund+Partner AG (AS 8560)
>Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62
>F0D4 D2BA  

BTW, Stefan, my mailer throws up on Mutt messages.  I need to get a
new mailer for this machine - but can Mutt send signed messages in
the old fashioned in-line style?

 - Carl



+--------------------------------------------------------+
|Carl Ellison      Intel R & D       E: cme at jf.intel.com |
|2111 NE 25th Ave                    T: +1-503-264-2900  |
|Hillsboro OR 97124                  F: +1-503-264-3375  |
|PGP Key ID: 0xFE5AF240                                  |
|  1FDB 2770 08D7 8540 E157  AAB4 CC6A 0466 FE5A F240    |
+--------------------------------------------------------+

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com