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

From: Mike Jones <[email-masked]>
Date: Mon, 14 Sep 2015 06:53:11 +0000

Replies inline below marked "Mike>", based on improvements incorporated in -02...

-----Original Message-----
From: Mike Jones
Sent: Monday, August 10, 2015 9:23 AM
To: 'Jim Schaad'; [email-masked]
Cc: [email-masked]
Subject: RE: [jose] draft-jones-jose-jws-signing-input-options 00

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

> -----Original Message-----

> From: Jim Schaad [mailto:[email-masked]]

> Sent: Monday, August 10, 2015 12:12 AM

> To: Mike Jones;

> [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>

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

> > -----Original Message-----

> > From: Mike Jones [mailto:[email-masked]]

> > Sent: Sunday, August 09, 2015 9:30 PM

> > To: Jim Schaad;

> > [email-masked]<mailto:[email-masked]>

> > Cc: [email-masked]<mailto:[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.

> > -----Original Message-----

> > From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad

> > Sent: Sunday, August 02, 2015 9:02 PM

> > To: [email-masked]<mailto:[email-masked]>

> > Cc: [email-masked]<mailto:[email-masked]>

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

> > The following represents my review of the document.

> > * 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.

> 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.

> > * 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.

> 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.

> 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.

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

Mike> The "b64" Header Parameter value is now required to be the same for all signatures/MACs.

> > * 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.

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

> > 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.

> > The better text is in the new section

> 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

> > 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?

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.

Mike> Per RFC 3986, % is not URL-safe (although is it used for www-form-url-encoding of characters as %<hex><hex>).  If we allow %, it opens up a Pandora's box of a bunch of choices we need to make, as well as possibilities.  I'll send a message specifically about those choices and possibilities to the working group (but not tonight).

> 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.

Mike> The spec now says "If an application uses a content encoding when representing the payload, then it MUST specify whether the signature or MAC is performed over the content-encoded representation or over the unencoded content".

> > *  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.

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

> on JWT?

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.

Mike> There's now an updates clause for RFC 7519.

> > * 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.

> Yes - that is part of payload transmission changes.

> >                                                       Thanks again,

> >                                                       -- Mike

                                                            Thanks Jim,

                                                            -- Mike

Mike> Thanks again for the thorough reviews, Jim.  You're good at that!

                                                            -- Mike

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 14 Sep 2015 11:02:15 +0100

Hi Mike, Jim, All,

Only one comment,

> 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.
>
> Mike> Per RFC 3986, % is not URL-safe (although is it used for
> www-form-url-encoding of characters as %<hex><hex>).  If we allow %, it
> opens up a Pandora’s box of a bunch of choices we need to make, as well
> as possibilities.  I’ll send a message specifically about those choices
> and possibilities to the working group (but not tonight).
>
Sorry if I just missed the point, but IMHO processing the payload should 
be left up to the application which gets it from a JWS.
I.e,

"$.02"
"%24%2E02"

are two different representations for the purpose of signing/validating 
them. "b64" does not only help making JWS JSON payload easier to 
understand by humans (in logs or tcp traces) but is also an optimization 
(no need to base64-encode). Having to check every character in such a 
payload to make sure '.' is percent-encoded kind makes this optimization 
much less effective, IMHO. Besides, JWS JSON are not meant to be URI 
safe payloads, I recall reading about it.
May be it is more useful for detached payloads...

Thanks, Sergey

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Sep 2015 12:47:28 -0700

Yes I think you have missed the point of the discussion.  The question was
dealing with the possibility of doing a content transfer encoding using %##
in order to make unsafe content safe.  The value to be signed was not going
to change.  This is the same as looking at "$.02" and "\u0024.02" where both
are legal JSON encodings of the same string and the internal representation
is going to be the same even if the string in the file is different.

Jim

> From: Sergey Beryozkin [mailto:[email-masked]]
> Sent: Monday, September 14, 2015 3:02 AM
> To: Mike Jones <[email-masked]>; Jim Schaad
> <[email-masked]>; draft-jones-jose-jws-signing-input-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [jose] draft-jones-jose-jws-signing-input-options 00
> 
> Hi Mike, Jim, All,
> 
> Only one comment,
> 
> > "%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.
> >
> > www-form-url-encoding of characters as %<hex><hex>).  If we allow %,
> > it opens up a Pandora's box of a bunch of choices we need to make, as
> > well as possibilities.  I'll send a message specifically about those
> > choices and possibilities to the working group (but not tonight).
> >
be left
> up to the application which gets it from a JWS.
> I.e,
> 
> "$.02"
> "%24%2E02"
> 
them.
> "b64" does not only help making JWS JSON payload easier to understand by
> humans (in logs or tcp traces) but is also an optimization (no need to
base64-
> encode). Having to check every character in such a payload to make sure
'.' is
> percent-encoded kind makes this optimization much less effective, IMHO.
> Besides, JWS JSON are not meant to be URI safe payloads, I recall reading
about
> it.