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

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 <Michael.Jones@microsoft.com> wrote:
> 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 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
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
>                                 Thanks again,
>                                 -- Mike
>

-- 

Best regards,
Kathleen