pem-dev
[Top] [All Lists]

Re: Semantics of signatures, multiple and otherwise (Was:Re: limitations of mime-pem transformation

1995-01-03 19:12:00


   >From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
   >Subject: Re: Semantics of signatures, multiple and otherwise (Was:Re: 
         limitations of mime-pem transformation
   >Date: Tue, 03 Jan 1995 15:25:09 -0700 (PDT)

   >> (Momentary non sequitur -- would/does MIME support the notion of a 
hypertext
   >> document, where the relationship between the parts doesn't change, but the
   >> contents of one of the parts might?
   >
   >Yes it does. MIME includes the concept of an object that is nothing but a
   >reference to something else, and that something is usually obtained by using
   >some other protocol (e.g. ftp). This could then be embedded inside of some
   >species of multipart that specifies the relationship between parts (e.g.
   >multipart/parallel, where all the parts must be displayed in parallel).
   >
   >In the security multipart extension to MIME its the reference that gets 
signed,
   >not the remote object. The remote object is a MIME object and thus can 
itself
   >be a signed entity, of course, and once you retrieve it you can verify the
   >signature that's on it. (Alternately, the security could be provided by the
   >network link itself.) However, the signature is co-resident with the remote
   >entity, not with the message that references the entity.
   >
   >This is supported now by the basic mechanisms that lets you sign a group of
   >objects together rather than one at a time. However, this doesn't let you
   >update a particular part of the group without invalidating the signature. 
You
   >need both the ability to reference an outside object as well as to verify 
that
   >you're referencing the right outside object.
   >
   >Neat stuff, isn't it?


Yes. Its great. There; I actually agree with something Ned Freed says!
I believe the basic concepts were outlined about 15 years ago at Xerox
- it the polymorphic application object concept.  Though you wouldnt
realize it, its what OSI's IS 8613 is based on. I was being taught this
stuff when I was an undergraduate, a while ago. That MIME is addressing
this area for the masses, is great.

Getting a suitable typed information model formalized was never very
hard.  That MIME does this part in a very natural and
self-defining/implementing way is great; the smalltalk for the
common-man! That in combination with message passing protocols
(providing LOCATION-INDEPENDENT, DOMAIN-INDEPENDENT connectionless
private channels) wonderful groupware concepts can be
defined/implemented whose application semantics and flows are specified
in the very object being passed. The fault lines with MIME are that it
only allows in one-pass but one organization of the content objects to
be specified.  (Im willing to be corrected here... I may be either
wrong, or its all in the original conception as yet unfulfilled)

Now, the really powerful security semantics with such objects come with
the introduction of multiple parallel structures which interplay and
overlap. Thus for a given document architecture, a logical versus a
layout structure versus a temporal structure, semantic-specific
signatures and authorization controls on the layout grouping of content
types can be mixed with those of the temporal structure to contrain
navigation and presentation activities according to
pre-ordained flow policies. Or, the flow policies can themselves be
distributed objects... Obviously controls on the (current) MIME-like
logical structure allow classical integrity and disclosure controls and
flow policies.

To realize the potential of MIME/PEM, its a discussion of the security
framework for this world that we miss. for that is the world MIME/PEM
is surely to address itself; not simple email!

You can see how some of this plays out in the IS 8613 security
addendum, where a given document frame/page can be in white out for
given user though surrounding material or the page numbering may not be
sensitive, nor is the implied length of the secret subject material.
Alternaitvely, the logical section might be controlled for access, with
the application-engine reorganizaing page numbering and content pages
automatically for the constraints - numbering becomes non-sequential,
but hierarchical Page 1.1.1+iv, etc; hypermedia links disaappear...
For a secure audio content type, one can imagine voices in a converstaion being
muted for voice-patterns :-)

Similarly for flow controls expressed on the logical structure, the
requirements for secured controls|flow of the object through a network
of processes (people!) can be specified, to both control and constrain
the groupware activity both access models, distribution, and flow
policies.

Perhaps we can pass on now, and ask Dave Crocker for permission to
reintroduce BBN's activity plan for considering efforts to
standardize some of the less-researchy aspects of this science so users
get tangible benefit using Internet technologies?

There is a need to refine the concepts down to the doable, and useful.
15 years is about the time it normally takes to get science to
application on the street.

Peter.

<Prev in Thread] Current Thread [Next in Thread>