How about this (see the last and third to last edit): https://github.com/core-wg/oscoap/commit/8f277d83 where the reference is made to COSE instead of AEAD? Best Göran On 2018-02-23 15:32, "Joel Halpern Direct" <jmh.direct@xxxxxxxxxxxxxxx> wrote: >I guess it is up to you. Personally, I like the idea of the verify >description including some reference to how one actually does verify. >I will leave it to the authors and WG to decide what degree of clarity >is called for here. > >Yours, >Joel > >On 2/23/18 9:30 AM, Göran Selander wrote: >> 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 >>>> >>
