-----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
