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

RE: encoding: SPKI vs. SDSI

PICS-Label (PICS-1.1 "http://www.classify.org/safesurf"
          ratings (SS~~008 9))

I don't think this is a hard problem except that its one of those 
things that everyone can have an opinion on. Hence it is one of 
those areas that can easily become a rat hole and clog up a 
standards effort good n' proper

What matters above all else is interoperability. 

I think its one of those areas where a cabal can probably come
up with a solution that meets everyone's objectives provided
people aren't too definite on having their particular approach...

-----Original Message-----
From:	Carl Ellison [SMTP:cme@cybercash.com]
Sent:	Monday, March 03, 1997 11:59 AM
To:	Phillip M. Hallam-Baker
Cc:	spki@c2.net
Subject:	RE: encoding: SPKI vs. SDSI

At 05:43 PM 2/26/97 -0500, Phillip M. Hallam-Baker wrote:
>>>We don't need two standard cannonicalizations for S-Expressions!
>>I think there can be only one standard for S-expressions.
>I can think of many cannonicalisations. Are there to be spaces before,
>after parentheses? How are litterals to be handled etc etc... ad nauseam...


	as long as the thing signed is the thing transmitted, there is no
canonicalization to be done prior to checking a signature.  Of course,
the difficulty of getting text through mailers uncorrupted might lead 
people to want to canonicalize before checking signatures.  IMHO, that's
a huge mistake.

I half agree and half disagree. I certainly do not like the clumsy PEM
style pandering to every email program and gateway in the universe.
Ideas like limiting the lines to 80 characters, removing blank space 
at the end etc are noisesome and stupid. Similarly I know of no 
data format stupider than ASN.1 DER. Without DER ASN.1 would be
merely braindamaged, with it it is lobotomized.

One of the major triumphs of the Web was to cut through IETF
superstition about eight bit clean transmission. There were many
people who wanted to impose all sorts of plain potty restrictions
on the spec so that the theoretical possibility of putting it through
broken SMTP gateways was still open. 

Where I disagree is the problem of storing certificates in some sort
of database. It is very convenient to be able to store a single copy of
a data structure and retain the signature. Similarly it is awkward if
two certificates appear to be the same on visual inspection but are 
in fact different due to added spaces etc etc.

This problem is serious when it comes to standards like PICS which
have to pass through email, proxies and USEnet, often as headers.

Let us ignore for a moment the use of PICS as a censorship device.
It is really an annotation mechanism which used the cyberporn scare
to attract critical mass. Tim said as much yesterday in a panel 
session. The Web became popular at CERN because of the phone
book application. Any mechanism short of hitting your fingers with
a hammer was a more pleasant and effective means of viewing the
CERN phone book than accessing CERNVM.

At the time I didn't think this a good strategy. It seemed to me that
entering that particular debate was like trying to offer a compromise
on abortion. Whatever good intentions one has neither side is likely
to give any thanks.

Now that PICS has critical mass and implementations we can
decide what to do with it. It is a means of passing metadata arround
the Web. SPKI is and SDSI are simply another application of metadata.

The PICS standard is at :-
Unfortunately it is not in a very convenient form for our purposes. It 
describes a concrete grammar rather than first proposing a meta-grammar
and instantiating a particular data structure.