home -> developer -> YURL -> httpsy

previous version

WaterkenTM YURL

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 a mandatory 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 using a public key having the expected hash.


Design goals

  1. The y-property is implemented.
  2. Existing Transport Layer Security (TLS) infrastructure is leveraged.
  3. Existing WWW infrastructure is leveraged.
  4. A migration path is provided for existing HTTPS client software.

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]

Migrating existing HTTPS client software

Deploying upgraded client software takes time. A mechanism is provided for optionally falling back to the HTTPS protocol when the client software does not yet support the HTTPSY extension. This option is at the sole discretion of the issuer of the URL.


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.

A subset of the existing https URL scheme is also defined. An https +-subset URL identifies a resource that can be accessed using either the HTTPSY extension or the HTTPS protocol. An https +-subset URL is identified by a userinfo field that begins with a '+' character.

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 https scheme +-subset

The https scheme +-subset is a hybrid scheme combining the properties of the httpsy and https schemes. This section defines the scheme-specific syntax and semantics for https +-subset URLs.

    https_URL = "https:" "//+" key-id "@" locator [ abs-path [ "?" query ] ]
    locator = host [ ":" port ]

When interpreted by an HTTPSY-unaware client, the semantics for this scheme are necessarily the same as for the https scheme. As specified by RFC 1738, the client will treat the +key-id@ portion of the URL as a userinfo field. [RFC 1738] This userinfo field will go unused in accessing the target resource.

When interpreted by an HTTPSY-aware client, the semantics for this scheme are the same as for the httpsy scheme. An HTTPSY-aware client MUST recognize an https +-subset URL by checking for a userinfo field that begins with a '+' character.

Issuing an https +-subset URL is only safe when the authentication results of both HTTPSY and HTTPS can be considered equivalent. In particular, the URL issuer MUST have the private key for a PKI certified certificate for the host, and be willing to trust the PKI. This trust requirement means that an https +-subset URL is not a YURL. [YURL]

The https +-subset is only provided as a temporary bridge to enable deployment of HTTPSY server applications during the rollout of HTTPSY client applications. A server that supports https +-subset URLs MUST also support httpsy URLs. Any resource identified by an https +-subset URL MUST also be identified by an httpsy URL constructed by changing the scheme.

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.

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 mandatory upgrade request, as specified in section 3.2 of RFC 2817. The upgrade request MUST additionally include a Key-Identifier header that contains the key-id in the request URL. The Key-Identifier header is only provided in an upgrade request, it MUST NOT be provided in a resource request.

If a server does not accept an upgrade request, it SHOULD respond with a 3xx redirection. The client MUST follow at least one automatic redirection, but SHOULD NOT automatically follow more than one. 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. The client MUST continue searching until a server is successfully authenticated, or the client has determined that none of the provided locators lead to a server that can be authenticated.


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. Only the httpsy URL scheme is used in this case, not the https +-subset URL scheme.

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 +-subset URLs. As previously described, the only difference between these URLs is the scheme name. 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.

[RFC 1738] T. Berners-Lee, L. Masinter and M. McCahill; "Uniform Resource Locators (URL)"; RFC 1738; December 1994.

[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.


Copyright 2002 - 2003 Waterken Inc. All rights reserved.

Valid XHTML 1.0! Valid CSS!