On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > OK, but why not put all of this into the headers anyways? > > Well that is what I suggested in my Content-Signature work and that is > exactly how my code works today. But folk proposed introducing the > signature in the HTTP content segment and that forced me to think about > which approach is better.
Your approach looks like a Transfer-Encoding to me. If that's what it looks like, and that's what it walks like, [and that's what we want,] then that's what it should be. > I think I can make a good architectural argument for the JSON Container > approach and besides which it is really useful at the file system level. You want the contents of the object to include the signature?? I mean, I've wanted filesystems to expose some internal metadata (e.g., a Merkle hash tree root hash for a file's content, with those parameters needed to reconstruct the same hash from just the contents, namely, the shape of the tree and the size of each non-tail block of contents). But making this part of the contents instead of the metadata strikes me as rather problematic. > Separating out protocol data from content-metadata is long overdue. Maybe, but I do want POSIX to continue not commingling contents and metadata. > > > Notice how we have just developed a format that allows us to sign a > > > complete code distribution including content data very easily. This is > > > obviously out of scope for ACME but the fact that an approach transfers > > so > > > neatly to a completely different problem suggests that it is the right > > > track. > > > > Wasn't JOSE about this sort of thing? > > Sort of. That might be where we eventually do the work. But the > requirements would be ACME in the first instance and the constraints from > JSON. I would see JOSE as being something we just plop in and should work > (or else they have some splainin' to do. I meant: why not use whatever JOSE delivered? Nico -- _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
