WaterkenTM 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.
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.
- The y-property is implemented.
- Existing Transport Layer Security (TLS) infrastructure is leveraged.
- Existing WWW infrastructure is leveraged.
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.
Reusing the existing and widely deployed TLS infrastructure minimizes the amount of
specification, implementation, and evangelizing work required for deployment.
[RFC 2246]
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]
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 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-id s MUST be compared using a
case-insensitive character-for-character comparison.
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.
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.
[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; "WaterkenTM
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; "WaterkenTM
YURL -- What Does the 'y' Refer to?";
<http://www.waterken.com/dev/YURL/Definition/> ; June 2003.
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.
|