Hi Mike, Thanks for the quick turn-around. I'll put the draft into IETF last call to get that started.
On Tue, Nov 24, 2015 at 6:35 PM, Mike Jones <[email protected]> wrote: > 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 updated text is better, but it is still a little long. I won't hold it up on this though. Thanks! Kathleen > >> 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 > -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
