RCDS servers are associated (via the URI resolution process) with a particular subset of URI-space; it is assumed that the official RCDS servers for a resource are maintained or authorized by the owner of that resource. The owner or an authorized party must therefore provide permission and authentication credentials to a party before it can add assertions, certificates, or locations to an RCDS database. This provides a mechanism to ensure that only authorized catalog information or replicas are listed in the official servers. Nothing prevents an unauthorized third party from establishing its own RCDS servers, but (barring attack of the resolution system) those servers must be explicitly configured by the user - they will not be found by a normal URI resolution process.
The authentication required to update an RCDS server does not ensure the authenticity or integrity of a resource listed by that server; it is intended only to provide some protection against denial-of-service attacks. RCDS provides end-to-end authenticity and integrity assurance for ordinary files through the use of message digests such as SHA or MD5, and public-key signatures for assertions that a particular message digest represents a particular version of a file.
Public keys are of limited utility without a means of key certification. It may be possible to use RCDS to as a repository for key certificates - signed assertions from a well-known party that a particular public key is associated with a particular RCDS asserter or certifier. The difficulty is not with RCDS itself, but in finding a trusted certificate authority (or chain of intermediaries) that can verify the asserter's public key. While there appears to be no general solution to this problem (i.e. no single certificate hierarchy) that can be trusted for every authentication need, it is often possible to establish a hierarchy or ``web of trust'' for specific purposes.