Ooops, that was an oversight in the draft, sorry. I did actually go so far as to specify the allocation of a di .well-known code point, I just forgot to use it!
The URL was meant to be: https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug... Sorry for the confusion. On Mon, Oct 3, 2011 at 10:02 PM, Thomson, Martin <[email protected]> wrote: > On 2011-10-04 at 07:40:56, Phillip Hallam-Baker wrote: >> http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt > ... >> * Scheme for specifying one or more locations for retrieval > > Please don't use /.well-known/ without some sort of extra qualification. My > "mu" digest produces base-64 output that could collide with existing > registrations in that space. It's just like a game of "battleship". I'm > really hoping to hit "host-meta" some day... > > What do you think of: > > di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=https://di.example.com/r/ > or > di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=https://di.example.com/r/{d} > > ...where retrieval is performed using: If we went this route I can't see why the digest would appear anywhere other than the end so why not just specify it as a prefix? The slippery slope there would be people looking to take parts of the digest and the algorithm in mix 'n match type approaches. Since this is a domain specified in a fairly tightly controlled URL, I don't see why collisions with other services can't be handled by people creating a new sub-domain specially for di content if required. I am not completely happy with .well-known, it is a yucky approach, but it is now sufficiently well established that it is probably OK. >> * Scheme for decrypting encrypted stored content. > > I don't see the encryption and content type parameters as a necessity. If > the core goal of the document is to identify a resource, then providing > resource metadata is, as a generic capability, very useful. However, the > specific subset of cases you have chosen exhibits a bias that might not fit > with all future uses. > True in the case of encryption, but I prefer to do stuff once if possible. The fact that there are parameters and the space is extensible means that there is room for other uses. The content type is essential meta-data if the digest is going to be used to create a strong reference to the specified content. Otherwise the attacker can repurpose an image/jpeg as application/script. This works much better than it should because most processors simply ignore content they don't understand and helpfully try to resynchronize. This creates attacks where the attacker can smuggle his malware into a photosharing site and then get links to it. It would create a new class of cross-site scripting attack if it was not present. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
