URN Resolution Security and Privacy Issues

Mark Madsen (msm@ansa.co.uk)
Tue, 11 Jul 95 10:34:41 BST

From: Mark Madsen <msm@ansa.co.uk>
Message-Id: <9507110934.AA27512@euclid.ansa.co.uk>
Subject: URN Resolution Security and Privacy Issues
To: pierre@indirect.com
Date: Tue, 11 Jul 95 10:34:41 BST
Cc: uri@bunyip.com, msm@ansa.co.uk
In-Reply-To: <199507101918.MAA15589@bud.indirect.com>; from "Pierre Landau" at Jul 10, 95 12:18 (noon)

Pierre Landau wrote:
> > From: Fisher Mark <FisherM@is3.indy.tce.com>
> > Because the mere knowledge that a string is a valid URN can useful in some 
> > contexts, it is advisable to have mechanisms that prevent the discovery of 
> > this fact.  Any generally useful resolution service must be able to not only 
> > refuse to resolve a URN (or URL), it must be able to avoid giving the 
> > impression that what was handed to it was a valid URN or URL to begin with. 
> Maybe I'm missing something here.  My understanding of the motivation 
> behind the creation of a URN was to say "I'm now publishing something I 
> want people to read/use/whatever; here's a persistent name for that object."

Creating a URN binds a persistent name to an object.  It's not
necessary to predict in advance what the motivation for that future
requirement will be.

> Any URN registry service must be able to answer the question of whether a 
> URN exists in order to decide whether it can be assigned to a new object.

All it necessarily needs to be able to do is issue a new URN.
Authorship is distinct from naming.  Chapman & Hall didn't ask me what
I wanted the ISBN of my new book to be, and I didn't give them an ISBN
and ask whether it was taken already.  They are the naming authority
in this instance,, so they just assigned it.

> If you're playing with confidential information, what is it doing on an 
> essentially public network, where security is basically nonexistent?

As Larry has already pointed out, this is a short term view of the way
the Internet works.  The goal of every IETF working group must be to
develop support for the kinds of things that people will want/need to
do on/in/across the Internet.  Note the future tense.

Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779