Semi-structured thoughtsm concerning what we are saying the big
picture of the debate is emerging as:-
There are three layers emerging to the architecture - for
a "secured message passing infrastructure with variable, per-exchange
established, but formally agreed and assured, application layer
semantics."
(yes , a bad horrible mess of a defn. But its the best I can
do at the moment. Ill work on my expression and the underlying ideas...)
get rid of 822 and SMTP as we know (or rather use) them. And
move "mail" handling onto the Web protocols is the general message.
this is nothing more than a mix of the old idea of interactive
mail, plus self-defining object semantics, plus hypermedia, combined.
What we are adding is the security constraints into all this,
to obtain the assurances we need to apply such a framework for
use in commerce. there is a toolkit of security mechanisms available
from the DMS/MISSI program which can build on PEMs infrastructure framework
which
are just ripe for exploitation:-
3 layer architecture:-
1. message-passing protocol which constrains store and forward
information exchange for many workflow patterns by exploiting digital
signatures, privilege certificates, access control, and content
security services to enforce the semantics agreed and needed to
accomplish the various assured workflow patterns.
The simplest pattern is currently MIME's PEM-protocol providing a
"privacy" work pattern for personal mail flows; multiple-authorization
signatures and flow pattern from ANSI X9, are a second concrete example.
Generically, the secured object architecture fits here.
2. The glue which allows (per-exchange, though secured a priori)
agreement of workflow and security-protocol semantics; and also
syntactic carriage and exchange of the layer 1 packets. This would be
the MIME multipart units, and the certificates
privilege/semantic-options fields, together with an access
control/enforcement unit to provide the "per-exchange, though secured a
priori agreement of semantics."
We have the MIME-PEM experience over SMTP. We can fit this over http
without too much fuss. The DMS MISSI use of privilges and clearances
and an access control unit built over a content security service shows
how one can assure for a store and forware exchange that a given flow
policy can be required by an orignator.
These mechanisms can be made generic to allow the same facilities to
support not a disclosure or integrity security policy, but a generic
information flow policy facilitating the prior enforcement/agreement of
semantics of the signature-protocols and the work flow pattern
3. Encapulation, encoding, and remote network access techniques for exchanging
the InformationObject between generic client and servers, whose basic
access language/protocol itself must be secured, proably using a
connection oriented security sub-protocol. The most obvious example is
the WWW client and server reliable transport service.
Lots of connection-oriented security stuff and experience exists. Secure
Sockets, or CIPSO directly.
Scenario:-
For the workflow application normally referred to as mail, then we are
returning to one of the oldest models of interactive mail of all, but
with more modern and practical protocols and flexilbe architectures for
objects.
Namely, each UA is a fully distributed node in the WWW-MHS (everone has a
personal mailURL, and a WWW client/responder, versus a mail address and distinct
mail UA) The fully distributed notion ensures we have no mail or
application relaying. So in a fully connected network assumed by WWW,
then http exchanges the "mail object" - in old fashioned language, not
SMTP or P3/P7. This is function 3. The Netscape security work
fits in here.
The hypermedia nature of html could be conceived to merge with the
object security architecture, 1. HTML could embrace the new
architecture as a complex content-type, Or HTML could itself
evolve into the object architecture. The BBN work (and other very
similar ISO) work fits in here.
As the info and application semantics of that architecture are agreed
by layer 2, and that is a store-and-forward process, then the
exchange of http/PEM-MIME and the hypermedia referrals guide and
negotiate and agree (with non-repduation) the semantic context for
signing protocol, and work flow pattern.
(the last bit suffers from using layering to impossibly describe
hypermedia relations between the exchange protocol at one layer,
and its hypermedia content formalized at another!)
Hopefully, some of the idea gets across here. the last bit is an idea -
namely use hypermedia interactions to perform the negotiation, rather than
en explicit negotiation protocol.
The bit I do understand is that the privilege certificates can
be used to pre-negotiate (thats it, Ive found the verb!) or pre-agree
the signature semantics, and the workflow pattern.
We could work on fitting it all together...and make PEM a happy place
by regaining a goal!?