Subject: [jose] draft-jones-jose-jws-signing-input-options 00

From: "Jim Schaad" <[email-masked]>
Date: Sun, 2 Aug 2015 21:01:34 -0700

The following represents my review of the document.

*  The justification for this document seems to be rather odd.  There is a
problem with the "compact" form of JWS and the fact that the bodies are too
large.  This seems to be rather contradictory.  Why would having a compact
form be the case that is having problems with size

* Abstract - second paragraph is a restatement of the first paragraph - this
is unnecessary.

* There is only one API that I am aware of that does not support an
"Initialize, Update and Finalize" API for dealing with hash functions.  That
is the W3C WebCrypto API.   Are there others that have the same issue?  Does
the W3C have plans to change this so that hashing is not an atomic
operation?

* I don't know about Phil, but Anders wants to have clear signed for
debugging purposes among other things.  He just wants to be able to read the
message w/o the base64 decoding issues. Nothing to do with what you are
suggested the reasons are.  I don't know that either of them are interested
in the compact serializations.  The fact that you are not removing the
base64 encoding on the transmitted protected header means that you are not
getting all of his issues solved with this approach.

* You have a major security problem with this proposal
SIGN({"sph":false, "b64":false}, "ABC") === SIGN("sph":false, "b64":true"},
"ABC")
But I did not sign the same content.  There are lots of other ways that you
can play games.  Consider for example putting all of the message, with
periods, in the body and say don't sign the object.  It would still have the
same signature but totally different meanings.

* If the values of sph and b64 are going to be fixed by the application and
are not intended to be changed on a per message basis, why are they even
parameters?

* Given that a double-quote will be quoted if contained in a string for json
serialization, I don't understand the delimiter issue for it.   You are
signing the in memory representation and not the JSON serialized version.
This entire issue needs far better text than it has.

*  How do I go back and forth between compact and non-compact
representations if I am signing w/o b64 and there is a period in the
message.   It does not seem to be possible.

* 7.2 para #2- what is the second property?  The first is changes in payload
transmission

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 3 Aug 2015 11:38:58 +0200

I may have read this in too big haste and my experience with JWS is not very deep but FWIW, here are a few initial comments.

1. Detached versus in-line signatures
It seems that there is no syntax separating these use-cases.
Shouldn't there be one?

2. In-line JWS
I (like Jim) don't understand the delimiter requirements.
The only requirement I can come up with is that the content within "" MUST be valid UTF-8, JSON serialization does the rest.

