"Perry E. Metzger" wrote: > 1) The "YURL" makes key management and replacement effectively > impossible.
Well, I would have said it suggests a different method. Instead of regimented, hierarchical and fixed key management - an idea of poor track record - the key management issue here is pushed back to the user & client. It relies on browser assistance in caching, and correlation between many introducers. In comparison to the CA regime, there is additional trust from the people who send out URLs with this information embedded. If you trust the introducers then you can trust their information. That doesn't mean that it is perfect, it just adds more security than an absence of information. I grant you that an either/or approach is a tough sell. The YURL would be improved if it explicitly included a method to reference the hash of a CA-cert, and to incorporate that additional information into its trust display to the user, IMHO. More information is generally better. (In comparison to the HTTP regime, as opposed to the HTTPS regime, this is much better method than having no trust at all.) > 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. I don't understand this. If Alice sends Bob a URL with a hash in it, then Bob can apply the same trust that he would apply to anything that Alice sent. The same metric applies to an attachment. If Alice sends some thing.exe around, Bob will have the same procedure in deciding whether to trust it as not-a-virus, or in how to increase your level of trust. Alternatively, if the URL with hash arrives from some unknown source, yes, this is untrusted! But, it is no more untrusted than the previous scenario sans hash. How can that be a problem? We've gone from untrusted to untrusted in one seamless step. I wouldn't pay for that as a feature, but I wouldn't grumble about it either. > 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. Right. I don't think the YURL really meant for people to read the things. It could be better explained, the browser has to record and correlate the hashes. Which is, really, how it is now for most use cases, as we see long complex URLs all the time (click on amazon for example) and without the browser to interpret these things, we in userland are lost already. > Those are just some of the more obvious issues. I think it is a mistake to compare the URL+hash idea to some existing security model such as is purported by, for example, https. It really sits closer to raw HTTP - which is where most of the live usage is, and where all of the problems lie. >From that pov, it adds security, in absolute and relative senses. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
