Hi all, I have read the draft again and think that it is largely ready.
Please find below some minor comments. Best, /Marco ========== [Abstract] Given the first paragraph, isn't the last sentence of the abstract redundant and possible to remove? [Section 3.1] * It says: > The mode is 'mode_psk' if the 'psk_id' header parameter is present; otherwise, the mode defaults to 'mode_base'. Suggested rephrasing: > The mode is 'mode_psk' if the 'psk_id' header parameter registered in Section 7.2 and specified in Section 3.1.1 is present; ... Later in Section 3.1.1, it says: > If 'mode_psk' has been selected, then the 'psk_id' parameter MUST be present. If 'mode_base' has been chosen, then the 'psk_id' parameter MUST NOT be present. I suggest to use "header parameter" (2 instances), consistently with above. Also, it would be good to define the parameter semantics already here, instead of only much later in Section 7.2 when requesting for the IANA registration. [Section 3.1.1] * It says: > This mode applies if the COSE_Encrypt0 structure uses a COSE-HPKE algorithm and has no recipient structure(s). I think you mean: > This mode relies on a COSE_Encrypt0 structure (see Section 5.2 of RFC 9052) that uses a COSE-HPKE algorithm. Note that the COSE_Encrypt0 structure has no recipient structure(s). * It says: > ..., this documents RECOMMENDS the use of the 'kid' parameter (or other parameters) to ... "RECOMMENDS" is not a BCP14 word. Proposed rephrasing: > ..., it is RECOMMENDED to use the 'kid' parameter (or other parameters) to ... * s/raw into the 'ek'/raw into the layer 'ek' (for consistency with the later "layer 'ek' parameter") (same comment for Section 3.1.2.2) [Section 3.1.2] * It says: > This mode is selected if the COSE_recipient structure uses a COSE-HPKE algorithm. I think you mean: > This mode relies on a COSE_Encrypt structure (see Section 5.1 of RFC 9052), within which each COSE_recipient structure uses a COSE-HPKE algorithm. * It says: > As stated above, the specification uses a CEK to encrypt the content at layer 0. Maybe this sentence can be removed? [Section 3.1.2.1] * It says: > It MUST be used for COSE-HPKE recipients ... I think you mean: > It MUST be used for encrypting COSE_recipient structures corresponding to COSE-HPKE recipients ... * It says: > This value MUST match the alg parameter in the next lower COSE layer. In case the alg parameter is present in the next lower COSE layer at all, right? (See the first paragraph in Section 3.1.2.2) * It says: > ... COSE_recipient CBOR-encoded deterministically with ... Proposed rephrasing: > ... COSE_recipient as deterministically CBOR-encoded with ... * It says: > Since it is not a header, it may be secret data that is not transmitted. I think you mean: > Since it is not a header, it is not transmitted and thus it can safely include data that may be secret. * It says: > It provides a means to convey many of the fields in COSE_KDF_Context. I think you mean: > It provides a means to convey many of the fields that are otherwise conveyed within COSE_KDF_Context. [Section 3.1.2.2] * There are 2 occurrences of: > raw key for the next layer down. In COSE-HPKE, isn't that "next layer down" specifically layer 0? * It says: > should be protected at layer 0 with external_aad. Should "should" be a normative SHOULD instead? It's better to clarify that the mentioned external_aad is the field in the Enc_structure used to perform the encryption/decryption at the "next layer down". [Section 3.2] * It says: > ..., this means the value of "crv" parameter is suitable. I guess you mean: > ..., then the value of the "crv" parameter MUST be suitable too. [Section 4] * s/'psk_id' parameter/'psk_id' header parameter [Section 5.2.1] * It says: > TODO: recompute this for Recipient_structure Is that a remnant? * The caption of Figure 4 should be updated to reflect the use of COSE_Sign1 as a wrapper. [Section 6] * It says: > Additionally, with the two layer structure the CEK ... I think you mean: > Additionally, when using the two layer structure, the CEK ... [Nits] * Section 3.1 --- s/, which authenticates using/and authenticates using * Section 3.1.1 --- s/contents/content (2 instances) * Section 3.1.1.1 --- s/by RFC 9052/by [RFC9052] (as a hyperlink) * Section 3.1.2.1 --- s/COSE encrypt/COSE_Encrypt * Section 3.1.2.2 --- s/contents/content (2 instances) --- s/strcture/structure --- s/in the COSE_recipient/in the COSE_recipient structure * Section 3.2 --- s/"kty" and "crv"/"kty", and "crv" * Section 4 --- s/some extend/some extent --- s/standardized it might/standardized, it might --- s/with HPKE, the KDF/with HPKE. The KDF --- s/consitute/constitute * Section 5 --- s/that shows all/that show all --- s/COSE_Encrypt and COSE_MAC/COSE_Encrypt, and COSE_MAC * Section 5.2 --- s/In this example we assume/In this example, we assume --- s/it will be/it would be * Section 5.2.1 --- s/detatched/detached * Section 5.3 --- s/key representation are/key representations are * Section 6 --- s/assumes the sender/assumes that the sender --- s/HPKE COSE/COSE-HPKE --- s/generations/generation --- s/ciphertext then/ciphertext, then Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se ________________________________ From: Michael Jones <[email protected]> Sent: Wednesday, June 4, 2025 10:28 PM To: [email protected] <[email protected]> Subject: [COSE] WGLC for draft-ietf-cose-hpke-13 This note starts a two-week Working Group Last Call (WGLC) for the Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) specification https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html. The WGLC will run for two weeks, ending on Friday, June 20, 2025. Please review and send any comments or feedback to the COSE working group at [email protected]<mailto:[email protected]>. Even if your feedback is “this is ready for publication”, please let us know. Note that this WGLC is intentionally running concurrently with a JOSE WGLC for https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-08.html because the drafts are closely related and their functionality is intended to be aligned. Please reply to the JOSE WGLC on the [email protected]<mailto:[email protected]> mailing list. Thank you, -- Mike and Ivaylo, COSE Chairs
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
