I am fine as well but I am curious to hear the opinion of the person who proposed it.
On Saturday, July 25, 2015, Brian Campbell <[email protected]> wrote: > I'm in favor of dropping "sph" > > On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> 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] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> 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] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://www.ietf.org/mailman/listinfo/jose >> >> > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
