wallet/docs/names/petnames.md

title
An Introduction to Petname Systems

::: {style="text-align: center;"} by Marc Stiegler, Feb 2005, copyright under the MIT X License
updated June 2010
:::

Abstract

Zooko's Triangle [Zooko] argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.

Though no single name can have all three properties, the petname system does indeed embody all three properties. Informal experiments with petname-like systems suggest that petnames can be both intuitive and effective. Experimental implementations already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.

Basic Petname Layout

Below, we have Zooko's Triangle overlaid with a petname system:

For the purposes of this document, we actually use an alternate rendering of the key points of Zooko's Triangle.  The points of the triangle are:

• Memorable: this means that  a human being has a chance of remembering the name. Memorable names pass the "moving bus test": if you see the name on the side of a bus as it drives past you, you should be able to remember the name long enough to use it when you get home.
• Global: this means the name is publicly available, and indeed the entity to whom the name is attached is eager to give it to you. A key goal of marketing and advertising is to capture memorable names in such a fashion that the memorable name is globally locked to a particular entity.
• Securely Unique: This is means that the name cannot be forged or mimicked. A name can be forged if one can manufacture an exact duplicate of the name such that neither man nor machine can tell the difference. A name can be mimicked if one can make a name similar enough to fool the human being. In general, phishing depends on mimicry, not forgery. This difference becomes crucial later in the discussion.

Each name set consists of three elements: a key that is global and securely unique (but not necessarily memorable); a nickname that is global and memorable (but not at all unique) , and a petname that is securely unique and memorable (but private, not global):

• Keys lie at the heart of the security properties of the petname system. Nicknames and petnames exist to make it easy for human beings to manipulate keys. The security of the system can be no stronger than the unforgeability of the keys. Self-authenticating public/private key pairs make excellent keys since they have strong unforgeability properties. But there are other ways of achieving unforgeability. A trusted path can also work well as the key: the full pathname to a file on a specific computer is also unforgeable (or at least, as unforgeable as the designation of the specific computer, which can be quite strong in some cases). It does not make any difference in a petname system whether a key can be mimicked: keys are handled only by the computer, the human being handles the keys only indirectly via petnames. For a particular person, for a particular application, there is a one-to-one mapping between a key and a petname.

• Nicknames can be used to assist in discovery of keys, and for help in selecting a petname. Nicknames are chosen by the owners of  keys in hopes of creating a distinctive, if not unique, mapping from the memorable nickname to the key. Such nicknames often are promulgated throughout the world in the hopes of making the nickname stick in the mind as a reference to the key. Since there are strong incentives to "take ownership" of a nickname, even though true ownership is not possible, nicknames are the most often misunderstood part of a petname system.

  In the simple case, a nickname has a one-to-many mapping to keys The name John Smith is obviously a nickname: there are many John Smiths.Other nicknames produce the illusion of being globally unique: the name Marc Stiegler appears to be globally unique at the time of this writing. But there is no security property in this accident of global uniqueness. The uniqueness of the name Marc Stiegler would change quite quickly if, through the mysterious forces of human whimsy, the name suddenly became desirable. Sometimes the desirability of a nickname is not whimsical, but venal. It is already desirable for some applications to call themselves Quicken, for example, and draw windows that request a Quicken password.

• Petnames are our private bidirectional references to keys. There are many Mark Millers, but there is one specific Mark Miller that the name means to me, the Mark Miller who works with object-capabilities for secure cooperation. "Mark Miller" is Mark Miller's nickname; it also happens to be my petname for the same individual. My private pet name for my wife is not recognizably similar to the public nickname used by my wife. In the computer setting, for a specific person with a specific application, petnames are unique, each petname refers to exactly one key, and each key is represented by exactly one petname. In all places in the application where the app wants to designate the key, the petname is displayed -- which is to say, a true petname is a bidirectional one-to-one mapping to a key. All references to the key by the user interface are represented by petname. A key cannot have two petnames; if a single key had two petnames, under what circumstances would the user interface use petname1 as the representation of the key, and under what circumstances would it bring up petname2?

