> I don’t think this is about what RFC 9052 requires or doesn’t require.
Of course, this is under the assumption that COSE_KDF_Info is not necessary because its role is being fulfilled by HPKE. However, as you mentioned, there is a need for detailed explanations or evidence presentation. I've confirmed it before like Ilari, but I will also reconfirm this on my end. Best, Daisuke 2023年6月8日(木) 0:55 lgl island-resort.com <[email protected]>: > 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]> 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 <[email protected]>: > >> >> > On Jun 4, 2023, at 12:12 AM, AJITOMI Daisuke <[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
