Message-Id: <199404261544.JAA24152@idaknow.acl.lanl.gov>
To: hoymand@gate.net (Dirk Herr-Hoyman)
Subject: Re: Yet more URI/URC
In-Reply-To: Your message of "Tue, 26 Apr 94 09:14:00 EDT."
<m0pvmyE-0004JMC@inca.gate.net>
Date: Tue, 26 Apr 94 09:44:44 -0600
From: rdaniel@acl.lanl.gov
hoymand@gate.net (Dirk Herr-Hoyman) wrote:
> At 11:14 PM 4/25/94 -0400, Peter Deutsch wrote:
>
>>> But, I see your point and I don't see how one can prevent "bogus" URN
>>> servers from springing up, short of cutting 'em off at the knees by
>>> preventing their INITIAL lookup. Does this imply Network URN police (sigh
>>> :-()?
>>
>>I don't see that this will be needed. The purpose of the
>>naming authority portion of the URN that we proposed was to
>>permit control over who gets to perform the conversion on
>>that naming authority's behalf. I'd originally thought of
>>using the IANA to maintain a registry of naming
>>authorities but I now agree that using DNS (which also has
>>a mechanism for guaranteeing authority and it has the
>>advantage of being distributed) makes more sense. Once we
>>have that in place, than distinguishing between:
>>
>> urn:myname.urn.int:war-and-peace
>> urn:yourname.urn.int:war-and-peace
>>
>>is easy. The first gets resolved by "myname.urn.int" and
>>the second by "yourname.urn.int" (and apologies if I have
>>the syntax on this wacko. I'm not proposing an
>>alternative, I just don't have the details handy).
>>
>Peter, you may know more about this than I do, but I don't take great
>comfort DNS authority granting mechnisms preventing folks from creating
>bogus URNs. I think access to the URN namespace will be readily available.
> Just like access to DNS is. Again I ask, who is going to be watching?
There are several possible interpretations of "bogus URNs" and I am not
sure which of them Dirk is worried about. The first is the one Peter
addresses - where a resource published by one publisher gets another name
assigned to it by another publisher. I agree with Peter's analysis that
this can have many legitimate uses, is likely to arise, and is nothing to
worry about in particular. (There is the case of outright theft, but that
can be handled in a fashion similar to current cases of theft. We don't
have to come up with automated net.cops to detect that sort of thing.)
Another interpretation of "bogus URN" is where a malicious person
forges things so that they appear to be published by a particular
publisher. This can happen in several ways. First, they could just
pick a random opaque string and make their own URN in the publisher's
namespace. They send this to some official URI server, which may not
be secure. At that point, they have a URC on the publisher's official
URI server(s) and can provide whatever they want with what appears to be
the blessing of the publisher. Another scheme is where they spoof DNS so
that a counterfeit URI server appears to be in the list of the publisher's
"official" servers. If they can do that, then they can provide whatever
they want to in response to the publisher's real URNs.
Current discussions of the URI server center around using whois++. This
is not secure system, although it does offer clear-text passwords as an
optional authentication mechanism. In an earlier message
<URL:http://www.acl.lanl.gov/URI/archive/uri-archive.messages/1224.html>
I had put forth what I considered to be some of the necessary operations
for the URI service. This included such things as registering a new URN,
registering and deregistering URLs for existing URNs, adding and deleting
material to the URC for existing URNs, etc. For security I suggested that
the operations would have a signature that was encrypted with the private
key of the publisher. The URI servers would fetch the public key and verify
the operation before performing it. This would address the problem of
forging a URN, but it does nothing to secure DNS against unauthorized URI
servers appearing as offical ones. That's just the way DNS is.
I should note that my earlier message also suggested that URNs have
an operation field added to them, a scheme that I no longer advocate.
However, I still believe that registering new URNs, URLs, etc. should
at least have the option of requiring authentication, and that digital
signatures are probably the best way to do that. I don't know what other
people are thinking of for maintaining URCs, but I tend to think of them
as being updated remotely, rather than requiring an administrator to
edit them. Because of this, there are more stringent security
requirements.
Ron