More Detail, and Interactions

A good example of a nickname management system is Google. Type in a name, and Google will return a list that includes all the entities Google knows, to which the name refers. Google makes a mapping between these nicknames and their keys (if we think of the url of a page as a trusted-path-style key, which will be discussed later). Often enough to be interesting, the first item in the list will be the one you wanted. But it fails often enough, and endless pages of other choices appear often enough, to never leave us in doubt that these identifiers are not unique mappings to single keys. As is already true in the current world, in a world filled with petname systems, a key goal of marketing would be to get your nickname listed at the top of the Google rankings for that nickname.

A single key may map to multiple nicknames. The entity that comes up first in a Google search for "Marc Stiegler" is an entity who proposes the nickname "marcs" for himself in many forums. However, to assess the security properties of a petname system, this is irrelevant.

Nicknames are conveniences that may serve as good starting points for petnames. If I send you my key and my nickname, often my nickname (which I normally will have chosen to be reasonably rare in the world) will work great as your petname. But do not confuse the nickname-as-proposal with the petname-as-decided. Never in a true petname system is the nickname presented or employed as if it were a petname.

Alleged names are similar enough to nicknames to be worth distinguishing. An alleged name is the name for an entity proposed by a third party, typically in an introduction. This can also be useful as a starting place for picking a petname. Alleged names, like nicknames, are usually memorable, often global, and never securely unique. Alleged names are often based on nicknames, though this is unreliable enough, if one really cares about the nickname then one really needs to ask the entity holding the key, not the introducer.

In action, keys and alleged names tend to be transferred together. We refer henceforth to such key/alleged-name pairs as referrals.

It is crucial not to confuse private petnames with global nicknames that temporarily happen to have a unique mapping to a key. Experience to date suggests that the word "petname" is attractive, leading people to desire to use it. People can thence easily fall into the trap of referring to momentarily unique nicknames as "petnames". This error then leads them inevitably to draw fatally confused conclusions about the possibility of petnames with global meaning. The security properties of a petname come from its privacy. Public nicknames are trivially vulnerable to both forgery and mimicry; they have no security properties.

Petnames are guessable. Most people will accept Paypal's nickname as the petname. This can only impact the security of the system if the user interface distinguishes the petnames from the nicknames so poorly that the user gets confused.

The term "petname" suggests that this name is embodied as text. This is not necessary; petnames can be graphical as well. Indeed, some of the petname systems listed later use petnames that include both pet texts and pet graphics.

Petnames must be repeatably editable by the human being so that the set of petnames can evolve as the user's set of associations grow. You might use the petname "Mark Miller" for the one and only Mark Miller that you know. But then if you meet another Mark Miller you will have to distinguish, possibly by editing the first one: the single entry "Mark Miller" may now split into "Mark Miller Capability Guru" and "Mark Miller Dentist".

Petnames convey power: since the petname is the user representation of the key, it is through the petname that the human being uses the key, communicates with the key owner, and conveys authority to the key owner based on the user's purposeful trust relationship with that owner (purposeful trust is the type of trust needed to engage in action: I trust (i.e., I am willing to be vulnerable to) Entity X to hold N number of dollars on my behalf, and to engage in transfers of that money based on orders I give).

Another way of thinking about the relationship between a key and a petname is this. The key is used to authenticate the entity that owns the key. The petname is used as a handle upon which to hang the trust/reliance/vulnerability data used by the human being to make authorization decisions for that entity. If the entity represented by the petname My Phone Company asks for my credit card, if the justification sounds reasonable, I will release it. If the entity represented by the petname Deadbeat Brother (whom I nonetheless trust to teach my daughter soccer in the afternoon without supervision -- the trust relationship with such a brother is neither positive nor negative, it is complex) asks for my credit card, I will not release it no matter what the justification.*
*

The security of a petname system depends on the keys to prevent forgery, and on the petnames to prevent mimicry.

Petnames In Action

