[146477] in cryptography@c2.net mail archive
[Cryptography] Communicating public keys: A functional specification
daemon@ATHENA.MIT.EDU (James A. Donald)
Fri Aug 30 00:53:54 2013
X-Original-To: cryptography@metzdowd.com
Date: Fri, 30 Aug 2013 14:43:55 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <CAMm+LwjtyYgo6j3dOdYG=ZbGPoovxGh2z=jrerfniQ6b-z2Ncg@mail.gmail.com>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============8899279167192839813==
Content-Type: multipart/alternative;
boundary="------------060205010901060306020104"
This is a multi-part message in MIME format.
--------------060205010901060306020104
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Communicating public keys: A functional specification
A functional specification tells us how the user uses it, what he sees,
and what it does for him. It does not tell us how we manage to do it
for him.
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.
Also a chatroom's public key and network location.
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.
Face to face:
Identifying information is nym, face, and location.
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.
Over the phone.
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.
Web or email.
Send a link that contains a 256 bit identifier, but the UI should
not show anyone the identifier.
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.
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.
He can use the link, the named key, to attempt to contact, or buddy it,
or bookmark it.
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.
When he attempts to contact, this automatically buddies it and/or
bookmarks it.
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.
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.
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.
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.
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.
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.
Because of automatic blacklisting, to contact, you have to /exchange/ keys.
--------------060205010901060306020104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Communicating public keys: A functional specification<br>
<br>
A functional specification tells us how the user uses it, what he
sees, and what it does for him. It does not tell us how we manage
to do it for him.<br>
<br>
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.<br>
<br>
Also a chatroom's public key and network location.<br>
<br>
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.<br>
<br>
Face to face:<br>
<blockquote>Identifying information is nym, face, and location. <br>
<br>
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.<br>
</blockquote>
<br>
<br>
Over the phone.<br>
<blockquote>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.<br>
</blockquote>
<br>
Web or email.<br>
<blockquote>Send a link that contains a 256 bit identifier, but the
UI should not show anyone the identifier.<br>
</blockquote>
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. <br>
<br>
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.<br>
<br>
He can use the link, the named key, to attempt to contact, or buddy
it, or bookmark it.<br>
<br>
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.<br>
<br>
When he attempts to contact, this automatically buddies it and/or
bookmarks it.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</body>
</html>
--------------060205010901060306020104--
--===============8899279167192839813==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8899279167192839813==--
