Thanks again for your comments, Jim. These are addressed in draft -04. Replies follow inline...
-----Original Message----- From: jose [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Saturday, October 24, 2015 2:19 PM To: [email protected] Cc: [email protected] 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
