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]]
Sent: Sunday, July 26, 2015 12:58 PM
To: Brian Campbell
Cc: John Bradley; Mike Jones; [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]<mailto:[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
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]<javascript:_e(%7B%7D,'cvml','[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]<javascript:_e(%7B%7D,'cvml','[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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
