/[storm]/storm/doc/dartboard/pointer_identities--benja/idea.rst
ViewVC logotype

Diff of /storm/doc/dartboard/pointer_identities--benja/idea.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by benja, Thu Jul 10 00:45:46 2003 UTC revision 1.3 by benja, Thu Jul 10 01:04:39 2003 UTC
# Line 176  feeling that they're similar in a fundam Line 176  feeling that they're similar in a fundam
176  Hm. Comments appreciated.)  Hm. Comments appreciated.)
177    
178    
179    A first cut at the problem
180    ==========================
181    
182    So, let's examine how the above work out for Storm.
183    
184    - We cannot use key-based identity for pointers because
185      any private key can get exposed-- that's the motivation
186      for this document.
187    - Using axiomatic identity would mean that for every
188      entity signing pointers, we would have to establish
189      out-of-bounds (manually) who they are, *before we can
190      read any documents from them*. Clearly infeasible.
191    - So we're left with hierarchical identity, which works
192      for DNS. (Of course, we need a root for the hierarchy;
193      since key-based is out, its identity must be asserted
194      axiomatically, as in DNS.)
195    
196    A first cut:
197    
198    - We have a root entity whose public key is specified
199      through out-of-bounds means (e.g., "download from
200      http://himalia.it.jyu.fi/pubkey").
201    - The root entity gives names to other entities and
202      signs ``(name,pubkey)`` pairs with its own key.
203    - The other entities can do the same.
204    - Then, given a path like ``foo/bar/baz``, we can
205      find out who ``foo`` is, according to the root;
206      who ``bar`` is, according to ``foo``; and who
207      ``baz`` is, according to ``foo/bar``.

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26