I don’t think this is about what RFC 9052 requires or doesn’t require. I think this about making sure COSE-HPKE is properly secure. I think we want to be sure COSE-HPKE addresses all the stuff in NIST SP800-56A because it is a reputable publication and because COSE, JOSE and others consider it.
Even if RFC 9052 was clear here (which I don’t think it is), we should do the analysis to be sure COSE-HPKE is secure. That’s our job. To that end I’ve tried to see how all the items in COSE_KDF_Context apply to COSE-HPKE. I think those are the arguments that matter. LL On Jun 6, 2023, at 7:21 AM, AJITOMI Daisuke <[email protected]<mailto:[email protected]>> wrote: > Given that there's no need to use it, it's not required by the core spec, and > there's the issue, as Ilari has repeatedly pointed out, of not being able to > input a meaningful value into SuppPubInfo.keyDataLength, For multiple recipient COSE-HPKE, it IS It is possible to put a meaningful value in for both COSE_KDF_Context. AlgorithmID and COSE_KDF_Context.SuppPubInfo.keyDataLength. The key point is, "Given that there's no need to use it, it's not required by the core spec.". Where is the necessity to redundantly reiterate the functionalities supported by HPKE, using the complicated COSE_KDF_Context? Honestly, while implementing COSE-HPKE, I felt it was a significant advantage that we could get by without using COSE_KDF_Context. In COSE-HPKE, I believe we can conclude that it is unnecessary to use COSE_KDF_Context and that the 'info' parameter for HPKE does not need to be supplied from outside and should always be an empty string (""). Best, Daisuke 2023年6月6日(火) 2:07 lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>>: > On Jun 4, 2023, at 12:12 AM, AJITOMI Daisuke > <[email protected]<mailto:[email protected]>> wrote: > > Hi Laurence, Ilari, > > > My proposal is to fully replace the Enc_structure with COSE_KDF_Context in > > COSE-HPKE. I am not proposing double protection. > > ... > > Given that there's no need to use it, it's not required by the core spec, and > there's the issue, as Ilari has repeatedly pointed out, of not being able to > input a meaningful value into SuppPubInfo.keyDataLength, For multiple recipient COSE-HPKE, it IS It is possible to put a meaningful value in for both COSE_KDF_Context. AlgorithmID and COSE_KDF_Context.SuppPubInfo.keyDataLength. Single recipient COSE-HPKE is kind of a degenerate case for this. It doesn’t need these values because it is all handled internally, so we can just put none/0. Ironically, it is the COSE standard COSE_Recipient alg -29 in RFC 9053 that has the problem mixing in the content encryption algorithm because AES Key Wrap is not an AEAD and in the way. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
