Re: URI deconstructed

Larry Masinter (masinter@parc.xerox.com)
Thu, 20 Jul 1995 07:30:13 PDT


To: sollins@lcs.mit.edu
Cc: uri@bunyip.com
In-Reply-To: "Karen R. Sollins"'s message of Thu, 20 Jul 1995 03:23:37 -0700 <199507201023.GAA09387@lysithea.lcs.mit.edu>
Subject: Re: URI deconstructed
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <95Jul20.073021pdt.2762@golden.parc.xerox.com>
Date: Thu, 20 Jul 1995 07:30:13 PDT

> I will say this again in the meeting this afternoon, but for those of
> you not in Stockholm, I have a concern about coordination among a
> multiplicity of groups.  For example, I see a gaping hole in this -
> authenticity, integrity, and access control.  I do not beleve that all
> the problems have been solved, so it is merely a matter of applying
> existing technology, but even if that were true, or the problem were
> reduced to a state where that were true, it is in no one's agenda to
> do that.

Karen, I agree that coordination among a multiplicity of groups is an
issue, but I think the particular issue you've raised--authenticity,
integrity and access control-- is not shared by most of the new
groups, but rather is the primary focus of (C) "resolution" and
possibly (B) "URC syntax & structure". 

A group that is focused on resolution can possibly deal with
authenticity, integrity, and access control more easily than one that
also must worry about the syntax of the 'mailserver' URL.

> I bring this up not only because the suite of security problems need
> addressing, but also because they may be an example of major issues
> not addressed.  I am concerned specifically about those aspects of an
> architecture which should not be add-ons after the fact, but should be
> part of the initial design.

The URI working group hasn't been a useful forum for developing
architecture, and so we're looking for good places to do that. 

> I don't have a particular ax to grind, but rather want to make sure
> that we don't do something that ends of useless or rejected by the
> community because it has gaping holes, by focussing ourselves on a
> narrow disjoined set of tasks.

I think that you and I may find ourselves working on the architectural
issues someone outside of the IETF structure; now that the URI mailing
list is no longer the official mailing list for an IETF working group,
it is now an appropriate place for us to talk about these issues.

The basic observations are:

* metadata is like data: it's necessary to provide the same mechanisms
  for authenticity, integrity and access control

* location information is a kind of metadata

* there exist mechanisms for checking authenticity and integrity for
  mail that should work for data transmitted over insecure protocols.

* we do not yet have a protocol independent way of specifying access
  control but probably could

* other mechanisms for authenticity and integrity verification and
  access control are likely to be protocol specific.