Hi Joel, Thanks for quick feedback, inline. On 2018-02-23 14:59, "Joel M. Halpern" <jmh@xxxxxxxxxxxxxxx> wrote: >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. Since the AEAD is used throughout the draft, in particular in other parts of this section I’m thinking that maybe we should add RFC 5116 to the list of specifications following "Readers are expected to be familiar with” in Section 1.1. Would that address your comment? Thanks Göran > >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" <jmh@xxxxxxxxxxxxxxx> 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 >>
