Announcing httpsy://, a YURL scheme

[Tyler Close]

On Wednesday 16 July 2003 11:26, Perry E. Metzger wrote:
> It seems to me to be more "a bad idea, fully realized".

Perry, throughout this thread, you have made a number of factually
incorrect statements about YURL. Never have you provided an
argument to backup any of these statements. I know that you are
under no obligation to make rational arguments about my work, but
I fail to see how making irrational arguments is useful to anyone.
Calling my work vomit seems even more spurious.

> I'll repeat:
>
> 1) The "YURL" makes key management and replacement effectively
>    impossible.

False.

YURL makes key management *much* easier than it is under the PKI.
See:

http://www.waterken.com/dev/YURL/Why/#Certificate_lifecycle_control

The HTTPSY specification states that:

"The client MUST construct a valid PKIX certificate path to a
certificate that is signed using a public key whose hash matches
the hash in the URL."

This means that the public key hash contained in an httpsy:// YURL
is the hash of the public key of the root certificate. Should a
subject private key be compromized, the subject certificate can be
revoked and a new public/private key pair created and certified.
All existing YURLs remain valid.

For example, the YURL for the Waterken Inc. site is:

httpsy://r4wdwfrp37ii6qzjlyklkeacbe@waterken.com/

The private key corresponding to this public key hash has never
existed on the Waterken Inc. server. Should someone hack into the
server, I can set the site back up after reclaiming control of my
server.

Note that if you go to the Waterken Inc. site using the Waterken
Browser, the public key you will use for the connection is only
valid until Jul 26 16:50:33 2003 GMT. I only issued a certificate
for one month. At the end of the month, I will issue a new
certificate, closing the window of vulnerability for that
particular private key. All YURLs will remain valid.

I am actually practicing what I preach in the "Why use YURLs?"
document. Read it.

> 2) It leads to situations in which you have no way to know what sort
>    of trust relationship you have for the documents you're looking at.

Garbage.

As Mark Miller has so completely explained, there are only two
possible sources of trust in *any* distributed system: the creator
of the URL and additional sites that will vouch for the URL.

You always know how you got the YURL, because someone has to send
it to you and you have to receive it. At the very least, you know
how you got the YURL. This establishes your initial trust
relationship.

You can then amplify the trust relationship by asking another
trusted site to vouch for the YURL. In the Waterken Browser, this
is implemented through the Pet Name system. When you receive the
YURL, the browser looks it up in its database and tells you if the
target site is one you have already been introduced to. This
simple mechanism lets you combine introductions and manage trust
relationships.

These principles are explained in the YURL Definition, which you
dismissed as "peripherally interesting". See:

http://www.waterken.com/dev/YURL/Definition/

> 3) It is impossible for people to determine that a "YURL" actually is
>    what it claims it is, given that most people can't actually
>    remember one hash, let alone large numbers of them, etc.

I can make no sense of this statement.

First, a YURL doesn't claim to be anything. No URL does. The
creator of a URL makes a claim. Other sites may also make claims.

No one is being asked to remember any hashes. This has been
pointed out to you multiple times, by multiple different posters.
This is the whole point of the YURL Trust Management document.
See:

http://www.waterken.com/dev/YURL/Name/


I don't want this to be a confrontational discussion. I am
saddened that it has become one. Please stop making baseless
denigrations of my work. I am eager to receive constructive
criticism, will receive it with grace and use it to build the best
solution to our common problem. However, if you insist on calling
my work vomit, then I will defend my work with equal zeal.

Tyler

-- 
The union of REST and capability-based security:
http://www.waterken.com/dev/Web/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com