This has now been dropped, by popular demand. From: Nat Sakimura [mailto:[email protected]] Sent: Sunday, July 26, 2015 1:16 PM To: Mike Jones Cc: Brian Campbell; John Bradley; [email protected] Subject: Re: [jose] Feedback on dropping "sph" header parameter
Thanks for the clarification. Then it would be fine to remove it. Nat On Sunday, July 26, 2015, Mike Jones <[email protected]<mailto:[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]<mailto:[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]<mailto:[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://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]<mailto:[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]<mailto:[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/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cc9be6657f4194ca5b32008d295f70a5e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4QCA6q5FWNwGxDRZ83yFS%2faLW9MFCQWEIqJwlUoplRY%3d> @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
