Hey Laurence,
Thanks for the quick review. I am pretty much fine with your suggestions and I created a few PRs for you to look at, see https://github.com/cose-wg/HPKE/pulls. A few remarks below From: COSE <[email protected]> On Behalf Of Laurence Lundblade Sent: Dienstag, 14. März 2023 20:31 To: cose <[email protected]> Subject: [COSE] Comments on draft-ietf-cose-hpke-04 -04 is a good improvement. Thank you. The kid parameter is always optional in COSE. It shouldn’t be mandatory in 3.1.1 and 3.1.2. I think this is a mandatory change for this draft. Section 5.2 of 9052 even discourages use of kid in and Encrypt0: The COSE_Encrypt0 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used. Key identification is something that COSE leaves up to the layers above as far as I can see. It should probably have been mentioned as one of the things a COSE profile should specify in section 10 of RFC 9052. I have found this a bit odd, particularly compared to CMS, but I can see the value in leaving it open. [Hannes] I can make the kid parameter optional. IMHO the advice in RFC 9052 regarding the kid is a bit strange. I don’t understand why there is no value in using some parameter, like the kid, to give the recipient a idea what they it should be using to decrypt the message. Of course, if it is available from the context then that’s fine but that this may not always be the case. Of course, having this discussion about RFC 9052 is not so useful and we have to look forward. If a profile needs the kid (or some other parameter) then they have to use it. I’d like for “HPKE” to be in the name of the structure since it is HPKE specific — perhaps “HPKE_sender_info”. [Hannes] Works for me. I think it’s better to say “plaintext” rather than “detached plaintext” in section 5. The plaintext is an input to COSE which may then turn into an inline cipher text or a detached cipher text. The plaintext is the same in both cases so there’s not really any such things as “detached plaintext”. [Hannes] Fine for me. Section 4.3 is clear now and well-aligned with what I was thinking it should be. A few suggestions: Say “again as required RFC 9052” rather than "again intentionally aligned with COSE by re-using the Enc_structure” in 4.3.1. [Hannes] I changed the sentence but I cannot claim that RFC 9052 required it since the text talks about the HPKE functions. Say “The external_aad in the Enc_structrue contains the Externally Supplied Data described in 4.3 and 5.3 in RFC 9052” rather than "The external_aad field in the Enc_structure is populated with the API caller provided AAD information”. There are several occurrences. [Hannes] I am fine with this change as well. While it is not wrong, the distinct descriptions in 4.3.1 and 4.3.3 are a little confusing. The AAD input to SealBase in 4.3.1 is exactly the same as the AAD input to the AEAD in 4.3.3. Why not say “An Enc_structure is create per RFC 9052 section 5.3. For Encrypt0 it is passed to SealBase. For Encrypt it is passed to the AEAD”. [Hannes] I need to think about how to improve the text. I also made related comments in the “COSE-HPKE: AAD and Info” thread. [Hannes] Will have a look. I will comment on the info parameter to SealBase separately. [Hannes] Thanks again for the review. Ciao Hannes LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