The W3C Web Payments Interest Group (http://www.w3.org/Payments/IG/) have requested a review (for applicability) of the JOSE specifications.
Although I'm not a member of this group, I intend to perform such a review which will also relate to this specification.

thanx,
Anders

---

From: "Nat Sakimura" <[email-masked]>
Date: Mon, 3 Aug 2015 19:26:18 +0900

Hi

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Monday, August 03, 2015 6:39 PM
> To: [email-masked];
[email-masked]
> Subject: [jose] draft-jones-jose-jws-signing-input-options 00
> 
> I may have read this in too big haste and my experience with JWS is not
very
> deep but FWIW, here are a few initial comments.
> 

In case of detached signature, there will be two consecutive periods "."
after the header section.

> The only requirement I can come up with is that the content within "" MUST
be
> valid UTF-8, JSON serialization does the rest.
> 
> The W3C Web Payments Interest Group (http://www.w3.org/Payments/IG/) have
> requested a review (for applicability) of the JOSE specifications.
> Although I'm not a member of this group, I intend to perform such a review
which
> will also relate to this specification.
> 
> thanx,
> Anders
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 04:29:53 +0000

Thanks for your review, Jim.  I've attempted to address your comments in the -01 version.  Responses are inline below.

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Sunday, August 02, 2015 9:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [jose] draft-jones-jose-jws-signing-input-options 00

*  The justification for this document seems to be rather odd.  There is a problem with the "compact" form of JWS and the fact that the bodies are too large.  This seems to be rather contradictory.  Why would having a compact form be the case that is having problems with size

This is about both serializations and the motivating problems can occur in both.  I've added a JWS JSON Serialization example in -01.

* Abstract - second paragraph is a restatement of the first paragraph - this is unnecessary.

Thanks - simplified.

* There is only one API that I am aware of that does not support an "Initialize, Update and Finalize" API for dealing with hash functions.  That
is the W3C WebCrypto API.   Are there others that have the same issue?  Does
the W3C have plans to change this so that hashing is not an atomic operation?

"sph" is gone by popular demand now, so this is no longer pertinent.

* I don't know about Phil, but Anders wants to have clear signed for debugging purposes among other things.  He just wants to be able to read the message w/o the base64 decoding issues. Nothing to do with what you are suggested the reasons are.  I don't know that either of them are interested in the compact serializations.  The fact that you are not removing the
base64 encoding on the transmitted protected header means that you are not getting all of his issues solved with this approach.

He can do that if he uses "b64":false and "header" rather than "protected" with the JWS JSON Serialization.

* You have a major security problem with this proposal SIGN({"sph":false, "b64":false}, "ABC") === SIGN("sph":false, "b64":true"},
"ABC")
But I did not sign the same content.  There are lots of other ways that you can play games.  Consider for example putting all of the message, with periods, in the body and say don't sign the object.  It would still have the same signature but totally different meanings.

"sph" is gone, so this is no longer pertinent.

* If the values of sph and b64 are going to be fixed by the application and are not intended to be changed on a per message basis, why are they even parameters?

So that the encodings are explicit.  If "b64":false is omitted but assumed, some are sure to use standard JWS libraries without the extension to emit and consume the JWSs, causing interop problems.

The better text is in the new section https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-01#section-5.

*  How do I go back and forth between compact and non-compact representations if I am signing w/o b64 and there is a period in the
message.   It does not seem to be possible.

The last paragraph of Section 5 addresses this explicitly.

* 7.2 para #2- what is the second property?  The first is changes in payload transmission

The other is restricting the characters used to those that can be successfully parsed.

				Thanks again,
				-- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 00:12:17 -0700

> From: Mike Jones [mailto:[email-masked]]
> Sent: Sunday, August 09, 2015 9:30 PM
> To: Jim Schaad; [email-masked]
> Cc: [email-masked]
> Subject: RE: [jose] draft-jones-jose-jws-signing-input-options 00
> 
> Thanks for your review, Jim.  I've attempted to address your comments in
the -
> 01 version.  Responses are inline below.
> 
"Initialize,
> Update and Finalize" API for dealing with hash functions.  That
operation?
> "sph" is gone by popular demand now, so this is no longer pertinent.

Why is this not pertinent?  One could, for example, base64 the content and
hash it in chunks if one has a hash function that does IUF processing.

> * I don't know about Phil, but Anders wants to have clear signed for
debugging
> purposes among other things.  He just wants to be able to read the message
w/o
> the base64 decoding issues. Nothing to do with what you are suggested the
> reasons are.  I don't know that either of them are interested in the
compact
> serializations.  The fact that you are not removing the
> He can do that if he uses "b64":false and "header" rather than "protected"
with
> the JWS JSON Serialization.

And this means that none of the controlling header data would be
authenticated correct?  That might not meet his needs.

An example of this would be :

SIGN("", "ABC") === SIGN("","ABC")
Where in one case headers says "b64":true and the other says "b64":false.
Same signature but different implied content.

> 
> * If the values of sph and b64 are going to be fixed by the application
and are
> not intended to be changed on a per message basis, why are they even
> parameters?
> 
> So that the encodings are explicit.  If "b64":false is omitted but
assumed, some
> are sure to use standard JWS libraries without the extension to emit and
> consume the JWSs, causing interop problems.

That seems to be a problem anyway.  If your library does not support b64
detection it will still do bad things.

> The better text is in the new section
https://tools.ietf.org/html/draft-ietf-jose-
> jws-signing-input-options-01#section-5.

Are % characters URL safe?  What if my content for compact is %24.02 (or
whatever the correct code for $ is).  Would I remove that serialization as
well?

The entire question of signing an in memory version vs a serialized out
version need to be much clearer than it is. There is an implication that
content-encoding would be removed but that should be made explicit for
detached contents as well as JSON serialization contents.  

> The last paragraph of Section 5 addresses this explicitly.

Given the update to section 6 - does this document need to make an "updates"
on JWT?
> The other is restricting the characters used to those that can be
successfully
> parsed.

Yes - that is part of payload transmission changes.

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 16:23:16 +0000

Thanks for your continued useful comments, Jim.  Replies inline...

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Monday, August 10, 2015 12:12 AM
> To: Mike Jones; [email-masked]
> Cc: [email-masked]
> > To: Jim Schaad;
> > [email-masked]
> > Cc: [email-masked]
> Why is this not pertinent?  One could, for example, base64 the content and hash
> it in chunks if one has a hash function that does IUF processing.

I wrote that it was no longer pertinent because the motivation for "sph" was to avoid having to prefix the payload with the "." character, so as not to have to do the copy when the MAC or signature function didn't support passing in multiple pieces from different buffer locations.  As you pointed out, WebCrypto is such an API.  Now that "sph" is gone, we've accepted that there will always be a "." prefix and sometimes also a protected header prefix before the payload, whether the underlying crypto APIs require a single contiguous input or not.

> > the base64 decoding issues. Nothing to do with what you are suggested
> > the reasons are.  I don't know that either of them are interested in
> > the
> compact
> > base64 encoding on the transmitted protected header means that you are
> > not getting all of his issues solved with this approach.
> >
> And this means that none of the controlling header data would be authenticated
> correct?  That might not meet his needs.

I'm discussing that with him in the thread "[jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00".  We'll see what he says.

> Same signature but different implied content.

I don't understand your example above.  Can you be more explicit about the inputs, outputs, and the issue you're discussing?

> > are sure to use standard JWS libraries without the extension to emit
> > and consume the JWSs, causing interop problems.
> 

Yes, but you won't be able to have the case of a library that does support the extension and the programmer forgot to set the don't-encode-the-payload flag when calling the library.  Instead, that flag is, by design, explicitly carried as a header parameter value, so can't be forgotten by the programmer at calling time.

> > * Given that a double-quote will be quoted if contained in a string
> > for
> json
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.
> org%2fhtml%2fdraft-ietf-jose-
> &data=01%7c01%7cMichael.Jones%40microsoft.com%7c2f549669ca5a475fa33
> 608d2a152f993%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Qlvvwz6
> 2JX2%2bLpuKvsnYYOSdmaAn%2fIBAP8lbrG3zvCE%3d
> whatever the correct code for $ is).  Would I remove that serialization as well?

That's a good question.  More to the point, would we want to consider allowing the period to also be escaped by representing "$.02" as "%24%2E02", rendering the payload URL-safe and parseable.  It would mean that we would end up defining that RFC 3986 percent-encoding be used for unencoded JWS Compact Serialization payloads, when needed.

What do others think about whether we should go there or not?  To me, it seems like a worthwhile experiment to at least write it down and see what we think of it.

> The entire question of signing an in memory version vs a serialized out version
> need to be much clearer than it is. There is an implication that content-encoding
> would be removed but that should be made explicit for detached contents as
> well as JSON serialization contents.

Yes, we should be explicit that content-encoding be removed when b64:false is used.  Thanks for the comment.

> Given the update to section 6 - does this document need to make an "updates"

I suspect that's probably an appropriate action.  Jim, Kathleen - you're the experts here.  Should we add an "updates" directive, given that the draft includes the following language?
	JSON Web Tokens (JWTs) [JWT] MUST NOT use "b64" with a "false" value.

> Yes - that is part of payload transmission changes.

				Thanks Jim,
				-- Mike