Waterken^TM YURL

An Introduction to Introduction

2003-07-24

This document is a primer on authentication.

Abstract

On the WWW, introduction takes place through the use of URLs. A page "introduces" you to another site by providing a hyperlink containing a URL for the other site. An introduction happens every time you receive a URL.

When you visit a WWW site, your browser "authenticates" the site. Authentication only means verifying that the site responding to your request is the same site identified by the introduction URL.

Authentication in the WWW is currently implemented using https:// URLs. This primer explains the current implementation and introduces a better approach: the YURL.

The status quo: https

When you click on an https:// URL, your browser establishes a secure connection to the identified site before requesting the document. If the secure connection is successfully created, your browser displays a small lock icon in the lower corner of its window and loads the document. If your browser cannot authenticate the identified site, it will interrupt your browsing with a pop-up dialog notifying you of the failed authentication.

Fig. 1: A failed authentication alert.

The certificate

To authenticate a site, your browser performs checks on a certificate that it receives from the site. A certificate is a signed document containing a public key and information about the holder of the corresponding private key.

Every secure site has a public/private key pair. Your browser uses a site's public key to encrypt a request to the site. The site uses its private key to decrypt the request. Anyone can encrypt a request using a public key, but only the holder of the private key can decrypt the request. A public/private key pair is like a locked mailbox: anyone can insert mail, but only the mailbox owner can remove mail.

A public/private key pair is a digital identity. https:// authentication uses a certificate to match a URL to a digital identity.

The three checks

Authenticating a target site means verifying that the provided public key belongs to the site identified in the URL. Your browser performs three main checks, listed in the dialog shown in Fig. 1, to complete the authentication.

A certificate names the owner of the provided public key. Your browser verifies that the owner name is the same as the domain name in the URL. For example, if you click on a link with URL https://www.waterken.com/, your browser will verify that the provided certificate names "www.waterken.com" as the owner of the provided public key. This is the third check listed in the dialog in Fig. 1.

A certificate is only valid for a specified period of time. Your browser verifies that the provided certificate has not expired. This is the second check listed in the dialog in Fig. 1.

Anyone can compose a document containing a public key and naming an alleged owner. A certificate is only useable if you trust its creator. A certificate creator is called a "Certificate Authority" or CA. A CA has its own public/private key pair used for signing certificates. The private key is used for signing and the public key is used for checking the signature. Your browser has a collection of CA public keys built into it. Your browser assumes that you trust all of these CAs. When you visit a site, your browser verifies that the provided certificate was signed using one of these built-in public keys. This is the first check listed in the dialog in Fig. 1.

If all three of these checks pass, the browser trusts the CA's claim that the provided public key belongs to the site identified in the URL. The identified site has been authenticated.

What does a CA do?

A CA checks the veracity of information in a certificate and signs it. When purchasing a certificate from a CA, you send the CA your domain name, your mailing address, and your public key. The CA verifies that you are the legitimate owner of the domain name. If so, the CA issues you a signed certificate.

When you purchased your domain name, you were given an entry in the Internet's WHOIS database. This entry lists your domain name and mailing address. Essentially, a CA lets you additionally associate your public key with this information. The checks performed by the CA only ensure that you are the same person for whom they created the WHOIS database entry. One may reasonably ask why the CA did not ask for the public key during the original registration process.

What does a CA not do?

Checking that you are the legitimate domain name owner is the only check performed by the CA. In particular, the CA does not vouch for your character or good standing. Nor does the CA vouch for the security of your site's software or setup. The CA in no way vouches for the content provided by a site. A site may provide fraudulent content from a domain name that it legitimately owns. Successful authentication does not mean that the user cannot be deceived about the true author of a document.

When comparing authentication solutions, keeping in mind the exact nature of the provided service is crucial to an accurate evaluation. Authentication verifies the site you were actually introduced to, not the site you thought you were introduced to.

A better way

The combination of public key cryptography and CAs is called the Public Key Infrastructure, or PKI. This name gives the impression of a large and important bureaucracy, which the PKI is. Like other bureaucracies you may be familiar with, the PKI is expensive, unwieldy, and error-prone. Might there be a better way of using public key cryptography that does not entail a bureaucracy like the PKI? Yes, a widely used and trusted way already exists; it just has not been applied to the WWW yet.

Every public key has a unique fingerprint. Creating a new public/private key pair with the same fingerprint as an existing public key is mathematically impossible. Instead of using the PKI to match a public key to a URL, the public key fingerprint is included in the URL. The browser verifies that the fingerprint in the URL matches the public key provided by the visited site. Certificates and Certificate Authorities are unnecessary.

A URL that uses this authentication technique is called a YURL. For a more detailed understanding of YURLs, read "What Does the 'y' Refer to?". For a comparison of YURLs to other widely used and trusted software, read "Things that are Similar to YURLs". For a detailed examination of the technical advantages of YURLs over the PKI, read "Why Use YURLs?". To understand how YURLs integrate with typical WWW browsing, read "Trust Management for Humans". Try using YURLs with the Waterken^TM Browser.

Copyright 2002 - 2003 Waterken Inc. All rights reserved.