Re: [jose] Shepherd comments

[Mike Jones <[e-mail]>]

Thanks again for your comments, Jim.  These are addressed in draft -04.  Replies follow inline...

-----Original Message-----
From: jose [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Saturday, October 24, 2015 2:19 PM
To: [e-mail]
Cc: [e-mail]
Subject: [jose] Shepherd comments

> I needed to review the document with a fine tooth comb for the shepherd report and came up with the following issues.

> 1. If you are going to define ASCII and UT8 in section 1.1, you should probably define BASE64URL since you are using them in the same manner.

Done

> 2.  Is it possible to use a UTF-16 string in section 3 for b64=false?  This does not seem to be explicitly rule out.  It would not be an issue for b64 encoded versions of the payload.

The UTF-8 encoding is specified in Section 5.3.

> 2.  Should have a flattened version of the structure in section 4.1 as well for comparison purposes.

Done

> 3.  In section 5.3 I find the sentence about performing escape processing slightly confusing.  It is not clear what operations are being applied in which direction.   Additionally, there appears to be a requirement that UTF-8 encoding be applied which is not reflected in Section 3.

The section now specifies that the escape processing is JSON string escape processing.

The JSON Serialization uses UTF-8, per Section 5.3.  The Compact Serialization, being restricted to ASCII characters, uses the ASCII encoding (which is equivalent to UTF-8 for these inputs), per Section 5.2.

> 4.  Please remove the double-quote marker for JWS JSON Serialization in section 7.  This is not and never has been a problem (as noted by the fact that there is no restriction about double-quotes in this document).  The first delimiter is a problem and should be note.  Leaving in the whitespace issues is reasonable as it could get messed up, although it should not, for the JSON encoding.

Base64url encoding the double-quote character when it appears in JWS JSON Serialization payloads does prevent it from being confused with the double-quote string delimiter.  That's the point of the remark.

> 5.  You still need to respond to the last pair of emails from myself and James about the 'crit' parameter  usage.  I think that some text will be require for this.  I note that he and I both described the same situation where this makes a difference.  This may be a requirement on crit or just a security consideration that needs to be discussed.

I replied to these earlier and added text to the security considerations about this.

> 6.  Curiosity.  If an application sends some messages detached an some in a URL safe form, would you consider that to be a case where an application could use b64 based on context for some messages but not others?

Yes.  The draft now talks about "it being consistently applied in each application context".

> Jim

				Thanks,
				-- Mike