204 |
- Then, given a path like ``foo/bar/baz``, we can |
- Then, given a path like ``foo/bar/baz``, we can |
205 |
find out who ``foo`` is, according to the root; |
find out who ``foo`` is, according to the root; |
206 |
who ``bar`` is, according to ``foo``; and who |
who ``bar`` is, according to ``foo``; and who |
|
``baz`` is, according to ``foo/bar``. |
|
207 |
|
``baz`` is, according to ``foo/bar``. |
208 |
|
|
209 |
|
When any of the keys is revoked, the corresponding |
210 |
|
entity can ask its parent identity to sign a new key. |
211 |
|
The root identity will need out-of-bounds means. |
212 |
|
|
213 |
|
Clearly, a parent entity can misrepresent a child |
214 |
|
entity-- ``foo`` assigns a key of its own to ``bar`` |
215 |
|
and can further on sign messages in ``bar``'s name. |
216 |
|
|
217 |
|
It isn't the Storm-using Web surfer who needs |
218 |
|
to put trust in the parent entity, then. |
219 |
|
It's the child entity-- because the parent |
220 |
|
entity can misrepresent the child entity. |
221 |
|
In fact, an entity needs to trust *all* its |
222 |
|
ancestor entities. |
223 |
|
|
224 |
|
(Just like your web hosting company can take your |
225 |
|
pages online and replace them by something else; |
226 |
|
it's the web page author who needs to trust the |
227 |
|
hosting company, not the person reading the page.) |
228 |
|
|
229 |
|
In fact, I believe the problem *cannot* be solved |
230 |
|
without having to trust somebody: Because you cannot |
231 |
|
guarantee that your private key will not be exposed, |
232 |
|
you need to give somebody else the right to assign |
233 |
|
you a new key; which means you need to trust them |
234 |
|
not to assign your key to someone else. |