home -> developer -> YURL -> Name

WaterkenTM YURL

Trust Management for Humans


This document compares the human interface for trust management in the PKI to that for YURLs.


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.

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.

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.

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!