Re: Registration request for urn:eris: namespace

> Namespace Identifier:  ERIS
> Version:  1
> Date:  2023-09-16
> Registrant:  Endo Renberg <[email protected]>

My overall impression of the Eris proposal is difficult to describe.
Perhaps the best term is "experimental", in that there is a lot of
important stuff here but further thought and description is needed.

In regard to the immediate need, I might suggest assigning an "informal"
namespace, e.g., "urn-8", for current usage, and when the practical
issues are clarified, to assign a formal namespace.  RFC 8141 says that
the requirements for an informal namespace are essentially the same as
for "formal" namespaces but the practice seems to be to apply much less
strict examination to their definition.

Some questions that I have are the following.  They are not listed in
any significant order.

1. To what degree are Eris URNs being used in practice?  Ideally, there are
systems working on a day-to-day basis that use them.  The impression I
get is that this proposal is a well-worked-out part of a generic
distributed system that does not yet exist.

2. The nature of Eris URNs is unusual, in that while they do not provide
direct information for locating a resource, they are only used to locate
resources, that is, they have no particular value except when one is
retrieving a resource.  I'd like to suggest that the authors back away
from looking at the URNs solely as the inputs and outputs of particular
algorithms and also look at them as abstract identifiers.

One idealization is that the NSS can be divided into two parts, one that
identifies/names the block of information and one that is used to decode
that block of information.  I'm pretty sure that isn't what's happening
here, as the the "convergence secret" concept forbids always having the
same resource content generate the same text in part of the URN.  But
I'd like to see a description of the URNs and how they and their parts
behave, from the point of view of a set of abstract identifiers.

Ideally, this sort of abstract discussion of Eris URNs would be fairly
simple and clear; simplicity and clarity of abstractions is a sign that
implementation difficulties are less likely to arise.

3. The Eris scheme has a fixed set of cryptographic algorithms and there
is no mechanism to update with newer ones.  How much are you prepared to
wager that these particular algorithms will be useful in practice 50
years from now?  I would recommend adding a versioning element in the
URN, perhaps something as simple as putting a fixed "A" after
"urn:eris:" and before the 106-character NSS.  The "A" could be replaced
with other BASE32 characters if additional URN formats are needed to
support additional algorithms.

4. The proposal seems to be ambiguous about security.  All of the
content is encrypted with keys of significant length and the text
declares "Intermediary peers, who are storing and transporting encoded
blocks without access to a read capability, can claim that decrypting
encoded content is infeasible for them."  And yet the test also says
"Confidentiality is not an objective of ERIS and ERIS SHOULD NOT be used
to ensure that content is kept secret from an adversary."  Which is
intended?  If the scheme *appears* to expend effort to provide privacy,
the scheme should be designed to provide privacy.

5. Presumably the intended retrieval mechanism is to use a URN as input
to some process to identify servers that might contain the resource,
followed by delivering the URN to those servers, which use it to locate
the resource.  What assurance is there that the structure of the URN is
suitable for this?  I think that the desired property is that any
initial substring of the NSS is expected to be uniformly distributed
over the space of all such BASE32 strings, and probably this is the only
useful property that can be specified for this sort of identifier.  But
these considerations should be described explicitly (including so that
the authors can assure themselves that a location process can be
implemented).

Dale