Recently, the Shmoo Group discovered that Firefox is vulnerable to precisely the exploit that i predicted in my 2002 paper—Ping
➡
➡
➡
➡
➡
➡
➡
➡

I’m ready to hear it. Perhaps you could just point me to some stuff on your YURLs. As you can see I was led in another sub thread to trying to bind a Petname to a certificate fingerprint. I’ll be interested to see if there is something comparable in your proposal, though you seem to object to cryptographic means. If you refer me to:

<waterken.com>

I don’t believe I see anything comparable there. It states the requirements but not how to meet them technically. When you say (in the above URL): __________
 Site authentication

A YURL MUST provide all the information required to authenticate the target site. Authentication of the target site MUST ONLY rely on information contained in the YURL. If any outside information were used for authentication, the creator of that information would have power to determine the target of sent messages, violating the y-property. In particular, any URL scheme that depends on the PKI for authentication, such as https, is not a YURL. __________

If my "YURL" was something like:

<paypal.com>

it would seem to be going directly against the idea of your YURL. Tell me why the above is inadequate. Tell me what you propose as an alternative.—Jed

For now, I am just going to give you some links. I really want to try the discussion in steps this time. We’ve had this discussion on cap-talk before (maybe before you arrived) and not made much progress. I suspect it’s because everyone just piles all naming related problems onto the discussion all at once, and then we circle around it endlessly. Petnames + YURLS + keyword servers do provide a complete solution, but I guess it’s just too much to communicate all at once. Petnames all on their own provide important and tangible benefits, and establishing that fact might make communicating the rest of the system easier.

The YURL Definition paper you’ve already seen is a requirements specification. The httpsy protocol is an implementation of these requirements. See:

<waterken.com>

This specification explains the crypto and networking part of the solution.

An example introduction scenario is examined in the paper at:

<waterken.com>

The home page for all these papers is at:

<waterken.com>

There are many papers under that root that explore different parts of the naming problem. Taken together, they might give you a more complete picture of what we have in mind. For now, I want to continue to focus the discussion on the phishing aspect. If we reach consensus on just that part, we will have made important progress, and done much better than we have on previous tries.—Tyler

Hooha! I’m delighted to see the YURL mechanism uses a "hash of a public key" (essentially equivalent to the certificate fingerprint I believe?). I just pulled that binding out of my a** for the discussion when I was trying to find a way to get involved. I’m glad to see some common thinking there.

I’ll try to use your syntax and mechanism in future as it seems clear you’ve put more thought into it that what I was making up on the fly.—Jed

A little sparse perhaps, but seems workable. —Jed

That sounds reasonable. To me it seems clear that isolating the name space and putting it under the users control (whether with Petnames or Petlogos or whatever) solves the business of managing the name space. Of course there’s still the issue of binding (I hope I using common terminology here) the name to a communicating entity (again terminology), but that seems to be where something like your YURL mechanism comes into play.—Jed

We all do our best... —Jed