I think dropping it and letting the implementations decide how to deal with the buffer issue, is best. I don’t think it is a good tradeoff unless there is no way for implementations to deal with it.
John B. > On Jul 25, 2015, at 6:12 AM, Mike Jones <[email protected]> wrote: > > Multiple people have given feedback that they’re uncomfortable with the > “sph”:false option > inhttps://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-00 > <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose > <https://www.ietf.org/mailman/listinfo/jose>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
