Re: [core] Genart last call review of draft-ietf-core-object-security-08

["Joel M. Halpern" <[e-mail]>]

In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE 
object using the Recipient Key as per RFC 5116 Section 2.2" that would 
fill in the confusion for this reader.

Yours,
Joel

On 2/23/18 5:26 AM, Göran Selander wrote:
> Hi Joel,
> 
> Thanks for your review. Comments inline.
> 
> 
> On 2018-02-22 04:51, "Joel Halpern" <[e-mail]> wrote:
> 
>> Reviewer: Joel Halpern
>> Review result: Ready with Nits
>>
>> 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
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-core-object-security-08
>> Reviewer: Joel Halpern
>> Review Date: 2018-02-21
>> IETF LC End Date: 2018-03-02
>> IESG Telechat date: 2018-03-08
>>
>> Summary: This document is ready for publication as a Proposed Standard RFC
>>
>> Major issues: N/A
>>
>> Minor issues:
>>     In section 8.2 on verifying the request, step 5 says to "compose" the
>>     Additional Authentication Data.  I would have expected it to be
>> "verify"
>>     the Additional Authentication Data.  I could imagine that the
>> verification
>>     consists of composing what it should be, and then comparing with what
>> is
>>     received.  But I do not see the comparison step.  is it implicit in
>> some
>>     other step?  This occurs again in 8.4, so I presume I am simply
>> missing
>>     something.  This may suggest some clarification could be useful.
> 
> The AAD is indeed “composed" both on encrypting and decrypting side from
> data which needs to be known to the endpoint at the time when the AEAD
> operation is performed. The authenticated decryption process is described
> in:
> 
> https://tools.ietf.org/html/rfc5116#section-2.2
> 
> So the verification consists of feeding the input, including the AAD, to
> the authenticated decryption which calculates the plain text or FAIL, and
> a failure may be - but is not necessarily - caused by wrong AAD.
> 
> The AD review also indicated that we should move the reference to RFC 5116
> to an early section in the draft and that change is already included in
> the latest version on the CoRE WG Github.
> 
> 
> Best regards
> Göran
>