Waterken^TM YURL

Authentication of TLS Upgrade Within HTTP/1.1

2004-02-07

This specification defines a mechanism for identifying and authenticating an HTTP server based on the hash of a public key, instead of a certificate from a certificate authority.

Abstract

A target server is identified by the hash of a certificate issuer's public key. A client locates a server using a list of network location hints. These location hints may provide the location of the target server, or the location of a redirection server which redirects the client to the target server. Once the target server is located, the client completes an upgrade to TLS/1.0. Before sending a resource request, the client authenticates the target server by constructing a valid PKIX certificate path to a certificate that is signed by a public key having the expected hash.

Overview

Design goals

The y-property is implemented

The existing standard for using encryption and server authentication with HTTP is HTTPS. [RFC 2818] HTTPS identifies a server by a DNS hostname. A certificate, signed by a trusted Certificate Authority (CA), binds a public key to the DNS hostname. This specification defines an alternative server identification and authentication mechanism that does not depend on centralized, third party administration. The HTTP extension, HTTPSY, uses a public key hash, instead of a DNS hostname, as the URL authority. This mechanism binds the URL authority to a public key without use of a trusted third party.

The decentralized authentication model implemented by this specification is defined by the y-property.

Existing Transport Layer Security (TLS) infrastructure is leveraged

Reusing the existing and widely deployed TLS infrastructure minimizes the amount of specification, implementation, and evangelizing work required for deployment. [RFC 2246]

Existing WWW infrastructure is leveraged

This specification defines a mechanism for use with the existing WWW infrastructure, and so needs to be compatible with it. This specification reuses the work done in RFC 2817 to meet this constraint. [RFC 2817]

Description

This specification defines a new type of URL authority and an HTTP extension for locating and authenticating the internet server hosting this URL authority. The HTTPSY extension identifies a host by the hash of a certificate issuer's public key. This hash is the URL authority.

A new URL scheme is defined for use with the HTTPSY extension. An httpsy URL identifies a resource that MUST be accessed using the HTTPSY extension. This specification requires the new URL scheme to create the preceding "MUST" constraint for clients.

The httpsy scheme

The httpsy scheme is used to locate network resources via the HTTPSY extension. This section defines the scheme-specific syntax and semantics for httpsy URLs.

    httpsy_URL = "httpsy://*" key-id [ "@" hints ] [ abs-path [ "?" query ] ]
    hints = locator *( "," locator )
    locator = host [ ":" port ]
    key-id = SHA1-hash
    SHA1-hash = 32BASE32
    BASE32 = [a-zA-Z2-7]

If the port is empty or not given, port 80 is assumed. The host follows the grammar defined in RFC 2732. [RFC 2732] The abs-path and query follow the grammar defined for http URLs. [RFC 2616]

The semantics are that the identified resource is located at the server possessing the private key corresponding to the public key having hash key-id. The locator list is merely a hint as to how the server may be contacted. The client can ignore this hint if the server is successfully contacted by alternate means.

Unlike the http scheme, the use of an IP address for the host is not discouraged. The redirection functionality of the HTTP protocol can substitute for the DNS. In the httpsy scheme, a host is like the address of a nameserver, rather than the name of the server. The address of a nameserver is typically more stable than that of a server. The issuer of an httpsy URL SHOULD ensure that a specified host remains useful for contacting a server throughout the lifetime of the identified resource.

The key-id is the base32 encoding of the SHA-1 hash of the certificate issuer's public key. [base32] The public key is encoded in the DER encoding of the ASN.1 type 'SubjectPublicKeyInfo', as defined by the X.509 standard. [RFC 3279] key-ids MUST be compared using a case-insensitive character-for-character comparison.

The HTTPSY extension

A resource request MUST ONLY be sent over a TLS/1.0 connection to the server identified by the key-id field in the request URL. The procedure for establishing this connection additionally acts as a search algorithm for locating the identified server. The client MUST continue searching until a server is successfully authenticated, or the client has determined that the identified server cannot be contacted.

A request URL contains a list of network location hints. This locator list is unordered, and SHOULD be used by the client in a random order. The client searches for the identified server by using a locator to send a TLS/1.0 upgrade request, as specified in section 3.1 of RFC 2817. The upgrade request Request-URI is the concatenation of '/id/' and the key-id specified in the request URL.

For example, if the request URL is:

httpsy://*cl7h3f7jwyj3fvmw7jpnjfvf2xlcmayi@yurl.net/

The upgrade request is:

    GET /id/cl7h3f7jwyj3fvmw7jpnjfvf2xlcmayi HTTP/1.1
    Host: yurl.net
    Upgrade: TLS/1.0
    Connection: Upgrade

If a server does not accept an upgrade request, it SHOULD respond with a 3xx redirection. The client MUST follow an initial automatic redirection, but SHOULD NOT automatically follow a subsequent redirection. A server that responds to an upgrade request with a redirection is called a "redirectory". A redirectory is a directory of redirections for locating an identified server.

If a server accepts an upgrade request, as specified in section 3.3 of RFC 2817, the client MUST attempt authentication of the server. A server is authenticated by constructing a valid PKIX certificate path to a certificate that is signed using a public key that corresponds to the key-id in the request URL. If the client is unable to successfully authenticate the server, the client MUST resume searching for the identified server.

Deployment

By providing server identification and authentication that is free from the costs of centralized, third-party administration, the HTTPSY extension enables the creation of HTTP applications that were not previously feasible. These new applications are expected to deploy HTTPSY client and server implementations as part of their initial application deployment.

Existing HTTP applications that use the https URL scheme may also benefit from migrating to the httpsy URL scheme. Such HTTP applications can begin migration by deploying the server side of the HTTPSY extension. During this intermediate deployment stage, all application resources are accessible under both httpsy and https URLs. After an acceptable percentage of deployed client software has been upgraded to support the HTTPSY extension, new application resources are hosted only under an httpsy URL. These new resources can then benefit from the reduced costs realized from eliminating use of the PKI. The population of https URLs decreases as old resources reach the end of their natural lifetime and are deleted.

References

[RFC 2818] E. Rescorla; "HTTP Over TLS", RFC 2818; May 2000.

[RFC 2246] T. Dierks and C. Allen; "The TLS Protocol"; RFC 2246; January 1999.

[RFC 2817] R. Khare, S. Lawrence; "Upgrading to TLS Within HTTP/1.1"; RFC 2817; May 2000.

[RFC 2732] R.M. Hinden, B.E. Carpenter and L. Masinter; "Format for Literal IPv6 Addresses in URL's"; RFC 2732; December 1999.

[RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1"; RFC 2616; June 1999.

[base32] T. Close; "Waterken^TM Enc -- base32 Encoding"; <http://www.waterken.com/dev/Enc/base32/>; June 2003.

[RFC 3279] W. Polk, R. Housley, L. Bassham; "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"; RFC 3279; April 2002.

[YURL] T. Close; "Waterken^TM YURL -- What Does the 'y' Refer to?"; <http://www.waterken.com/dev/YURL/Definition/>; June 2003.

Acknowledgments

Thanks to David Hopwood for his early and detailed reviews of this specification. Thanks also to Mark Miller for his contributions to the conceptual underpinings of this specification.

Copyright 2003 - 2004 Waterken Inc. All rights reserved.