On Thu, Jun 1, 2017 at 3:18 AM, Mike West <mkwst@google.com> wrote: > https://tools.ietf.org/html/draft-thomson-http-mice, is, I think, the > link you were looking for. > > >> That also suggests an enhancement for integrity more generally. >> > > I think it's a reasonable one, pretty much in line with what agl@ was > proposing a million years ago. We never ran with his proposal because folks > were concentrating on scripts and style (which are processed atomicly), and > the complexity of streaming was hard to justify. > Yep. An unbalanced Merkle tree is the only reasonable solution that I'm aware of. An open question is whether the hashes should be distributed throughout the file (as I think I prefer, and Martin proposes) or served all at the beginning in an HTTP header. The latter allows the same resource on disk to be used for fetches both with, and without integrity, but is a bit shitty. On your work: >> One major limitation of using ed25519 is that you can't incrementally >> calculate the signature; you should at a minimum consider the >> pre-hashed variant if you intend for this to be universally >> applicable. The draft above would be trivial to get to work with >> ed25519. >> > > I don't know enough in this space to have an informed opinion about the > options. CCing agl@. :) > The current SRI assumes that resources are small and not incrementally parsed, so ed25519 fits nicely. Combining ed25519 with an unbalanced Merkle tree effectively does make it the pre-hashed version, so that's fine too. So, if SRI sticks to it's current goal of only covering small resources, ed25519 seems applicable. If it wants to cover large resources, support for Merkle trees is needed and then we effectively have ed25519ph already, or we can actually use ed25519ph on the basis that we're already there and why hash the first record twice? Cheers AGL
Received on Thursday, 1 June 2017 18:54:59 UTC