I share Matt's reservations about the delimiting here. That part is fundamentally broken.
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. Saving the base64 encoding probably saves more bytes than moving to a completely new format. 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. A format without OIDs could be extremely compact. But part of the point of JOSE is to avoid that muck, and the gains aren't significant. 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. On 3 April 2015 at 09:30, ⌘ Matt Miller <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 3/25/15 10:14 AM, Phillip Hallam-Baker wrote: >> The revised draft is now up. It is essentially a one pager. Which >> turns out to be five with the boiler plate and IANA section. >> >> http://tools.ietf.org/html/draft-hallambaker-joseunencoded-01 >> >> 2. Serialization >> >> In the JWS Direct Serialization, no JWS Unprotected Header is >> used. In this case, the JOSE Header and the JWS Protected Header >> are the same. >> >> In the JWS Direct Serialization, a JWS is represented as the >> concatenation: >> >> UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' || >> >> (JWS Signature) >> >> The calculation of the signature is performed over the octet >> sequence that corresponds to the concatenation: >> >> UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' >> >> _______________________________________________ jose mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/jose >> > > Here is my review of draft-hallambaker-joseunencoded. > > In summary, I think this draft has serious issues. > > I assume the following: > > UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' || (JWS > Signature) > > Means that the JWS Protocted Header is the JSON-Object structure > (possibly, or not, including insignificant-to-JSON whitespace), and > the JWS Payload and JWS Signature are the exact octet values -- no > escaping or other armoring (e.g., base64url encoded). > > Using '.' as a delimiter without preparation of the inputs can lead to > ambiguous results. A '.' in the JWS Payload makes it impossible to > determine where the payload ends and the signature or MAC begins. > Similarly, a '.' in the JWS Signature causes the same problem for > searching from the end. A '.' in the JWS Protected Header requires > non-trivial preprocessing of the input in order to determine where the > JSON structured JWS Protected Header ends and the JWS Payload begins. > Some form of TLV-like container would help alleviate this problem, > such as CBOR. > > Using the JWS Protected Header without any form of canonicalization or > other armoring can lead to signature/MAC verification failures due to > differences in how various JSON implementations parse and serialize. > Some generators add extra whitespace; many parsers don't retain the > order of name/value paris within a JSON-Object; others; and there are > other subtle differences that can cause serious problems with > on-the-wire consistency. This problem might be mitigated by requiring > consumers to retain the original "UTF8(JWS Protected Header)" value as > well as requiring producers to remove all insignificant whitespace > before using the UTF8-encoded header to generate the signature/MAC and > emitting the Compact Direct Serialization. Verifying this on the > consumer side would be expensive. I'll note that CBOR provides > canonicalizaation guidance; this JSON problem seems to be far better > mitigated there. > > > - -- > - - m&m > > Matt Miller < [email protected] > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJVHsA3AAoJEDWi+S0W7cO1qh4H/2rw97xHZeKU///CBHMKB7v8 > Z+vKEoHFVzW9dbfnJyDdSRiWUbaSw+M+mZhfjgm8rJq4h/dOZzt0+7+kw+EZnegH > to6q+x+2DZyO2tiPlVwT/TygUOVkU5q12dmwCS6IIVITrA9vfiWonCMRYV1mPx1d > S74LIx8n2TTbJ8rxNWw7ALO7VT++X+flSKSEONxYyRks3tDT8bmYOqjUaqwnUiiO > GoyAki663KsbY75C+vdqJ0fKgh2ZRLG50PFe1xXD92vI/Vvj09VclZYqWSwpxZaC > 5hVTZ1yGJTCrkpEjppmDmpty9y0j6sbcpYBd0ZdUYSXRR7fu+yHX68j6P6wMmC0= > =dSL4 > -----END PGP SIGNATURE----- > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
