On 1/27/06, Thomas Lord <xxxxxx@emf.net> wrote:
>
>   Well, really, the question comes down to "what are these names
>   for"?

This is indeed the question.  With respect to Zooko's Triangle,
human-readable and decentralized seems to be the natural choice - at
least that's what other module systems use.  Let's consider what it
would mean to have secure module names.

There are, as the triangle indicates, two ways to handle this:
decentralized, in which case the name itself is a digital signature
proving the name belongs to a specific entity, or centralized, in
which case you have a central trusted authority somewhere (such as at
schemers.org) which maps names to entities (and vice versa).

At first sight, the digital-signature naming of modules such as
"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" is just silly.  No one
would write code like that, you'd always be looking at documentation
and web pages for module names and cutting and pasting them.  The
notion of petnames (or similary some sort of project-wide lexically
scoped aliases) is interesting, and possibly brings this back into
consideration.  There are a number of drawbacks, however.  The first
is the need for tool support, which we don't have yet and would take
time to spread to all the different tools and implementations in use.
The tools also wouldn't necessarily work in all situations, and may
not play with other tool-chains and idioms - if I grep through code
for a module I'd need to grep by the unwieldy signature, not my
petname.  Furthermore, communication is hampered when people may be
using different names.  Programmers wouldn't necessarily know if
someone else's "html" module refers to Bob's HTML library or Alice's.
Collaboration, education and presentations suffer.

For a centralized naming authority, we'd setup some sort of
registration system at a server like schemers.org, and delegate module
namespaces to separate "entities," either organizations or individual
authors, presumably identified uniquely by a public key.  This is
complicated, rigid and doesn't scale well.

Rather than establish our own authority we could try to leverage an
existing one, as Java does.  com.microsoft.foo.bar is reserved for the
owner of the microsoft.com DNS name.  This may not be the most
suitable level of entity for an authorization system.  The example
above could either refer to the foo.bar module of microsoft.com, or
the bar module of foo.microsoft.com, which for Microsoft Corporation
may not be such a problem, but for other hosts that conflict may be
unacceptable.  The naming is also not actually enforced by any of the
Java tools - nothing is stopping me from distributing my own
com.microsoft modules.

All this, of course, has nothing to do with the security of the code
itself.  It just provides a module-name<->entity mapping.  In and of
itself, it doesn't even guarantee that the owner of the module name
wrote the code that it's attached to.  If using a DNS-based authority
you could restrict it so that a com.microsoft module can only be run
or installed if being accessed from a microsoft.com server.
Alternately if using a schemers.org key-server you could require that
the module code itself be signed by the same entity as that owning the
module name.

The question arises, since for any security considerations at all
we're going to need to authenticate the entire module anyway, does the
_name_ of the module itself need to be authenticated?  As you say,
"Does it really matter?"

Imagine web browsers can launch Scheme applets, similar to Java
applets but done right.  Web browsers access a page with an <applet
language="r6rs" ...> tag, the code is downloaded and signature
verified, and a dialog pops up:

  Applet Name: XXXX

  Author: Acme.com (optionally shown as petname or with other trust
                    or past applet use info)

  Desired Capabilities: (with big flashing warning signs because it's
                         asking for a lot, or possibly just a summary
                         "This applet can do anything to your computer,
                          run at your own risk!")
    * local file access
    * network access
    * eval

  X Don't ask again when running this applet
  - Don't ask again when running modules from Acme.com

At first glance the XXXX name of the applet (module) itself is
meaningless.  "Don't ask again" only works on the signature of the
code itself and the entity, not the name.

Now consider that, unlike Java, we actually write reusable code, and
share modules with third parties.  So Acme.com may import Bob's List
Library.  The page could tell you to download and install such and
such a library, or for more automatic use refer to central or
distributed repositories of known code, or even link directly to
.jar's or .scm's in the <applet> tag itself.  When the module is run,
the dialog confirmation will show for all new modules.  Bob's List
Library shows as requiring no capabilities (it just uses CONS, CAR and
CDR), or possibly even is loaded without confirmation because of this.

It's at this stage where there's a possibility of attack based on
module names, if the module names are the only means the modules have
of referring to one another.  If Acme.com uses Bob's Library, it will
point directly to safe URL's or repositories, and even if it just puts
a notice "you need to install Bob's List Library version >= 2.1," with
no link, then when people will Google for said library and come up
with the correct link (without really ingenious and well-timed SEO).
However, the villain Charlie comes along and puts on his own site a
link to an applet saying "hey, check out Acme.com's new domestic
animal hunter game!"  You've heard of the game and decide to try it
out, the applet verifies the game and the author Acme.com, along with
some other incidental modules such as "Bob's List Library" which
verifies and requires no capabilities so you click OK.  However, Bob's
List Library was actually written and verified by Charlie's key, and
although it itself has no capabilities, it has been cleverly designed
to return bad data back to the calling Acme.com module in certain
situations such that security is compromised (perhaps URI's are
manipulated in list representation, and when the result is '(http
acme.com login.cgi) it instead arranges for the login info to be sent
to Charlie's server).

So even with full digital signatures and an elborate trust system and
petnames, code can be compromised if modules refer to each other by
name and those names aren't secure.  There are a number of ways to
resolve this, the first and most obvious of which in the above example
is for the <applet> tag itself to be signed by the same entity as the
applet, or to include signatures for the modules it uses.  Alternately
you could de-emphasize the fact that the List Library uses no
capabilities, and prominently give a dialog of all authors with all
capabilities the collection of modules accessed by the applet -
trusting Charlie's code in that situation is the same as installing
unknown software from Charlie.

And we can, of course, simplify things by deferring to other
authorities.  If module names are based on domain names, then we could
use Yahoo Domain-Keys as the signature method.  In this case when you
verify (schemers.org srfi 1) against the public key stored in the DNS
TXT entry for _domainkey.schemers.org, you simultaneously know that
both the code _and_ the name are valid.  This is very close to
having all three points of the triangle.

--
Alex