Reviewer: Elwyn Davies 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ace-oscore-profile-17 Reviewer: Elwyn Davies Review Date: 2021-03-23 IETF LC End Date: 2020-07-20 IESG Telechat date: 2021-03-25 Summary: Ready with nits. A very great improvement on the previously reviewed version. Thanks. Major issues: None Minor issues: Would it be useful to provide some advice on the length of salts and IDs to go with the advice on length of nonces? There is some in s3.3 of RFC 8613 but some other reference might be helpful, maybe placed in s3.2.1. and/or s4. Nits/editorial comments: General: The RFC Editor conforms rigorously to American practice and allows only the use of double quote marks (") in the text when marking strings as quotations and such like. The document makes extensive but not totally consistent, use of single quotes to flag up field names and such like (e.g., 'nonce1'). In practice these are unnecessary, but may be replaced by the RFC Editor if left in place. Personally. I think most of them can be removed. NB this does not affect CBOR items such as h'1645. General: There are lots of usages of 'CBOR diagnostic notation without the tag and value abbreviations'. An abbreviation would reduce the verbiage. General: It is slightly confusing to have Nonce 1/N1/nonce1 and Nonce 2/N2/nonce2 used in the document. Am I right in thinking Nonce 1 and N1 are the same with nonce1 being the name of the JSON/CBOR parameter used to carry the value? A few words of clarrification would help. Abstract/s1: It would be useful to introduce the name of the profile (coap_oscore) up front. It rather sneaks out in s3. s1, para 2: Need to expand CBOR on first use. s2, end of para 3: s/as well/instead/? or s/as well/alternatively/. s2, para 7 and s6, bullet 2: s/e.g. expiration./for example, expiration./ s3.1, para 3 and last para: s/reported/shown/ s3.1, Figure 2 and Figure 3: Appendix F.3 of draft-ietf-ace-oauth-authz reports that req_aud was replaced by audence at version 19 of the document. s3.2, second set of bullets: Need to expand HMAC and HKDF on first use (not well-known in RFC Editor list). It would also be useful to put a pointer to section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms. s3.2, 2nd para after 2nd set of bullets: s/The applications needs/The application needs/ s3.2, 3rd para after 2nd set of bullets: s/parameeter/parameter/ s3.2, 4th para after 2nd set of bullets: s/the use of CBOR web token/the use of a CBOR web token/ s3.2.1: OLD: IANA "OSCORE Security Context Parameters" registry (Section 9.4), defined for extensibility, and is specified below. NEW: IANA "OSCORE Security Context Parameters" registry (Section 9.4), defined for extensibility, and the initial set of parameters defined in this document is specified below. END s3.2.1, below Figure 9: Expand CDDL. s4.1, para 1 and s4.2, para 2: s/RECOMMENDS to use/RECOMMENDS using/ s4.1, para 1 and s4.2. para 2: s/as nonce's value/as the nonce's value/ s4.1, para 7: s/renew/update/ [renew implies the same identifiers are used - which is already specified!] s4.1, last para and s4.3, last para: Does /authz-info have some special meaning? s4.3, para 1: s/ Once receiving the 2.01 (Created) response from the RS/ Once the 2.01 (Created) response is received from the RS/ s4.3, Figure 12: I assume the Master Salt is supposed to be a CBOR indefinite length string encoding (it doesn't say so) as it it consists of the concatenated CBOR strings of its component byte strings. It would be strictly correct to start it with 0x5f and end with (0x)ff I would have thought. Be that as it may, I do not understand why the document is concerned with either CBOR or JSON/base64 encodings of the master salt. It may be that I am missing something, but I didn't think that the master salt was ever put in a protocol message as such (deliberately), but only as one or two of its components such that it could be privately constructed at both endpoints once the three components had been shared, and was just the concatenation of the data bytes of the 3 components rather than involving their lengths. s6. last para: s/observation/observations/ s7, para 3: s/RS pass/RS passes/ s9: It is now usual to give the URLs for the various existing registries as normative references. s9.4: I am not aware that a single registry can have different review/specfication requirements for portions of its parameter space. Is it seriously expected that there will be significant numbers of requests for values in this registry? My instinct would be to go for specification required and advise allocation according to the orign and type of the specification. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
