Multiple people have given feedback that they're uncomfortable with the "sph":false option in https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00. Martin Thompson's review<http://www.ietf.org/mail-archive/web/jose/current/msg05158.html> expressed reservations similar to those raised at the microphone during the ACME meeting in Prague, and similar to those John Bradley shared with me there in person.
The gist of this security argument is as follows... Assume you have an encoded protected header value H in which "sph":false is not present and a payload P. Let S be the JWS Signature of H || "." || P, Now, construct a new payload P' := H || "." || P. The JWS Signature of P' when using "sph":false is also equal to S. Being able to generate the same signature for two payloads, one of which adds a prefix to the other, seems like a potential security issue. (I *believe* that the JWS JSON Serialization's unprotected headers don't introduce that problem because the "." is still always included in the JWS Signing Input, thus delimiting the headers and the payload.) Another objection to "sph" was raised by Matias Woloski<http://www.ietf.org/mail-archive/web/jose/current/msg05191.html>, who stated that including "sph" seemed like a premature optimization. The rationale for having "sph":false is that for massive payloads, it may be an important performance optimization not to have to malloc a buffer big enough to hold the concatenation of the protected headers and the payload and copy them to the buffer - only for the purpose of calling the sign() function on the concatenation. If you can call sign() on the bare payload you already have, you never have to copy it. "sph":false with "b64":false enables this. What do you think? Should "sph" stay or should it go? -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
