> I don't see
> this in Safe-TCL. The language doesn't have any simple way to
> determine whose authority a procedure executes with. Maybe Safe-TCL is
> a useful platform on top of which one could build this kind of
> security model, but it isn't there, and it isn't obvious that Safe-TCL
> actually provides 'an open framework on which you can build' such
> applications.
Well, let me try to explain the reasoning behind this claim, which I
realize is a very strong claim that might appear overblown.
The goal of Safe-Tcl is to provide a language for mail-enabled
applications (including but not restricted to the kinds of agents you
describe), in a way that is fully compatible with the OPEN standards of
today's Internet email. In some places, these standards are quite clear
and well-understood -- SMTP, 822, MIME, etc. In other places, however,
things are still evolving. One of the most unclear areas is email
authentication. Between PEM and PGP there is a fair amount of murky
ground, as I'm sure you will readily admit.
Now, clearly an authentication infrastructure is very important to
mail-enabled applications; no one would debate that. The question is
whether such an authentication infrastructure should be a part of the
language model, as in Telescript, or whether it should be orthogonal
thereto. Safe-Tcl comes down squarely on the "orthogonal" side. Our
position is that there should be an authentication standard for Internet
mail, and it should be used by Safe-Tcl or any other mail-enabling
language.
However, the problem is that we're trying to build a language (Safe-Tcl)
in ADVANCE of the standardization of the authentication infrastructure.
(The only alternatives are to either wait for the authentication wars to
end, or to have the enabled mail system NOT be orthogonal to the general
authentication infrastructure.) So how do we do it? Conceptually, very
simply. We say that the information about authentication is provided
out-of-band to Safe-Tcl, by whatever mechanism (also outside of the
specification) invoked Safe-Tcl in the first place. Inside Safe-Tcl,
this information is made available with the SafeTcl_Services variable in
the *trusted* interpreter, where it is not modifiable by untrusted code.
Thus, for example, if you want to experiment with authenticated enabled
mail, using (for example) PGP with Safe-Tcl, you would configure your
MIME viewer in such a way that after PGP-decrypting a MIME entity of
type application/Safe-tcl (or a multipart message containing such an
entity), you would make the authentication information available to the
Safe-Tcl interpreter.
This is all completely doable today, using the public interpreter
(swish) and pgp. Your pgp-decryption process just needs to feed the
authentication information to swish, which can be made to stick the pgp
signature information in the SafeTcl_Services variable using the
-initeval mechanism on the command line. Then, your personal or site
extensions, which execute in the trusted interpreter, can take
differential action based on this authentication information.
No kidding, this all works today, with today's version of the Safe-Tcl
interpreter. -- Nathaniel