URN Resolution Security and Privacy Issues (fwd)

Pierre Landau (pierre@indirect.com)
Mon, 10 Jul 1995 12:18:32 -0700 (MST)


From: Pierre Landau <pierre@indirect.com>
Message-Id: <199507101918.MAA15589@bud.indirect.com>
Subject: URN Resolution Security and Privacy Issues (fwd)
To: uri@bunyip.com
Date: Mon, 10 Jul 1995 12:18:32 -0700 (MST)

> From: Fisher Mark <FisherM@is3.indy.tce.com>
> To: "'URI'" <uri@bunyip.com>
> Subject: URN Resolution Security and Privacy Issues
> Date: Mon, 10 Jul 95 11:41:00 PDT
> Message-Id: <30017541@MSMAIL.INDY.TCE.COM>
> Encoding: 29 TEXT
> X-Mailer: Microsoft Mail V3.0
> Sender: owner-uri@bunyip.com
> Precedence: bulk
> 
> 
> 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."
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.
If you're playing with confidential information, what is it doing on an 
essentially public network, where security is basically nonexistent?