[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Dart: Digital archives without patented techology
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz] Dart: Digital archives without patented techology |
Date: |
Fri, 18 Jul 2003 00:16:35 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 |
Benja Fallenstein wrote:
===========================================
Digital archives without patented techology
===========================================
Three additional notes about this dart.
First, we can make it so that you don't need to register with a deputy
before you can start using the system for yourself.
Instead, you could create an identity simply by creating a file
containing data identifying you, like--
name
address
e-mail
current public key
REQUIRED: the deputy you want to use
The hash of this file is your identity; URIs in your namespace could
look something like,
urn:x-foo:<hash>:<localname>
where <hash> is your identity.
You can then start to use the system off-line, and signatures will be
axiomatic (the hash of 'signed' messages will be stored in a list on
your harddisk, and anything in that list will be considered signed by you).
Later you can go online, and send the identity file to the deputy you
picked, and authenticate yourself to the deputy using the information
from the identity file (most simply, the public key). Then you can
submit (the hashes of) the messages on your harddisk to the deputy to
acquire a real, global signature on them.
To resolve x-foo URIs, people would need to have your identity file.
They'd check the hash of the identity file against the hash in the URI.
If it matches, they would accept any signature that is given by the
deputy named in the identity file.
So you could acquire a global, deputy-based id without going online,
when setting up your Storm system. (You'd need to do this once before
you could create pointers in Storm.)
Second, I think the system easily extends to documents that can be
changed by groups of people, e.g. a CVS repository. Simply have the
deputy authenticate signatures from any member of the group. For each
member of the group, register that member's public key as one that can
sign promises for the group.
When a member leaves the group, revoke that member's public key for use
in that group.
Third, the deputy hierarchy can be used to provide mnemonic, DNS-like
names for documents. For example,
urn:x-deputies:foo:fenfire:manifesto
The root deputy would name the first-level deputy (foo); the first-level
deputy would name the second-level deputy (fenfire) which would name the
document.
A message would be signed by urn:x-deputies:foo:fenfire:manifesto's
owner if the root deputy says that 'foo' says that 'fenfire' says that
'manifesto's owner signed that message.
Of course, in accord with URN policies, a name must never be reassigned.
This would be a way to implement the "URI-on-the-side-of-a-bus" thing in
our framework, with secure histories provided for these URIs.
- Benja