Currently, the COSE-HPKE Recipient_structure is passed into HPKE Seal/Open via the “info” parameter, not the “aad” parameter. However, HPKE recommends limiting the “info” parameter to 64 bytes and states that can be the max an HPKE library supports.
The Recipient_structure contains all the protected headers. If the “kid” is a protected header, as recommended, it would be limited to approximately 40 bytes, assuming no other parameters except the alg ID. Seems to me that we must either switch to the Seal/Open “aad” parameter, which is unlimited and, as I recall, Sophie Schmieg mentioned being acceptable, or add a RECOMMENDATION to maintain the small size of the COSE Recipient header parameters to ensure compatibility with the HPKE RECOMMENDATION. The 64 byte recommendation is in [Section 7.2.1 of RFC 9180]: > The RECOMMENDED limit for these values is 64 bytes. This would enable > interoperability with implementations that statically allocate memory for > these inputs to avoid memory allocations. Switching to “aad” seems better to me. It has no limits. It’s a simple switch. Does anything like this happen in JOSE-HPKE? Going further, [Section 8.1 of RFC 9180] says: > 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. COSE-HPKE is an application that uses only the single-shot API, so this paragraph applies to us. It prefers “info”, but doesn’t mention the size limitation. I don’t know why it says both should not be used, but it’s only a lowercase “should”. There’s an implication that it’s OK to use only “aad”, which conveys confidence that “info” is not needed for NIST SP800-56A security reasons (“info” is the one that goes into the HPKE KDF). Seems to me that it’s still OK for us to switch to “aad” and allow “info” if a use case has SP800-56A security concerns with HPKE. LL [Section 7.2.1 of RFC 9180]: https://www.rfc-editor.org/rfc/rfc9180.html#name-input-length-restrictions [Section 8.1 of RFC 9180]: https://www.rfc-editor.org/rfc/rfc9180.html#name-auxiliary-authenticated-app _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
