> Here the external_aad input needed to make the Enc_structure is the exactly the same for all three instances.
Yes, I think that's correct. The externally supplied aad is the same, but the three AAD values passed to HPKE AEAD are different. > Also, I think the info parameter to SealBase here should be “”. One thing to add here is that there is another option for the info parameter to take a fixed string like "cose" but RFC9180 Section 8.1 says "Implementations which only expose single-shot APIs should not allow applications to use both Setup info and Context aad or exporter_context auxiliary information parameters". Regardless of whether the single-shot APIs are used, COSE-HPKE creates a single HPKE context and encrypts/decrypts on it once per call, so I think it would be better for the info parameter to be an empty string. Best, AJITOMI Daisuke 2023年3月3日(金) 8:05 Laurence Lundblade <[email protected]>: > > On Mar 2, 2023, at 6:38 AM, AJITOMI Daisuke <[email protected]> wrote: > >> >> > >> *Inputs to SealBase in two-layer mode* >> I think an Enc_structure (5.3 in 9052) with context “Enc_Recipient” is >> what should be given to SealBase for the aad parameter. This is not super >> clear from 9052, but I think it is right. I’ve also been reading Jim’s code >> and I think that is what it does. (There’s a few layers and occurrences of >> AAD here — the external AAD input to COSE, the AAD input to the AEAD and >> the AAD input to SealBase — none of these are the same). >> Also, I think the info parameter to SealBase here should be “”. >> > > I agree. My implementation does the same. > > > To check one more thing here — Let’s say you have a COSE_Encrypt with two > COSE_Recipients and there is some externally supplied authenticated data > (section 4.3 in RFC 9052). Three instances of Enc_structure will be > created, one at the top level and one each for the two COSE_Recipients. > Here the external_aad input needed to make the Enc_structure is the exactly > the same for all three instances. It is the externally supplied > authenticated data. The protected headers input is different for all three. > > Once at level zero would have been enough for integrity protection. That’s > all the payload gets. But the standard is written such that externally > supplied authenticated data is covered once at level 0 and again for every > COSE_Recpient at level 1. > > This is also how Jim’s code seems to work. > > LL > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