Informal experimentation suggests that a petname system is much easier to use than to explain (see examples below). We will create a single example for this introduction, and give some hint as to the wide diversity of variations in the Examples. Suppose I send you Mark Miller's OpenPGP pubkey in email. I say, "here is mark miller's pubkey." I sent you both a key  and an alleged name (mark miller). Implicit in the transmission of the alleged name is the proposal that you might want to consider "mark miller" as the petname. What you actually choose as a petname depends entirely on your context. If you know this particular mark miller in other contexts in other applications as "markm", you may choose "markm" as the name referring to this key in your list of pubkeys. If you think this might be the same mark miller, but are not willing to be vulnerable to me as the sole source of such powerful mapping, you might use the petname "Marc Stiegler's Mark Miller" or "Mark Stiegler's markm". If you perform appropriate incantations on the pubkey, you can get the entity's nickname. If this pubkey already exists in your list, your software shouldn't give you the choice of adding it: the software should tell you that you already have this one, and tell you the current petname (and perhaps bring up the petname editor so you can change the petname if the newly-received reference suggests a better name). If you receive a message signed with the private key for the markm petname's pubkey, the software should display the petname markm. If you send a message to mark miller, you should pick the encryption key based on the petname.

The above example has the security properties of a petname system, but OpenPGP systems often do not demonstrate the  usability properties a petname system needs. Instant messaging systems with buddy lists demonstrate the usability properties, but for reasons beyond the understanding of this author, discard all the security properties. See the examples section for more details on buddy lists as petname systems.\

Key Issues with Petname Systems

Two elements of full-fledged petname systems seem to be principle sources of controversy. One is, how do I get the keys transferred around the system? The other is, "how easily can Darth Vader mimic a petname?".

Transferring Keys and Purposeful Trust

Transferring keys around the universe is easy; for example, plaster the keys on all the web sites in the world that'll let you do so. The hard part is transferring a key with an association to purposeful trust. It is useless to both PayPal and the phisher who wants your Paypal account if you just know Paypal's key; you have to be willing to make yourself vulnerable to the entity who owns the key to hold your credit card, trusting him to engage in only transfers that you specify.

The question, "how do I transfer a purposeful trust association?", is hard to answer because there is no simple single answer. Instead, there are a vast array of answers, each of which works in narrow circumstances. The question is made even more difficult to answer because the mechanisms by which humans determine an appropriate purposeful trust to be associated with an entity is subtle, complex, powerful, and completely subconscious: the question of how you transfer the association can easily slide into a hopeless discussion of how to create purposeful trust in the first place. Here we outline some general ideas for transferring key/purposeful-trust mappings, then in the Examples point out some practical approaches in specific narrow contexts.

