Authentication of a resource verifies that the resource was published by its purported publisher. Verifying the integrity of a file ensures that the file has not been modified. Provisions for authenticity and integrity checking are necessary for a software repository because there have been multiple instances of software packages stored on a public repository that were modified by intruders to introduce security holes which were then spread to other systems. Our authentication and integrity mechanisms are similar to those described in [6].
Recall from Section 2 that a publisher cryptographically signs the description for a resource. In the case of a file resource, this description includes the file's LIFN and MD5 fingerprint. Any client in possession of the publisher's public key can verify the authenticity of the resource description. Publishers are expected to widely advertise their public keys to make it difficult for an attacker to substitute rogue keys. In addition, publishers may have their keys certified by trusted third parties to further establish their authenticity, as in [6].
Assuming that the association between a LIFN and a file signature (e.g., the MD5 fingerprint) is known to be correct (either because the signature is part of the LIFN or because of the description authentication described in the preceding paragraph), a client may perform an integrity check on a retrieved file by computing the signature for the file and comparing it with the one known to be associated with the file's purported LIFN. Recall from Section 3 that a LIFN server returns a list of locations for a given LIFN but does not guarantee the correctness of those locations. A location may be incorrect if it no longer exists or if the contents of that location are wrong. In the former case, no file will be returned from that location. The latter condition may be detected by the client performing an integrity check.
To avoid the overhead of the client having to perform authenticity and integrity checks for every file accessed, however, we plan to use an authentication system for LIFN and URN servers and for file servers. A client program will be able to cache naming-authority to LIFN(URN)-server-IP-address mappings and authenticate these mapping by contacting the LIFN (URN) servers. Furthermore, the LIFN servers for a particular naming authority will allow only authorized trusted file servers to register locations for that naming authority's files. Update requests from file servers to LIFN servers, as well as the batch update protocol between LIFN (URN) servers, will require authentication, so that only authorized servers can store locations in the naming authority's LIFN and URN databases. Such authentication may be based on public keys, shared secrets, network addresses, or some combination of these.
To spare clients from performing an integrity check on every retrieved file, a trusted file server must be able to guarantee that a file it returns for a particular LIFN is correct. The guarantee can be provided in at least two ways. One way is for the file server to maintain a LIFN-to-filename mapping for the files it serves, to guarantee that this mapping is correct, and to accept file requests in the form of LIFNs. A LIFN server would still return one or more URLs for the LIFN, but the LIFN would be substituted for or added onto the pathname portion of the URL. Such a file server could be implemented with current HTTP servers by means of a CGI program. A file server could also guarantee correctness of the file returned for a LIFN by never reusing filenames, even for updates to a file. This restriction would require changing from the present-day practice of using a filename as a stable reference to the current version of a file.
File servers will be expected to inform
the location database in advance of deleting a file to minimize
the likelihood of ``stale'' file locations, locations for which
the corresponding files have been deleted. A file server will
supply a location-time-to-live value when it posts a location
for a file. Specifying a location-time-to-live value of 
constitutes an agreement that the file server will not delete the
file without informing a location server seconds in advance of
doing so. The location server can then adjust that value by subtracting
an estimated upper bound on the time to propagate updates between
LIFN servers, and LIFN servers can then include a location-time-to-live
value in responses to location queries for use by clients or proxy
servers in maintaining a cache of LIFN-to-location mappings.
To ensure consistency within a group of
related files (e.g., a software routine plus all the routines
in its call tree) we allow a LIFN to represent a list of component
LIFNs. A query to the LIFN
database may therefore return a list
of component LIFNs instead of a list of locations.
The LIFN server might optionally also return
a location list for each of the component LIFNs in the same response.
Current WWW clients,
such as Mosaic, are not capable of retrieving a group of
files in one action, so
we are developing a WWW client that will have this capability.
Our client will then download a consistent set of files to
a specified location on the user's disk.