home -> developer -> YURL -> Name

previous version

WaterkenTM YURL

Trust Management for Humans


This document compares the human interface for trust management in the PKI to that for YURLs, specifically focusing on resilience to phishing attacks.


The World Wide Web is, as the name implies, a web of interconnected, but independent sites. A user has a different trust relationship with each site. For example, a user may trust one site, but not another, to perform a credit card transaction. When a user follows a link from one site to another, the transition from one trust relationship to another must be apparent and unspoofable.

Currently, trust relationship transition within the WWW relies on the PKI. This document explains the PKI solution, highlights its flaws, and shows how trust relationship transition is better implemented without the PKI.

A trust relationship transition

When surfing the WWW, a user finds an interesting book review. The book review links to an online bookstore which sells the book. Following the hyperlink to purchase the book involves a trust relationship transition. The user has an existing relationship with the online bookstore and trusts it to complete credit card transactions. The user does not place the same trust in the newly discovered book review site. Unfortunately, to purchase the book, the user follows the hyperlink provided by the untrusted book review site. A fraudulent book review site links to a spoof site that appears the same as the online bookstore. The spoof site attempts to make a fraudulent charge to the user's credit card.

In the fraudulent bookstore example, a deceptive site transition occurs, causing the user to make an unwarranted trust relationship transition. The user believes that a site transition to the trusted bookstore has occurred, when in fact, a transition to a spoof site has occurred. The user is deceived about the true target of the site transition and makes an incorrect trust relationship transition.

The PKI solution

Currently, the WWW uses the PKI in an attempt to protect against deceptive site transitions. After the site transition, the user is expected to examine the target URL displayed in the browser's address bar. The user must verify that the target URL is in the https scheme, and that the indicated domain name matches the domain name of the expected target of the hyperlink. If both of these tests pass, the user knows that the expected site transition has occurred and that the corresponding trust relationship transition can now safely occur. The user can then apply his trust of the target site.

For example, suppose the bookstore in the bookstore example is Amazon Inc. After clicking on the book review site hyperlink, the user must verify that the URL in the browser address bar starts with: https://www.amazon.com/. If so, the user can safely complete a credit card transaction, making use of his trust relationship with Amazon Inc.

Name conflation

In the switch from the book review site to the bookstore site, two transitions take place: the site transition to the bookstore site and the trust relationship transition to the bookstore site. As the provider of the hyperlink, the book review site must be allowed to specify the target for the site transition; however, the book review site must not be allowed to specify the target of the trust relationship transition. Accepting directions from a stranger is safe, but accepting a stranger's advice on who to trust is not. Unfortunately, the PKI solution logic makes this error.

The PKI solution uses a single domain name as the identifier for both the site transition target and the trust relationship transition target. This conflated name is specified in the link URL provided by the potential attacker. As a consequence of this conflation, the name used to recognize the target trust relationship is also specified by the potential attacker. It is inherently dangerous to use the link target identifier, an element whose value is necessarily chosen by the potential attacker, as the key user interface element in recognizing a trust relationship.

Phishing attacks commonly exploit this flaw in the PKI's logic. Domain names, deceptively similar to that of a trusted site, are frequently registered. Users frequently receive fraudulent email containing URLs which appear to have the same domain name as a trusted site.

Expecting a human to detect a small and deceptive change to a domain name is unrealistic. Given this constraint, using a domain name as a trust relationship identifier is dangerous.

The YURL solution

A YURL does not rely on a global namespace, like a PKI URL does. A YURL identifies a target site by the hash of its public key. Given the absence of a global namespace, a user can conveniently create a local namespace.

In the YURL solution, the user's browser maintains a mapping of public key hash to petname. [PNML] When a user visits a page identified by a YURL, the browser prominently displays the petname the user previously associated with the public key hash contained in the YURL. If no such association exists, the browser allows the user to create one. After a site transition, the user verifies that the expected petname is displayed.

For example, after the site transition from the book review site to the Amazon Inc. site, the petname toolbar displays the user's previously chosen petname for the Amazon Inc. site, say "Amazon". An example display is shown in Figure 1.

'Amazon' in the petname toolbar

Figure 1: A site transition to the trusted "Amazon" site.

If the book review site linked to a spoof site, instead of the Amazon Inc. site, the petname toolbar indicates that there is no associated petname. An example display is shown in Figure 2.

'unknown' in the petname toolbar

Figure 2: A site transition to an untrusted site.

Note that in neither case can the book review site craft the content of the petname toolbar. A petname system has the crucial property that the name used to identify a trust relationship is selected by the user, not the site providing the hyperlink. This property protects against the deceptive site transition attack that plagues the PKI.

A petname is assigned to a site by the user when the user decides that he has a trust relationship with the site. The user chooses a petname that he feels best describes the entity he is choosing to trust. When the user visits a page from the site, the petname toolbar displays the chosen petname, helping the user recognize the trusted site and remember the nature of his trust relationship with the site.

Trust is something which exists only in the mind of a particular user. The nature of this trust is determined entirely by the user, and so is best named by the user. Approaches that inject trusted names into the user's namespace, as the PKI does, give the appearance of a trust relationship, where none actually exists. Under the PKI, an untrusted site has all the same visual hallmarks as a trusted site. This practice misleads the user and lends assistance to fraudsters.

Since the user manages his trust relationship namespace, he can select localized names that maximize his ability to make correct trust relationship transitions. This feature is especially important for non-English-speaking users.

Trust management for software

A petname system is solely for the benefit of humans; software has no trouble differentiating between YURLs. A web service, or other software that uses YURLs, should operate exclusively by direct use of YURLs.


[PNML] M. Miller; "Lambda for Humans -- The Pet Name Markup Language"; <http://www.erights.org/elib/capability/pnml.html>.


Copyright 2003 Waterken Inc. All rights reserved.

Valid XHTML 1.0! Valid CSS!