From: “Alan (Miburi-san) Wexelblat” <wex@media.mit.edu>
To: cypherpunks@toad.com
Message Hash: ac41c652bc9548a4a087ddced8f844b716a9e3025b416a32228dec925ef71fa6
Message ID: <9402271657.AA08339@media.mit.edu>
Reply To: N/A
UTC Datetime: 1994-02-27 19:14:18 UTC
Raw Date: Sun, 27 Feb 94 11:14:18 PST
From: "Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>
Date: Sun, 27 Feb 94 11:14:18 PST
To: cypherpunks@toad.com
Subject: Valente clarifies on Telescript
Message-ID: <9402271657.AA08339@media.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
[This was posted to RISKS in response to objections raised by several
readers. Note that he says they are using "RSA" encryption; one wonders
where their public keys are? --AW]
From: "Luis Valente" <luis_valente@genmagic.genmagic.com>
Subject: Safety in Telescript, Part Deux
Following my posting to RISKS on January 17 entitled "Safety in
Telescript" a number of readers have strongly questioned some of the
statements I made in that posting. Two of those statements, in which I
used casual or imprecise language, were particularly criticized:
1- "Telescript is interpreted and, thus, is safer than compiled
languages." As pointed out by many readers, an interpreted language is
not intrinsically safer than a compiled language. It is the Telescript
language definition that provides that protection. Within the abstraction
created by Telescript, programs lack operations for directly manipulating
the physical resources of the "real" computer(s) on which they execute.
That doesn't mean that Telescript programs cannot interact with
applications (e.g., databases) outside the Telescript abstraction.
However, that interaction can only take place via Telescript objects that
act as proxies for the "external" applications. Each such proxy object
defines the features of the corresponding external application that are
to be made available to Telescript agents and places. It may also define
and enforce a security policy for controlling access to those features
(e.g., based on an agent's credentials and permit). Furthermore, the
administrative authority for a given Telescript engine is capable of
controlling (by means of mechanisms built into the language) who can and
cannot create these proxy objects.
2- "Authority names are cryptographically generated and cannot be
forged." Obviously, that statement is not true in an absolute sense since
the "unforgeability" of the authority name is directly related to the
cryptographic mechanism used to generate it. We currently use RSA-based
public key cryptography for generating authority names. Entitlement to
use a particular authority name can be linked to the secret key used to
generate it.
Aside from the criticism leveled against my poor choice of words in the
aforementioned statements, several readers complained about the lack of
more detailed information on the security technology used by Telescript,
namely, what cryptographic algorithms are used, key sizes, key
distribution and management issues, exportability issues, etc.
Let me start by saying that my posting was not meant as a treatise on
Telescript Technology but merely a brief description of some of the
features of Telescript that can be used effectively against misprogrammed
or ill-intentioned telescripts.
General Magic has already published a white paper entitled "Telescript
Technology: The Foundation of the Electronic Marketplace." This paper
provides a high-level description of Telescript and is intended for the
layman, not the techno-savvy reader. It can be requested directly from
General Magic by calling (415) 965-0400. In the coming months we will
publish additional information on many different aspects of Telescript
Technology (including security).
Let me further say that the point of my original posting was not that
Telescripted networks are intrinsically secure (i.e., the "it won't
happen here" syndrome). It was simply to let RISKS readers know that we
have put a lot of thought into the security aspects of Telescript. In
fact, when General Magic started developing Telescript, security was at
the top of our list of concerns. As a result, we have built into the
fabric of the language a number of features that, we believe, will enable
application developers to write safe Telescript programs and network
operators to run highly secure Telescripted networks.
Heretofore, the discussions on RISKS have only covered a few of the many
security issues faced by a dynamic, interpreted, communication-centric
language like Telescript. As more detailed information on Telescript
becomes widely available, I am certain it will generate heated debates on
this and other forums. I look forward to them!
-Luis Valente, General Magic, Inc.
------------------------------
Return to February 1994
Return to ““Alan (Miburi-san) Wexelblat” <wex@media.mit.edu>”
1994-02-27 (Sun, 27 Feb 94 11:14:18 PST) - Valente clarifies on Telescript - “Alan (Miburi-san) Wexelblat” <wex@media.mit.edu>