I attempt here to describe the working of the YURL with minimal SSL cert jargon but assuming common notions of the URL and public key crypto. I also rely on classic ideas of symmetric crypto (secret key crypto). httpsy is a protocol proposed for YURLs which shares many of the https mechanisms. Here are some ramifications of broad-spread availability of this technology.
The problem that we address is to make a string of characters, like an URL, reliably designate a unique computer, the ‘site’, on Internet despite mischief in the network between the browser and the site.
In particular we do not rely on certificate authorities, nor do we rely on the user verifying that the domain name that appears in the browser address bar is as expected.
We call the string a YURL and hope that it will often serve where URLs serve without changes to the code written to deal with URLs.
The YURL is like the URL except for including a fingerprint for the public key of the intended site.
When the browser interprets a YURL it uses the domain name in the YURL to get an IP address as usual.
Note that no cert like functionality beyond carrying the public key is involved. There is no cert signing and certainly no PKI. Yet we establish a firm connection between the YURL and the site. We do rely in this scenario on the domain name service to provide an accurate IP address. If the service delivers a wrong IP address, or IP routing is compromised, the bogus site will be unable to deliver a public key whose fingerprint matches that in the YURL, unless it delivers the good site’s cert. If the bogus site responds with the real site’s public key then it will be unable the decipher the symmetric key proposed by the browser. If DNS fails to deliver a good IP address then the style of URL with real IP addresses in them will serve for many uses.
Some will be shocked to note that the domain name in a YURL conveys no ‘authenticated’ information about who operates the indicated site. What they achieve instead is that when X accurately transmits a YURL to Y, that YURL accesses the same site for both X and Y. When one opens a bank account it would be wise in this plan to pick up a card at the bank with the bank’s YURL printed on it. This does not seem onerous.
A new sort of site might arise that provides YURLs to well known institutions. I call such a site a register here. A register might include an entry such as:
Unlike certificate authorities this site has no legislated authority; it must maintain its own reputation and is chosen by the user of the browser. The user may be vulnerable to the site he chooses, but is not vulnerable to all CAs as in PKI.
Perhaps the following is safe and solves the ‘CitiBank problem’. The site normally responds with a chain of certificates, each signing the next. If the browser is validating a YURL, and an allocated bit in the YURL is 1, then it follows the chain comparing the fingerprint of each cert with that found in the YURL. If one of them matches the YURL is OK. Logic much like this is already found in the browser.
A more complex browser function would consult your favorite register. For each new fingerprint the browser consults a local register cache to report in the browser address bar if the current site was one of your commonly destinations. A site pretending to be BofA would not be and the address bar would make this plain.
The fingerprint in the key must be long enough to protect against an offline search for a public-private key pair with the same fingerprint. Using a subset of the public key’s bits for the fingerprint invites a class of attack using elementary number theory and so I advocate using however many bits security demands, of a secure hash of the public key. It is not necessary for the fingerprint length of all YURLs for a particular site to agree.
The proposed httpsy format specifies the full SHA-1 form of fingerprint and of the whole 509 cert. The ‘hints’ mechanisms there provides a strong mechanism to survive DNS attacks. It requires a bit more browser function related to DNS lookup. In that context corrupted IP routing can deny service but cannot breach security.
A YURL, like an URL, may contain an IP address in place of a domain name. To achieve the host authentication provided by TLS, the URL must contain the domain name which is compared by the client with that found in the cert. YURL authentication does not depend on this comparison.