>
> > 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