Answers often start with direct physical contact. You get a combination of a nickname and a key in a file from your best friend, who says, "this Google thing is a great search engine", or "this Consumer Reports site will not lead you astray". You stick these referrals in your browser, assign petnames, and make yourself vulnerable to them for the purposes stated because your friend said so. Then when the side of the bus says PayPal, you might go and see what Google thinks Paypal means. Since a relationship with PayPal is a serious vulnerability decision, serious enough so that we're not going to jump at the first site just because Google said so, we'll ask a few of our friends to email referrals to the entities they use for online money. If the referrals they send all share the same key as the Google key (which is easy to tell, because trying to add each new key/petname mapping will produce the alert that the key matches something you've already got), the quality of your willingness to be vulnerable to the key you have petnamed PayPal improves. This is pretty similar to how we all started using PayPal even without the petname system: we jumped in when enough of our friends and organizations that we trust for recommendations about financial matters concurred. The only difference in the petname version of the story is that our friends explicitly gave us referrals rather than easily mimicked domain names, and we explicitly set a petname (perhaps by just clicking an Accept key when the alleged name was proposed as the petname).

While a full-fledged, purebred petname system could in principle supplant the entire DNS system, we have DNS now, and we can use it to do some bootstrapping.  My ability to type google.com and paypal.com is probably adequate to get started.

Regardless of how you bootstrap, you can get referrals by email, thumbdrive, web page, chat, and even by telephone.

Converting From Nickname to Petname

The other part of the system that is impossible to quantify is the mimicability of pet names. Let us assume a poorly built petname system in the clutches of a clueless user. We have a money transfer site on the Web that we have petnamed PayPal. We get an email telling us to update our PayPal account, we click the link, and go to a domain that has given itself the nickname PayPa1 (for those of you with typically broken fonts, that last character, "1", is a one). Our poorly built  hypothetical petname system is so poorly built, the nickname is put into the field where the petnames go, with a hint of  shading or some other easy-to-miss mod to mark the fact that this is the web site's nickname for itself, not our petname for it. The  distinction is missed, and our user is phished.

The solutions to this problem are application and context specific, though there are some good ideas floating around that seem to have wide applicability. In the Waterken Petname Toolbar proposal (see below), the alleged name is always "untrusted".  It's hard to fail to recognize that this isn't PayPal, though a sufficiently unobservant user might completely disregard the petname and nickname information and get phished anyway. There is limited informal evidence that users really do notice things like this (see below), and so the most cynical of skeptics are probably mostly wrong though they are probably slightly right: if you send a million phishing emails to each of a million users, some day some one will be tired and unobservant and will get phished. If sending a trillion emails like this is cheap enough, phishing will remain profitable, so part of the solution needs to be making a trillion emails ever so slightly expensive. Regardless, multiple experiments with multiple user interfaces would be a good idea to help develop user interfaces that maximize the probability that a tired unobservant user will notice a warning.

There are a couple of user interface issues. The petnames must be unambiguously distinct from nicknames. This seems easy to do, through colors, fonts, additional text, and separate fields for the nickname as examples of pieces of strategy.

More difficult is the following problem: Petname creation must be both painless (or people will reject the whole idea) and reliably mimicry-free (it would be a disaster to have both PayPal and PayPa1 as petnames!).  Is this one of those hopeless tradeoffs that the computer security community enjoys throwing in its own face? To the author, this problem looks solvable; indeed, it seems hard to believe that this cannot be solved with some reasonable satisfaction, given the number of user interface ideas for this problem floating around. But implementations and experiments, will be required to identify minimally intrusive, adequately effective solutions. 

Here are two example ideas for petname creation user interface that seem generally applicable. First is to compose the default choice for the petname out of a combination of contextual information and nickname information. Suppose we click on a link to "PayPal" in the Consumer Reports site (that is, the site that we have assigned the nickname, "Consumer Reports"). This takes us to a new site that proposes the nickname "PayPal". The system clearly marks that we do not have a petname for this site and proposes "Consumer Reports's PayPal". The user can press a button to accept this name, edit it, or, with algorithmic chicanery left as an exercise for the reader, press a second button that says, "let me use the raw nickname PayPal as the petname." This system still depends on the user remembering the petnames he has already assigned and noticing at the time of creation of the new petname, whether he already has a similar name in his list. This by itself is probably enough to protect the PayPal pet name -- most of us who gave PayPal a petname would have no trouble remembering we had done so, and if we saw something that looked like "PayPal", we'd notice we were at risk of confusing ourselves if we accepted a similar name -- but again, we are dealing with humans, so the process is imperfect. To support the human being, we'd want to use a font that was as ambiguous as possible during petname creation, mixing up 1 and l and I in a hopeless mess, so that we could be confident that our petnames looked unique no matter what ridiculous font got used later.

The second idea is to have a weak algorithm for comparing a candidate petname in the act of being accepted to the existing petnames. We explicitly call this a weak algorithm because it can be pretty poor. It  is quite acceptable for the algorithm to pop a list of "similar petnames" that is overly extensive, i.e., it is fine to show names that the human easily recognizes as distinct. The serious error is to fail to show names that the human might confuse. Comparing Paypal to Paypa1, a sample algorithm might notice that the names are of similar length and have three letters in common ("p", "a", and "y"), and say, "that's similar enough to worry me, I'm gonna check with the boss." The algorithm for noticing similarity between private petnames is under much less pressure to be perfect than is the algorithm for a Certificate Authority when deciding whether to award the name "pawpal" when the name "paypal" already exists. A CA might like to prevent mimicry, but to do so must tread a difficult line with abolishing huge swaths of namespace to ensure similarities don't arise.

However it is done, mixing alphabets from different languages into a single petname list is ridiculous. These are private petnames. Only one person in the whole world needs to read them. Use the user's default character set, and be done.

Examples, Near Examples, and Comparisons

Physical World Petnames

Humans have been using parts of petname systems since before the invention of the written word. Human faces were used as keys. These keys resisted forgery far better than most things that pass for security today on computers (except in episodes of Mission Impossible, and the occasional Shakespearian comedy like 12th Night). The referral, "Joe, this is my son Billy, he's great with a club," transferred both a key/alleged-name pair and a first-order purposeful trust recommendation. The recipient of this referral typically accepts the alleged name as a petname, though in some cases the recipient may instead choose other petnames, such as, "Bob's big dumb dufus of a son", which is a strictly private petname.

These physical world petname systems were sufficiently different from computer-based petname systems that it is dangerous to draw too many conclusions from them. But the similarities are sufficiently intriguing that the author feels compelled to mention them. More comprehensive comparison and contrasting of physical petnaming to computer-based petnaming is left as an entertainment for the reader.

Trademark Law

Trademark law is not a petname system. When civilization started creating entities that did not have unforgeable faces (like Apple Computer), we settled on a legal system that attempted, with fair success, to enforce (that is, secure) purpose-unique memorable global IDs for small numbers of entities. It is hard to map trademarks onto petname systems for comparison, but an attempt seems in order. The trademark-purpose pair is the key, made unforgeable by government coercion. It is important to note that the trademark itself is not the key: Apple Computer and Apple Music both used the trademark Apple for decades, without conflict, until Apple Computer entered the music business.

The trademark by itself is the nickname: Apple Computer thinks of itself as "Apple". Petnames are absent. Mimicry is prevented by the same government action as forgery, and indeed the trademark system makes no distinction between forgery and mimicry (which helps explain why the distinction is so blurred in most computer security discussions).

Trademark law depends on the legal system to disambiguate "similar purpose". This is expensive, and consequently trademark law can only apply to "small" numbers of "big" entities. The name Mark Miller is covered by trademark law, but only in explicitly recognizing that all people who have that name may use it, i.e., trademark law recognizes non-uniqueness in this case. On the Web, the number of entities with whom we would like to associate trust/vulnerability relationships is extremely large; indeed, one of the failures of the Web today is that we cannot construct as many such associations as we would like. Those relationships span multiple legal jurisdictions, further complicating the trademark system. Trademarking simply does not scale well enough for the age of the Web, despite its success in earlier eras.

Instant Messaging Buddy Lists

Buddy lists for instant messengers follow the logic of petname systems quite closely, though all the security properties are discarded in current implementations. Each entity gets a globally unique id, rooted in the domain name of the messaging service, which fills the role of "key". A weak effort is made to make the id both human memorable on the one hand, and unforgeable, on the other. The id is used as a nickname; being sometimes memorable, it works well enough often enough. The same id is used as a key even though it is easy to forge (either through man in the middle attacks or password attacks). The important point is that, once the user puts a petname into the buddy list, all references to the id are represented using the petname: you can connect to the entity using the petname, and when the entity connects to you, the petname displays.

Buddy lists are so intuitive, people easily learn how to use them with neither instruction nor documentation. An instant messenger that used true keys, true nicknames, and enforced good security properties would be virtually indistinguishable in user-interface presentation from existing systems; indeed, if one used an object-capability style of key, the biggest difference would be the absence of passwords, an actual usability improvement. Informal experimentation on a global scale in the instant messaging arena suggests the petname architecture embodied in buddy lists can work well.

CapDesk and Polaris

CapDesk [CapDesk] and Polaris [Polaris] are desktop systems that explicitly flesh out a petname system to enforce security properties. CapDesk is a point and click desktop that combines usability, security, and functionality, to a degree often found surprising by those unfamiliar with it. In CapDesk, at application installation time the application proposes a pet text and a pet graphic (the icon for the top left corner, and the text in the title bar that is immediately adjacent). The user may accept this petname or modify it. Windows launched thereafter by the installed application are unforgeably marked with the petname. Limited informal experimentation suggested that the CapDesk petname system was intuitive and easy to use, like the buddy lists.

Polaris is a derivative of CapDesk that defends the Windows operating system against several interesting classes of attack. Polaris uses pet texts similar to the CapDesk pet texts for marking the windows. Polaris was used in a larger set of pilot programs than CapDesk ever experienced. One result of the pilots that proved a pleasant surprise was that people were  aware of and sensitive to the petname markings. This supports the hope that petnames could indeed strongly impact phishing.

Domain Names

The DNS system is perhaps the most widely used naming architecture in the world. There are a couple of ways of viewing DNS from a petname perspective. The most clarifying view is perhaps the view of the domain name as both key and nickname rolled into one -- a unique nickname that must try to support security properties. One powerful way to describe DNS is to say that DNS strives to make keys that are memorable. In other words, it is a direct violation of Zooko's triangle. And that is why mimicry is possible. Mimicry is an emergent property of the violation of Zooko's triangle. Mimicry emerges as the system grows to large scale. DNS is the leading example of the problem.

Several of the other examples here treat the domain name as a trusted-path key. Domain names are forgeable, but in practice they seem to be resistant enough to forgery to be useful. Judging by the prevalence of mimicry-based phishing over DNS forgery, it seems clear that forgery is not the weakest link in DNS; mimicry is.

Browser Bookmarks

Browser bookmarks combined with DNS have a remarkable similarity to a petname system...with a fatal flaw. Think of the domain name as both a key and a nickname (which is not fatal to a petname system, remember the nickname has no security properties, it can be gibberish or massively oversubscribed or mimicked without violation...though the petname system has a better chance of success if users understand that the nickname has no security properties, which is another problem with DNS). With this characterization, the bookmark can be thought of as a private name that points at the key, suggested by the nickname. It sounds like a petname system.

However, the bookmark is not a petname. Technically, it is a lambda name. As noted earlier, a true petname is a two-way mapping: any reference to the key is represented in the user's world as the petname. However, lambda names like bookmarks only map from the private name to the key, with no mapping back. When you follow a bookmark to a page, or take any other path to get to the page, the domain name is used throughout the user interface as the "name" for presentation to the user, a fundamental violation of petname logic. Despite this violation, bookmarks plus DNS demonstrate how even a partial implementation of petnames will deliver some of the defense against mimicry that a full petname system can achieve. Any person who uses the strategy of reading an email allegedly from PayPal, and then clicking on their existing bookmark to go to PayPal rather than following the email-embedded link, is getting a security benefit derived from the partial implementation of petnames afforded by bookmarks.

OpenPGP and the Web of Trust

OpenPGP keys carry nicknames with them, and the user can replace nicknames with a name of the user's choosing, which would be a petname. When an entity's key is observed by the software, the pet name is properly presented, i.e., the petname is properly bidirectional. The Web of Trust supplies an interesting way to associate these keys with purposeful trust, by asking other entities who have vouched for the new entity, what they recommend as a trust relationship.

With all these features, OpenPGP supplies a true petname system architecture. OpenPGP has not been tested by phishing attacks yet. Since all the basic elements are there, the biggest question would be, how must the user interfaces for applications using OpenPGP evolve to face such a threat? This is another reminder that user interface is as critical for any practical security architecture as is the crypto. A security system whose user interface is written by cryptographers is no more likely to succeed than a security system whose encryption machinery is written by user interface designers.

Waterken Petname Toolbar

This toolbar[Waterken] is a proposal for web browsers explicitly based on petname architecture, explicitly to prevent phishing. A certificate plus a domain name is treated as the key. The petname is a true two-way mapping between key and private name. The alleged name for all sites is "untrusted"; there is no nickname. For those sites to which the user assigns a petname, the toolbar supplies markings that makes it easy for the user to unambiguously distinguish the site. This toolbar has been implemented for Firefox. This author switched to FireFox from Mozilla just to be able to use this tool. Limited informal experimentation suggests that the petname toolbar is as intuitive as the buddy lists and desktop systems described earlier.

Certificate Authorities

Certificate Authorities create nickname/key pairs. The certificates share with pgp keys the cryptographic strength to ensure unforgeability. The claim is made that, because the nickname is unique within the CA, interesting security properties may be ascribed to the nickname. Petnames are not included in the scheme. It looks a fair bit like DNS, with the CA root playing the role of the DNS root servers.

How do CA-based systems fair against mimicry? The similarity to DNS is certainly suspicious. A generous author might just say, CA defense against mimicry is controversial in theory and untested in practice. A less generous author would probably say no more, since such an author would still desire people who think that CAs are beneficial to read the rest of the paper.\

Trustbar

The trustbar [trustbar] is a CA-based browser system that allows user construction of petnames, including both pet text and pet graphics, for the certified entity.  In the 0.1 Mozilla implementation, the distinction between a nickname (based on the cert) and the petname is implied by the popup of a dialog box when the cert is first encountered and no petname has yet been assigned. The petname and the key are not quite fully bidirectional: the key is properly represented by the petname in user interactions, but the petname cannot be used to get to the key. This is just a quibble, however. The Trustbar implements a petname system. It has, however, a big change from a simple petname system: the inclusion of a CA in the mix. Does this help or hinder?

In the presence of the popular "Just click Ok" mantra for certs, adding a CA to the system may introduce new vulnerabilities. Two CA-based attack examples: "We here at Verisign are upgrading our root key. Please follow the link and click Ok." Alternatively, "We here at Paypal have fallen into a legal dispute with Entrust. We are using a new CA that is every bit as trustworthy. Please follow the link and click Ok." Brief informal experimentation with the author's 83-year-old mother-in-law suggests that an email asserting Paypal has changed domain names is easily recognized as an attack. However, email asserting a cert has changed is viewed as a foolish demand impeding progress -- just click OK.

As noted earlier, user interface design is every bit as important to security as the strength of the keys. Simply stripping the trustbar tool of the inevitable plethora of CA-related dialog boxes would significantly improve usability, increasing the chances that real human beings would tolerate it; all the security properties of a petname system without CAs would remain intact. The Trustbar itself pops dialogs at the user (sometimes several in a row, if the entity maintaining a web site decides to use different certs for different pages, as discovered during the author's experiments). Private correspondence with the designers of the trustbar suggest that evolution in a direction reducing the frequency and annoyance of the dialogs is a possibility.

How well will the current implementation of the trustbar work in practice? Only experimentation can tell.

Pet Name Markup Language

PNML is an XML proposal for using petname systems ubiquitously. In a chat system, if Bob made a reference to Alice in the text he wrote to Ted, and if Alice is Bob's petname for a person known to Ted with petname Carol, the sent reference to Alice would be converted via the magic of computers into a received reference to Carol. It would take more effort to build PNML into an existing browser than to integrate the Waterken Petname Toolbar, but the results would be interesting indeed.

Conclusions

Many informal experiments with systems identified here that use parts of petname systems have demonstrated that they can be intuitive and easy to use (Buddy Lists, Browser bookmarks, the petname toolbar, and the CapDesk and Polaris secure desktops). A user who understands his petname system and is alert to the information it conveys can be extremely hard to trick using mimicry, making that user a difficult target for phishing. Experimentation is required to determine how much less vulnerable to phishing the typical user would become given a petname system. Experimentation with petnames for web browsers does not have to be expensive; both the Trustbar and the Waterken Petname Toolbar are ready now, both for usage and for further experimentation by building variations based on the open-source code.

Implementation Notes/Requirements

Following are key features of a petname system. If an implementation of a naming system for an application does not include these properties, it is not fully following the logic of petnames:

• The key must be resistant enough to forgery to survive in the context of the application threat model.
• There can be at most one petname per key per user per application.\
• There can be at most one key per petname (per user per application).
• In the application user interface, all references to the key are represented by the petname.
• The user must be able to assign a private petname to any key.
• The petname must be assigned to the key only by explicit user action.
• The user must be able to repeatedly edit the petname of any key.
• The user interface shall assist the user in assuring that two petnames are not similar enough to enable mimicry, to the extent necessitated by the complexity of the application context in which the petnames are selected and manipulated. If the number of petnames needed by the application is small and they are easily remembered, no assistance may be required. If the number of petnames is large, and/or difficult to remember and/or likely to be similar, and the resultant forms of mimicry, accidental or intentional, leads to vulnerability inside the threat model, assistance is required.
• Nicknames and alleged names must be unambiguously visually distinct from petnames.
• Nicknames are optional.

Glossary

Petname System: a naming system in which, for each individual entity recognized by another entity, three interlocking names solve Zooko's Triangle. The three elements are the key (global and secure), the nickname (global and memorable), and the petname (secure and memorable).

Petname: This term has three distinct but related usages in the literature on petnames. Sometimes it is used as a shorthand for referring to the petname system as a whole. Sometimes it is used as a direct reference to the naming element that is secure, memorable, and private to the individual who refers to another entity; this is the meaning used throughout this paper. Sometimes "petname" is used to refer to the textual component of a petname (which may have graphical elements as well). In contexts outside this paper, the reader must ascertain the correct interpretation from that context. True petnames are 2-way associative: given a petname in a specific application on a specific machine, you can acquire the key, and given the key, you can acquire the petname. The mapping back from the key to the petname is always performed when presenting data to the user. This makes petnames different from lambda names, which only map from the name to the key.

Pet Text: A petname, or part of a petname, that is textual. The owner of a machine upon which a petname resides can edit the text to modify the petname.

Pet Graphic: A petname, or part of a petname, that is graphical.

Pet Face: A petname, or part of a petname, that is an image of a human face. Pet faces are intended to exploit the special powers of the human mind for associating purposeful trust with another human.

Purposeful Trust: The type of trust that is needed before a person should empower another entity. Examples: "I trust Entity X to hold N dollars for me, and to perform transfers of that money on my behalf." And, "I trust Entity Y to tell me whether or not to buy a car from Entity Z." We speak of purposeful trust to distinguish it from the many other things computer people call "trust" these days. CAs, for example supply "trust". But CAs do not tell you if you can trust a certificate owner to pick up your garbage, or handle your stock portfolio. It's just "trust".

Forgery: An exact duplication of a key, such that neither human nor computer can distinguish the duplicate from the original.

Mimicry: A duplication of a name that is good enough to fool the human being, though not good enough to fool a computer. A famous example is the name paypa1 (with a "one" as the final character), which mimics paypal quite well. The quality of the mimicry of paypal depends on the ambiguity of the font in use, and the alertness of the human reading the message.

Lambda Names: Names that are memorable, secure, and private, but which only map from the name to the key: given the lambda name, you can retrieve the key, but given the key there is no mapping back to the name. Objects in programming languages follow this logic: the programmer gives the object a name in the program, but once compiled, neither the object nor much of anything else knows how to get back to the name (though this is an imperfect example, since debuggers can indeed map back). Bookmarks in browsers are another example: the bookmark maps to a url, but once you go to the url, the url is presented directly to the user, not the name embodied in the bookmark. Consequently bookmarks cannot help against phishing.

Acknowledgements

Thank you to everyone on the Cap-Talk mailing list for their help, especially Ian Grigg for his deliciously relentless criticism, but also notably including David Hopwood, Alan Karp, Mark Miller, Tyler Close, Trevor Perrin, and Charles Landau, each of whom made comments that directly caused modification to the early draft. Thank you also to Amir Herzberg for his assistance in understanding the Trustbar.

References

Zooko

Trustbar

or http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm\

CapDesk

or http://www.combex.com/tech/edesk.html\

Polaris

Waterken