On Mon, Apr 6, 2015 at 3:20 PM, Joe Hildebrand (jhildebr) <[email protected]> wrote: > On 4/3/15, 11:26 AM, "Martin Thomson" <[email protected]> wrote: > >>I share Matt's reservations about the delimiting here. That part is >>fundamentally broken. > > As do I. json-text-sequences (RFC 7464) was designed for this sort of thing, > as Justin Richer mentioned. You could at least take the idea from there of > using an ASCII RS as the separator, since it is not valid JSON.
I think the RS character makes better sense. The only reason I did not use it before was to try to make the changes as minimal as possible and see what people argued for. >>I don't share his concerns about the canonicalization. That denies >>PHB's basic thesis, which I agree with. If you have a transport that >>is 8-bit clean, you can trivially preserve the JSON, as serialized and >>you have exactly as many issues as JOSE has already. > > It would have to be both 8-bit clean, tolerate newlines, and if the payload > isn't detached, you're severely limited in what could be sent. Limited to > the point where I'm worried the approach would work terribly well in practice. HTTP is 8-bit clean. Always has been. Anything is not MUST break. End of story. I am not worried at all about signatures breaking when they go through non compliant HTTP proxies. That is what the signature is there for. Streaming is a much harder proposition. Because many implementations of the HTTP streaming spec are broken and don't handle trailer headers that I added for the express purpose of supporting streamed signatures. It is only useful to put the header at the end if you have streaming capability. And right now you would have to have two nested chunking schemes or write a new chunking scheme for HTTP. Either is possible of course. But once you get into chunking schemes then you might as well use JSON-B which supports chunked binary blobs as a replacement for base-64 encoded text. Or some other binary encoding of JSON. Fortunately it is not one that is in the slightest bit relevant to ACME or 95% of Web Service transactions. The messages are all compact enough to process in one chunk. > Do we have one of these transports in mind, by the way? HTTP >>Saving the base64 encoding probably saves more bytes than moving to a >>completely >>new format. > > Probably, but I'm also worried the need to keep the original text around > after parsing to avoid the need for canonicalization. The extra memory > associated with that isn't a good fit for smaller devices, and is an > attractive nuisance for developer shortcuts. I don't see the problem. The proper tool chain is 1) Parse signature header, identify data bytes 2) Check signature 3) Pass data bytes to JSON parser. There is no need to keep the data bytes after the signature is checked unless they are going to be passed on to another system. If you have a constrained device it should not be an intermediate party in a three party transaction. >>If you really cared about saving bytes, you would drop the text labels >>and move to a schema-based binary encoding, or at least integer keys. > > ASN.1 is a schema-based binary encoding, so we already have one of those in > CMS. Integer keys help, but help a lot more in an encoding that uses 1 byte > for the oft-used small integers (as CBOR does). Or use a dictionary to compress the tags with an option to pre-exchange which JSON-C does. The dictionary can then be compiled incrementally or exchanged inline as the circumstances require. >>I don't see a significant gain in moving to COSE, unless you have a >>lot more base64 to remove from the protected header. But if you are >>shipping a lot of bytes in the header, I'd suggest that you might be >>past the point where you should be concerning yourself with saving >>space. > > I only see a gain in moving to COSE if you're going to use it throughout. > For non-clean transports like http: URLs, you can always base64 at the end, > and save some processing time and space. If you are using a data encoding that has direct support for binary, there is no need for this particular scheme. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
