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``. |