forked from cheng/wallet
159 lines
8.7 KiB
HTML
159 lines
8.7 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>Functional Specification</title>
|
||
</head>
|
||
<body>
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
<h1>Functional Specification</h1>
|
||
<p><br/>
|
||
</p>
|
||
<p>A functional specification is a pile of mockups of the user interface,
|
||
telling a story of what the software will do for users, explaining how the
|
||
program will behave externally. </p>
|
||
Humans have been identifying themselves with shibboleths for thousands of
|
||
years, and frequently killing each other in large numbers on the basis of
|
||
shibboleths.
|
||
<p> So it seems to me that the way to go is to have the front end, the user
|
||
interface for most users, shibboleth based (username and password), while
|
||
the backend uses public keys, and all the other tools at our disposal, to
|
||
make shibboleths resistant to dictionary attacks and man in the middle
|
||
attacks. The user, therefore, should ordinarily control the private key by
|
||
username and password. </p>
|
||
<p> Here is one such proposed system, intended to implement Zooko’s
|
||
triangle: </p>
|
||
<p> The end user creates an account with username and password on an
|
||
identity server, which may be running on the cloud, or on his company
|
||
server, or on his home network. He gets the hash of a rule identifying
|
||
public keys that are valid for him, and his username, and how to contact
|
||
him while he is logged in. </p>
|
||
<p>Now if any user actually sees that hash, contact information, and so
|
||
forth, they will reel back in horror. It absolutely has to be
|
||
hidden, or else users will boggle. We stick it in the avatar icon,
|
||
and/or reference it by the petname.</p>
|
||
<p> Many people can have similar or seemingly identical avatars, and people
|
||
on different servers can have the same nickname, one’s nickname being
|
||
one’s username on a particular identity server. </p>
|
||
<p> When he is logged in to that identity server, he can message other
|
||
people, and other people can message him. To message someone, you need
|
||
their avatar containing their public key. Any such avatar will be assigned
|
||
a petname that is unique for any end user, so if someone communicates with
|
||
two different people, with two different public keys, they will always be
|
||
identified as having two different names, even if they both have same
|
||
nickname. </p>
|
||
<p> So if I get two people whose nickname is Bob, my software will insist on
|
||
me differentiating them with different names before I can message them. </p>
|
||
<p> The end user should have on his local computer and on his identity
|
||
server data structures that looks like a browser bookmarks list, except
|
||
that the favicons can be quite large (can be user avatars), the entry
|
||
generally contains public key information about the target (or the hash of
|
||
the rule identifying public keys valid for the target), and the entry may
|
||
contain username and password information for mutual identification, after
|
||
the fashion of otr. </p>
|
||
<h3>Communicating public keys:</h3>
|
||
<p> The problem is that you want to tell someone over the phone, or on a
|
||
napkin, or face to face, information that will enable his client to
|
||
securely obtain your public key and network location so that end to end
|
||
secured communication can take place.</p>
|
||
<p> Also a chatroom’s public key and network location.</p>
|
||
<p> We do not necessarily protect against security agencies figuring out
|
||
which public key is talking to which public key. That issue is out
|
||
of the scope of a functional specification, but we somewhat reduce the
|
||
usefulness of this information by allowing people to have lots of public
|
||
keys. So you probably have one key for activities that show your
|
||
unusual sexual preference, another key for job related activities, another
|
||
key for tax evasion related activities, another key for gun running, and
|
||
yet another for attempts to overthrow the regime.</p>
|
||
<ul>
|
||
<li>
|
||
<p> Face to face:</p>
|
||
<blockquote>
|
||
<p>Identifying information is nym, face, and location.</p>
|
||
<p> Recipient looks up the nym, sees a bunch of faces grouped by
|
||
geographic area. Geographic are usually, but not necessarily,
|
||
has some relation to users actual location, and may be very
|
||
specific, or very broad. It is a tree. One guy may
|
||
locate his face at the node "North America", another at the node New
|
||
York, North America. You may, of course, employ a well known
|
||
cartoon character or movie star as your avatar instead of your
|
||
actual face. Fictional places are permitted, but to
|
||
avoid filling the namespace, not on the tree that represents the
|
||
real planet earth.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>
|
||
<p>Over the phone.</p>
|
||
<blockquote>
|
||
<p>Recipient looks up phone number. Finds a bunch of named keys
|
||
associated with the phone number – usually one key or a quite small
|
||
number of named keys.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>
|
||
<p> Web or email.</p>
|
||
<blockquote>
|
||
<p>Send a link that contains a 256 bit identifier, but the UI should
|
||
not show anyone the identifier.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
<p>The ordinary user by default finds himself using at least one key for
|
||
face to face key introductions, a different key or keys for phone
|
||
introductions, and yet more for web or email introductions. If he is
|
||
clever and reads the manual, which no one will ever do, he can use the
|
||
same key for multiple purposes.</p>
|
||
<p> All of these named keys have the same behavior when you click on them,
|
||
they are intended to be perceived by the user as being the same sort of
|
||
thing.</p>
|
||
<p> He can use the link, the named key, to attempt to contact, or buddy it,
|
||
or bookmark it.</p>
|
||
<p> The identifying link information looks like a web link, and is the
|
||
nickname of the public key. By default the nickname is the
|
||
petname. The user is free to edit this, but usually does not.</p>
|
||
<p> When he attempts to contact, this automatically buddies it and/or
|
||
bookmarks it.</p>
|
||
<p> When he finds a named key, he may "bookmark" it, together with one of
|
||
his own private keys – it goes into a datastructure that looks like, and
|
||
works like, browser bookmarks. He can also put it in his buddy list.</p>
|
||
<p> When you look at an item in your buddy list or bookmarks list, You see a
|
||
pair, the other guys key identifying information, and your own key
|
||
identifying information. You don’t see the keys themselves, since
|
||
they look like line noise and will terrify the average user.</p>
|
||
<p> When you click on one of these bookmarks, this creates a connection if
|
||
your key is on the other guy’s buddy list and he is online. You can
|
||
chat, video, whatever, end to end secured. Otherwise, if you are not
|
||
on his buddy list, or he is not presently online, you can send him
|
||
something that is very like an email, but end to end secure.</p>
|
||
<p> When you send a bunch of people a text communication, chat like,
|
||
chatroom like, or email like, they are cc or bcc. If cc, all
|
||
recipients of the communication get links, which they can, if they feel so
|
||
inclined, message, bookmark or buddy.<br/>
|
||
<br/>
|
||
Text communication software vacuums up and stores all links, so if you get
|
||
an incoming communication from someone whose public key you have not
|
||
buddied or bookmarked, the software will tell you any past contacts you
|
||
may have had with this public key.<br/>
|
||
<br/>
|
||
Buddied public keys are white listed for immediate online communication,
|
||
Bookmarked and buddied public keys are white listed for offline text
|
||
communication, public keys with past information about contacts are grey
|
||
listed, public keys with no previous contact information are blacklisted.<br/>
|
||
<br/>
|
||
Because of automatic blacklisting, to contact, you have to <i>exchange</i>
|
||
keys.</p>
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons
|
||
Attribution-Share Alike 3.0 License</a></p>
|
||
</body>
|
||
</html>
|