Re: [jose] AD review of draft-ietf-jose-jws-signing-input-options

Thanks for your comments, Kathleen.  Replies are inline below...

> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Monday, November 23, 2015 11:06 AM
> To: jose@ietf.org
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

				Thanks again,
				-- Mike