Re: Unique handle generation

[George Belotsky <george@register.com>]

An opaque identifier has plenty of uses (and provides some security,
too).

A vehicle license plate, for example, provides identification even if
you know nothing about its format.  With sufficient authorization, you
can get answers to queries such as 'who does this vehicle belong to',
etc.

Opaque identifiers have many uses, and are in fact frequently used.
We just have to determine if such identifiers meet our requirements.
If they do, then there are great advantages in using them -- most
prominently the elimination of the need to maintain a registry of
handles (or parts thereof).

George.


On Wed, Mar 14, 2001 at 08:20:42AM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: Patrik Fältström [mailto:paf@cisco.com]
> >Sent: Wednesday, March 14, 2001 1:31 AM
> >To: George Belotsky; Hollenbeck, Scott
> >Cc: ietf-provreg@cafax.se
> >Subject: Re: Unique handle generation
> >
> >
> >At 21.14 -0500 01-03-13, George Belotsky wrote:
> >>Scott:
> >>
> >>Here is an overview of the algorithm I had in mind, so that
> >>it is easier to understand the changes that I am suggesting.
> >>
> >>
> >>    (1) A human-readable object handle is created.  This
> >>        is done UUID-style, by concatenating several
> >>        atomic units.  The creating repository may be
> >>        one of these, but it does not have to be.
> >>        The end result is something like this.
> >>
> >>        Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001
> >>
> >>   
> >>    (2) A digest function is applied to the human-readable handle.
> >>        The system stores the resulting  digest, and not the readable
> >>        form itself.
> >>
> >>    (3) The readable form is returned to the user.  Now, there are
> >>        two equivalent representations: the digest (which is used
> >>        by default), and the readable form (which can be used
> >>        by the 'owner', or anyone else that the 'owner' gives it to).
> >>        This is the essence of [5] and [6] as I suggested; not
> >>        contradictory, but complimentary.
> >
> >I think you make life much too complicated.
> 
> I agree, too.  One of things that I don't like about digests used this way
> is that a registry has to maintain _three_ different identifiers for an
> object like a domain name:
> 
> 1. The name itself,
> 2. A combination of human-readable elements used as digest algorithm input,
> and
> 3. A digest (128 bits (16 octets) for MD5, or 160 bits (20 octets) for
> SHA-1, or more for newer algorithms -- fewer bits or weaker algorithms don't
> offer much collision protection)
> 
> I know that George suggested that the human-readable form doesn't need to be
> stored by a registry, but putting an opaque digest into a whois response (as
> an example) seems useless to me.  Take the digest out of the surrounding
> context and you have a meaningless string of characters.
> 
> If I'm reading this right, the real sticking point that we're continuing to
> debate is local part uniqueness, primarily if a repository ever has to join
> with all of the objects and identifiers from another repository.  I might be
> wrong, but I think this is a pretty rare corner case that we don't really
> need to optimize for.  I think a simple approach is best, and if collisions
> ever do occur they are best handled on a case-by-case basis -- which means
> that an object identifier could change if a new local part is needed to
> avoid a collision when integrating repositories.  However, if the identifier
> is going to change anyway as a result of the repository change, maybe this
> isn't a major issue.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
george@register.com
212-798-9127 (phone)
212-798-9876 (fax)