- The y-property is implemented.
- Existing Transport Layer Security (TLS) infrastructure is leveraged.
- Existing WWW infrastructure is leveraged.
Authentication of TLS Upgrade Within HTTP/1.1
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 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.
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 = "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]
The semantics are that the identified resource is located at the server possessing the private key
corresponding to the public key having hash
A resource request MUST ONLY be sent over a TLS/1.0 connection to the server identified by the
A request URL contains a list of network location hints. This
For example, if the request URL is:
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
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
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
[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.
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.