[p2p-hackers] [i2p] naming ideas (fwd from derick_eddington@yahoo.com)

Eugen Leitl eugen at leitl.org
Tue Sep 14 06:15:12 UTC 2004


----- Forwarded message from Derick Eddington <derick_eddington at yahoo.com> -----

From: Derick Eddington <derick_eddington at yahoo.com>
Date: Mon, 13 Sep 2004 18:05:08 -0700 (PDT)
To: i2p at i2p.net
Subject: [i2p] naming ideas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been thinking a little about naming and I have a scheme
I'll throw out here.

SDSI and PNML have naming-paths denoted with an apostrophe-s
syntax, ie: "Bob's eepsite" or "<pn>Bob<s/>eepsite</pn>".  (I
like dot syntax, like "Bob.Eepsite", better so I suggest that.) 
The user's addressbook has a sub-addressbook for "Bob" of
name=>dest supplied by Bob in which "eepsite" would be looked
up.  Sub-addressbooks could also name other sub-addressbooks so
name-paths like "Bob.Brother.blog" could be done.  Compared to
a one-level addressbook, I think this would greatly reduce the
hassle of name collisions and everyone having to try to think
of unique names to suggest for all their dests and likewise for
users needing to come up with names (not that this couldn't
still be done).

Nyms could have signing keys.  They are GUIDs for the nym and
with which nyms sign and publish their addressbooks as and how
users associate their chosen name for the nym with their local
sub-addressbooks for the nym.  This would securely associate
multiple destinations with a nym and could allow for revocation
of compromised destination keys and updating of the new dest
for the name.  (Is there anything beyond the obvious in the
threat model and implications of destination key compromise in
I2P?)

When I2P gets big, having to maintain your local address book
and keep in sync with all the published names could become too
burdensome.  A remote querying protocol could exist and name
service providers could specialize in maintaining and providing
a massive number of names.  They would have a nym GUID/pubkey
and users would name it whatever they want (ie "NamesRUs") and
have a local sub-addressbook for them; in the sub-addressbook
would be a standardized name like "resolver" which points to a
destination which provides the remote querying service.  When
you say "NamesRUs.AcmeCo" and "AcmeCo" is not already in the
sub-addressbook, "resolver" is queried for it.

This has the benefits of:

* distributed and decentralized

* under the control of the user

* interesting possibilities for naming-path combinations from 
  addressbooks exported by disparate entities

* few if any collision and coming-up-with-names hassles

* revocation of compromised destination keys

* possible potential for some sort of reputation web-of-trust 
  integration

* able to choose and simultaneously use multiple name service 
  providers which overcomes having too many names for users to
  manage (the benefits of DNS), as well as having the above 
  attributes


Derick Eddington

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iQIVAwUBQUZA17YUeoIU0wXLAQILVQ/+IQW7Dv5XWwwOu2rBQSWSUpeiJOrXQE3R
zMfHsxDKtsU+PjWPRbRgw1fqVxN4ddm5gcZEIs2XjKTq4So6bCXaCr9XqTqVcQh6
ndeVXqT2kP8n8ofkfLQqeorEpcFHKyXmOrPtQxNggL8oQGQMOgmRlT0fW0dcxKYY
/Ezcp30ufkwbcpAF7sRXHs6IoQfeotz71oFfRDOE0sV6KQEqGpDS068oGO1A1TjK
iRB4RdsuIiV0C9wQld9f5bs7/pcv/ogFl32yYjWCG4QD8xzZjYTwB1/ytqCbKzUn
w5Sh1pI3n3hiVt9GR7ByKn4P4yYQebPbdI1tM0H75NFQA1w6p18ab0sV5ogDcxsi
jJBcFCfZmngLCq9Sbdr+3elVC6jsy9zCyYeeY19r4w7DFFDS8ArmcH3zrevtbusE
zuRSHR0YcsKmycTRZ8AVMp8k4220Na4ztjDigfOMIFRNKLXq89G/vg0ox7Esfo9M
RH8Vt2cZjtIh7w0u1OvWQfq6FJU1jTCugmgFnnm5sbzSUf0xTY6OPPreoGaZnJNr
VL5WgL0oxFUQiJK1qvXOvi7rZlJ/LClZcx5FH+H39iP1TsbT4C0x6YdKY+QwkotA
8eRJeBEw96I9w5pV0l8ramNUiNHXNpnpgt6QmCa+dnEl2hVs2X1YZcPIrwwJSNRP
jtviTFuekJ0=
=da+i
-----END PGP SIGNATURE-----






	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
_______________________________________________
i2p mailing list
i2p at i2p.net
http://i2p.dnsalias.net/mailman/listinfo/i2p

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20040914/63e67fb0/attachment.pgp


More information about the P2p-hackers mailing list