- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Thu, 20 Jul 1995 07:30:13 PDT
- To: sollins@lcs.mit.edu
- Cc: uri@bunyip.com
> 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.
Received on Thursday, 20 July 1995 10:31:04 UTC