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?