Thanks for your comments, Kathleen. Replies are inline below... > -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Kathleen Moriarty > Sent: Monday, November 23, 2015 11:06 AM > To: [email protected] > Subject: [jose] AD review of draft-ietf-jose-jws-signing-input-options > > Dear Mike & JOSE WG, > > Thanks for your work on this draft! I just have a few nits and am hoping you > can turn this around quickly so I can kick off IETF last call.
-06 has been published, which addresses these review comments. > Abstract: > The last sentence should state what is prohibited since it does not add a lot > of text rather than saying 'this option". > > How about: > > "This specification updates RFC 7519 by prohibiting the use of the > base64url-encode option in JSON Web Tokens (JWTs)." Replaced "this option" with "the unencoded payload option". > Section 7, Security considerations. > > The first sentence is really hard to parse as written: > > "[JWS] base64url-encodes the JWS Payload to restrict the character set > used to represent it to characters that are distinct from the > delimiters that separate it from other JWS fields." > > I'm not sure what you mean by representing something 'to characters' > either. Maybe you meant something slightly different than what's there? I rewrote this sentence. > Second paragraph, first sentence: > This is a run-on, please fix it: > "One potential problem that applications using this extension may need > to address is that if a JWS is created using "b64" with a "false" > value and is received by an implementation not supporting the "b64" > Header Parameter, then the signature or MAC will still verify > correctly but the recipient will believe that the JWS Payload value > is the base64url decoding of the payload value received, rather than > the payload value received itself." I rewrote this one as well. > The next sentence needs a comma: > Change from: > > For example, if the payload value > received is "NDA1" an implementation not supporting this extension > will think that the intended payload is the base64url decoding of > this value, which is "405". > > To: > > For example, if the payload value > received is "NDA1", an implementation not supporting this extension > will think that the intended payload is the base64url decoding of > this value, which is "405". Done > IDnits: > Can you check the 2119 language? IDnits is showing an error, so maybe > something is slightly off: > > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > The other errors that show up are all fine from my check. I think that's because it said "this specification" rather than "this document". I've changed it back. > Examples: I see Jim's note that the examples have been validated by a non- > author implementation. SHould there be an ack for this person's work? Great point! Vladimir's contribution is now acknowledged (as is yours). > Thanks! > > -- > > Best regards, > Kathleen > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose Thanks again, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
