Ilari, Thank you, I now better understand the relationship to RFC 9180. It might be helpful to give an aside somewhere (intro section?) to explain that the mechanism of this document is not compatible with strict minimal RFC 9180 implementations and requires the API of the bis document.
I will continue to track this with Py cryptography library authors for eventual compatibility with the 9180bis spec. Do you have a feeling on the stability of the current version of that draft? Thanks, Brian S. On Mon, Jul 20, 2026 at 1:51 PM Ilari Liusvaara <[email protected]> wrote: > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
