On Mon, Jul 20, 2026 at 11:13:42AM -0400, Brian Sipos wrote: > > Following on to an earlier thread, I have done some experimentation with > patching the pycose package to enable draft HPKE algorithms [1]. Some > experiences are good and some not so much. > > That existing library implementation takes a strict reading of HPKE RFC > 9180 [3], which allows use only of the KDF "info" input and not any access > to the AEAD "aad" input. This restriction is quoted below and causes any > implementation that follows its guidance to be incompatible with the > current COSE HPKE draft. > > Applications that only use the single-shot APIs described in Section 6 > should use the Setup info parameter for specifying auxiliary authenticated > information. 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.
Note that RFC9180bis removes the text about not allowing both. > I understand that this is the choice of the library author to adhere to > non-normative guidance of RFC 9180, but presumably that guidance was > written for a reason and HPKE implementations already exist with > corresponding limitations. One huge benefit that I see of using HPKE > algorithms in COSE is to take advantage of libraries where possible. As far as I can tell, there is no reason. The fields are for distinct purposes, and both can end up being used. > How do the authors feel about removing use of the HPKE "aad" input and use > only the "info" input? I don't think it would change the > fundamental behavior of binding to that COSE Enc_structure or > Recipient_structure context. Note that RFC9180 has very small info size limit that is too small. RFC9180bis has larger one, but info is still not meant to hold aad (aad should not be used on layer >0). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
