Thanks for the clarification. Then it would be fine to remove it.
Nat On Sunday, July 26, 2015, Mike Jones <[email protected]> wrote: > I defined “sph” based on a conversation I’d had earlier with Matt Miller > about a use case he has with huge payloads in a browser application. He’d > told me that having to do the allocate and copy could be a significant > performance hit. However, I followed up with Matt in Prague, and it turns > out that his application is encrypting the content – not signing it. So > the JWS Signing Input Options spec doesn’t apply to it. > > > > -- Mike > > > > *From:* Nat Sakimura [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] > *Sent:* Sunday, July 26, 2015 12:58 PM > *To:* Brian Campbell > *Cc:* John Bradley; Mike Jones; [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > *Subject:* Re: [jose] Feedback on dropping "sph" header parameter > > > > 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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > I'm in favor of dropping "sph" > > > > On Sat, Jul 25, 2015 at 11:04 AM, John Bradley <[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]> > 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-00&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2b50KVTBqod7N9hI%2bGLe6UoGCvXpUVnqXv1vV277xXiU%3d> > . Martin Thompson’s review > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05158.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I426zdg%2fj4QhCDajn6DsF9oPfXKd3fzO3Yy0oMymYzo%3d> > 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05191.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B2xKzGMLIpeMOwDLCWlmsbutNcfLBuFUcadzeEStG5I%3d>, > 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 > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d> > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rk1ulDqmu8%2fAFXq6itfdRPHzi9m%2fi5T2ML8uQ3XLNR0%3d> > > > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c035b7d335e97463b76a108d295f48916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DawUq1rv%2ffF2A0LNzcU67SeBQnbY8s6RMCheoCSV3e0%3d> > @_nat_en > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
