home -> developer -> YURL -> Why

WaterkenTM YURL

Why Use YURLs?


This document makes the case that YURLs are almost always a better choice than the PKI.

Principle of least privilege

The principle of least privilege is the main constraint in the design of secure software. This constraint requires that a task be completed using the minimum distribution of privilege. As explained by the y-property, only the creator of a URL requires the privilege of determining the target of the URL. A YURL meets this constraint, the PKI does not. The PKI additionally gives the Certificate Authority (CA) the privilege of determining the target of the URL.

To understand the gravity of PKI's violation of the principle of least privilege, examine the list of CA certificates in your web browser. This list is commonly upwards of 50 long. All of these participants have the privilege to impersonate any site. If the private key for any one of these certificates is not perfectly protected, an attacker can impersonate any site.

Certificate lifecycle control

Today, the unfortunate reality is that servers get hacked. When your server gets hacked, your private key is exposed and no longer useful for authentication. To return to business, you must revoke the old certificate and get a new certificate issued. When using the PKI, you must pay your CA for this service. When using YURLs, you can provide this service for yourself. When using YURLs, you are your own CA. You have complete control over the creation of certificates.

Due to the high cost of CA services, sysadmins infrequently change a server's certificate. Increasing the lifetime of a certificate increases your vulnerability to identity theft. The longer the certificate is valid, the longer the private key must be protected. When using YURLs, sysadmins can shorten the lifetime of a certificate, change keys more frequently, and thus reduce their site's vulnerability to identity theft. Keys could even be changed at a frequency that would enable the site to forgo certificate revocation and Certificate Revocation Lists (CRLs).

Name ownership

A PKI based URL, like https, identifies your site using a domain name. Your right to use a domain name is governed by a non-democratic central authority, the IANA. You do not own your domain name, and you may lose the right to use it. In this event, a new owner of the domain name can put his own resources at the URLs that formerly identified your resources. Your resources would no longer be accessible.

A YURL, like httpsy, identifies your site using your CA public key fingerprint. You own your CA fingerprint. Taking away ownership of your CA fingerprint requires determining the corresponding CA private key. Determining a private key based on knowledge of the public key is mathematically impossible. No organization controls the creation of public/private key pairs. You do not need anyone's permission to acquire an identity, and no organization can reclaim your identity.

Monopoly rents

Despite the large number of CA certificates in the web browser, one company has a monopoly on selling certificates to the public. This company charges nearly $1000 for a certificate. When using YURLs, you issue your own certificates. No third party demands a fee.

Paying monopoly rents may be a tolerable situation when you only need limited services, but the situation becomes untenable when your needs expand. A single certificate for your entire WWW site may be affordable, but purchasing certificates for smaller collections of resources, like each web service, will quickly become unaffordable.

These economics typically result in many web services being bundled under the same domain name and SSL certificate. This solution creates a difficult and expensive performance bottleneck, as requests to all hosted web services must be routed through the same domain name. Since the same SSL private key authenticates all bundled web services, the security of each web service is not independent. This security vulnerability grows linearly with the number of bundled web services.

When using YURLs, you can give each web service its own authentication identity. This solution provides simple and cheap load distribution, as each web service can be independently migrated between computers. The security of each web service can be made independent, reducing vulnerability and facilitating management and security auditing.

When to use the PKI

Storing authentication information in the URL makes it difficult to memorize. If your URLs must be human memorable, the PKI is an appropriate choice for authentication.

Rarely are humans required to memorize a URL. Software is almost always used to remember the URL for the user. Before deciding to use the PKI, be sure that your application has this requirement. If it does, reevaluate your user interface before committing to the PKI. Using a hyperlink is always better than a memorized URL.


Copyright 2002 - 2003 Waterken Inc. All rights reserved.

Valid XHTML 1.0! Valid CSS!