On 2011-10-04 at 13:53:53, Phillip Hallam-Baker wrote: > The URL was meant to be: > > https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug...
ACK. > 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? While this assumption is true for HTTP, can you say the same for other URI schemes that support retrieval of the representation of a resource? To cite a (relatively bad) example: a 'pres:' URI supports retrieval using SIP (and XMPP). Depending on circumstance, that looks like 'user@host' where user might filled with your digest bits. > The slippery slope there would be people looking to take parts of the > digest and the algorithm in mix 'n match type approaches. It might be better to ride the slope the whole way down. Include the whole URI. You might also like to consider registering a Link relation (RFC 5988) for "digest". > Since this is a domain specified in a fairly tightly controlled URL [...] That's a pretty big assumption, almost as much as I dislike the /.well-known/ use. > 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. You aren't making the world a less safe place if you leave the problem alone. Or have I missed something. What makes this scheme any worse for the attack, other than its inherent opacity? Regarding de/encryption keys: Is it really the case that you need to decrypt before calculating the digest? Excuse my ignorance, but for a file store, I would have thought that encryption would want to come before storage. --MartinT _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
