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

RE: spec for wire format of SPKI cert

Carl,

Thanks for the note; I picked up a spki.txt from the web, dated recently.

There is certainly a large collection of wayward semantics being expressed,
and a noticable tendency to simply redefine all other systems with a new overlying
syntax and terminology, rather than establish a common "simple" semantic
model to which others naturally gravitate, because its better. 

I do agree that the notion of controlling delegation is the most simplistic
security policy model Ive thought about myself, and one which is increasingly
necessary for the object protocols now emerging into practice on the web.
Assuming the Internet becomes a distributed object system, one can
perhaps begin to conceive of certs not as an ancillary mgt security infrastructure, but
as the point of expression and control of interface brokerage between cooperating
objects. Just as an X.509 cert is really a mini-Directory entry, so the 
delegation-cert is a authorised-configuration utility for both comms paths
and interworking assumptions.

Whereas RPC models used normal comms security service and
thereby relied upon the tradtiional separation of authentication and authorization
to "separate" domains, the more important modern
control point - where objects need security - is indeed surely during the binding of
monikers to their object interfaces, and where one interface delegates
to another responsibility. Such bindings mnifest themselves  just as much in securing
an real RPC bindery mechanism, as for two objects operating as part of
MS COM, or native CORBA-specified brokerage, within 
processes, or within a single computer system using
global memory as a comms channel, or over  network-OLE w/RPC, say.
Considering an SPKI cert to really be a trusted moniker -  the "new" role of a
SPKI cert may be easier to contemplate and express, rather than simply redefining
all other deploying certs (with their assumptions of authentication and authoriozation
semantics embedded) in terms of an NIH- or IhateASN.1- motivated syntax
casting.

So, I like what I see (and Im biased!) in the emerging model, where I can see through
the blatent NIH agenda, though have considerable legal worries from the consistency of
the argument concerning the role of TTPs. A reliable liability model depends upon
constrained data handling with well-defined meaning; and SPKI certs
sometimes seem to be self-defining semantically; and this property makes
life difficult if the certs are ever to control commercial risks,
control hazardous, or military weapon systems.

Its disappointing to see the rejection of the list-based SDSI cert format. Given its
striking structural similarity to X.509/DER lists one should not be suprised,
perhaps.

Peter.

----------
From: 	Carl Ellison
Sent: 	Tuesday, August 27, 1996 3:21 PM
To: 	Peter Williams
Cc: 	'spki@c2.org'
Subject: 	Re: spec for wire format of SPKI cert

At 11:53 AM 8/15/96 -0700, Peter Williams wrote:
>Could someone send me the spec of the SPKI cert wire format,
>and the precise encoding rules for the bytes which ones signs.
>
>Ive asked a leading light in SPKI and so far got nowhere, with a view
>to writing the code which interoperates with the reference
>code (apparently in production in some closed circle of vendors).

Peter, 

        sorry to have been so tardy getting back to you.  I've been out of
town (and still am).  I'll add a BNF section to spki.txt when I do the next
editing pass -- and pass it along to you as soon as it's done.

All the info is in spki.txt, but not in BNF format and certainly not in ASN.1 :)

The signed quantity is a block of binary bytes.  The format is spec'ed by
the ASCII equivalent, narratively through the text.

We've been accumulating some small changes to the format, in discussion
since 7/5/96 when the current spki.txt was posted, so I wouldn't suggest
building your own BNF from that document.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                              http://www.cybercash.com/    |
|207 Grindall Street           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103       T:(410) 727-4288     F:(410)727-4293        |
+--------------------------------------------------------------------------+