Some JOSE context from a JOSE implementer > Does anything like this happen in JOSE-HPKE?
No, in JOSE we only put in the next layer encryption algorithm identifier (with few additional fixed bytes, well below whatever limit) as there was/is no benefit in stuffing the entire JOSE protected header in. > Going further, [Section 8.1 of RFC 9180] says ... Somewhat discussed in https://mailarchive.ietf.org/arch/msg/hpke/fnGREXJ50IdG3tnQAbMCQ-XXnyM/ the concern raised in JOSE was that an underlying HPKE API implementation might not expose a way to use "aad" in its Single-Shot API, but since that's just a wrapper around Setup() and Seal() I don't believe it to be an issue for JOSE implementers. In JOSE we reference draft-ietf-hpke-hpke, not RFC9180, and we also don't have the following statement in the introduction. > This document defines the use of HPKE with COSE ([RFC9052], [RFC9053]) with the single-shot APIs defined in Section 6 of [RFC9180]. We don't reference Single-Shot APIs at all. > The 64 byte recommendation The revised HPKE spec does not have such limits, it in fact says that the usable space is effectively limitless and instead says that it may be useful for some implementations to impose a lower limit on the values they will accept and if so that such limit be no less than the maximum Nsk of an implementation-supported KEM but does not make that a recommendation. https://www.ietf.org/archive/id/draft-ietf-hpke-hpke-02.html#section-7.2.1-5 S pozdravem, *Filip Skokan* On Wed, 18 Feb 2026 at 15:53, Laurence Lundblade <[email protected]> wrote: > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
