Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-jwt-bcp-04

[Yaron Sheffer <[e-mail]>]

Hi Brian,

Thank you for your review!

Your comments are addressed by the following commit: 
https://github.com/yaronf/I-D/commit/d00674b352f6e1323da8c5b6600f1f0d7e9b64b1

Please let us know if any issues remain.

Best,
	Yaron

On 30/03/2019 23:51, Brian Carpenter via Datatracker wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-oauth-jwt-bcp-04
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-oauth-jwt-bcp-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-03-31
> IETF LC End Date: 2019-04-08
> IESG Telechat date:
> 
> Summary: Ready with (minor) issues
> --------
> 
> Minor issues:
> -------------
> 
>> 2.3.  Multiplicity of JSON encodings
>>
>>    Previous versions of the JSON format [RFC8259] allowed several
>>    different character encodings: UTF-8, UTF-16 and UTF-32.  This is not
>>    the case anymore, with the latest standard only allowing UTF-8.
>>    However older implementations may result in the JWT being
>>    misinterpreted by its recipient.
> 
> Why is that a security issue?
> 
>> 3.6.  Avoid Length-Dependent Encryption Inputs
> ...
>>   ...It is
>>   RECOMMENDED to avoid any compression of data before encryption since
>>   such compression often reveals information about the plaintext.
> 
> I'd like a citation for that, because it isn't intuitive. (And compression
> after encryption is pointless, of course.)
> 
>> 3.10.  Do Not Trust Received Claims
> 
> Both the recommendations in this section seem imprecise. Maybe there
> should be some hints about the verification processes.
>