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

Re: Ideas from the I&A Forum



At 09:52 PM 7/16/96 -0700, PALAMBER.US.ORACLE.COM wrote:

>I am still enamored with a PIC-like syntax.  The PICS example below is 
>reasonably human readable. 
> 
> (PICS-1.1 "http://www.gcf.org/v2.5" labels 
>  on "1994.11.05T08:15-0500" 
>  exp "1995.12.31T23:59-0000" 
>  for "http://www.greatdocs.com/foo.html" 
>  by "George Sanderson, Jr." 
>  ratings (suds 0.5 density 0 color/hue 1)) 
> 
>We should make spki signatures as readable! 
> 
>I am not advocating a full SDSI S-expression syntax (too complicated, and a 
>few other issues).  Instead, I would suggest that the flexibility in our 
>"certificate" structures (a.k.a. auth stuff) be supported by a machine 
>readable PICS-ish expression carried within a well defined simple signed 
>structure. 

Paul,

        thanks for the glimpse of PICS.  Is there a full write up I can refer to?

        Labeling of an object (which is the example you gave) doesn't apply to certificates, unless you are suggesting that some trusted third party generate all PICS labels and only labels from that trusted party be honored by a browser.

Who does the enforcement in PICS?  ..the browser or the server?  If it's the server then the user needs a certificate giving characteristics relevant to PICS.  If it's the browser, then all you need are object labels.

In that latter case, I don't see a need for certificates at all.

Meanwhile, I'd like to see your proposal for an SPKI signature.  Care to post it?

 - Carl
From ???@??? Thu Jul 18 12:18:46 1996
Return-Path: <cme@cybercash.com>
Received: from carl ([204.254.34.231]) by cybercash.com (4.1/SMI-4.1)
	id AA10439; Thu, 18 Jul 96 12:13:22 EDT
Message-Id: <2.2.32.19960718161620.00854e00@cybercash.com>
X-Sender: cme@cybercash.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 18 Jul 1996 12:16:20 -0400
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
From: Carl Ellison <cme@cybercash.com>
Subject: Re: Ideas from the I&A Forum
Cc: cme@cybercash.cybercash.com, spki@c2.org
X-UIDL: 3bb475561b67102378734aeb1be4257a

At 09:52 PM 7/16/96 -0700, PALAMBER.US.ORACLE.COM wrote:

>I am still enamored with a PIC-like syntax.  The PICS example below is 
>reasonably human readable. 
> 
> (PICS-1.1 "http://www.gcf.org/v2.5" labels 
>  on "1994.11.05T08:15-0500" 
>  exp "1995.12.31T23:59-0000" 
>  for "http://www.greatdocs.com/foo.html" 
>  by "George Sanderson, Jr." 
>  ratings (suds 0.5 density 0 color/hue 1)) 
> 
>We should make spki signatures as readable! 
> 
>I am not advocating a full SDSI S-expression syntax (too complicated, and a 
>few other issues).  Instead, I would suggest that the flexibility in our 
>"certificate" structures (a.k.a. auth stuff) be supported by a machine 
>readable PICS-ish expression carried within a well defined simple signed 
>structure. 

Paul,

        thanks for the glimpse of PICS.  Is there a full write up I can
refer to?

        Labeling of an object (which is the example you gave) doesn't apply
to certificates, unless you are suggesting that some trusted third party
generate all PICS labels and only labels from that trusted party be honored
by a browser.

Who does the enforcement in PICS?  ..the browser or the server?  If it's the
server then the user needs a certificate giving characteristics relevant to
PICS.  If it's the browser, then all you need are object labels.

In that latter case, I don't see a need for certificates at all.

Meanwhile, I'd like to see your proposal for an SPKI signature.  Care to
post it?

 - 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        |
+--------------------------------------------------------------------------+