[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HIP and PKI reqs [RE: Identifier/locator recap]



On Mon, 17 Mar 2003, Pekka Nikander wrote:

> > This could work extremely well except for one tiny problem: what if some
> > nodes don't cooperate and don't follow the protocol?

> You just take a different hash (or a different part
> of an hash), and try again.

Hm, this means that there must be a record with a cryptographic
signature for every possible entry, including non-existing ones so a
node can't fake a "doesn't exist" message. But I still don't like the
idea of having to depend on some random servers somewhere on the net
that I have no influence over.

> > This is essentially the same old problem: looking up entries in huge
> > piles of data that lacks a hierarchical structure simply doesn't scale.

> Yes it does, if the data is randomly distributed.

> If it is hierarchical, you can use a tree structure.
> If it is randomly distributed, you can use a hash structure.

Ok, I should have mentioned some constraints, mostly "distributed". In a
tree, you can delegate sub-trees to organizations. When using a hash (or
a simple flat space that can be searched using binary search) stuff from
different people ends up on one pile so you need some level of trust to
make it work.

> > I really think the FQDN is the
> > actual identifier here, not the HIP id.

> There we have the difference.  Computers don't understand names.
> Names are just bit strings to them.  Public keys make *re*cognition
> possible to computers, just like faces make it to people.

This is a good comparison. Yes, we recognize people by their face, but a
face is not what identifies a person, that's their name and some extra
info to discriminate against people with the same name.

It is a very useful feature if computers can recognize other computers,
but it's only relevant if they can translate this into something a user
can understand, like: "this message was authenticated as written by
jbezos@amazon.com" or "you are now communicating securely with
ietf93registration.ietf.org". In other words: to the user, the
identifier is the FQDN or an application-specific name (usually based on
a FQDN). (But it's ok if there must be some additional mapping between
internal stuff and user stuff.)