On Wed, Feb 18, 2026 at 07:52:33AM -0700, Laurence Lundblade 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.
Yeah, I think that structure should be passed as aad. The reason it is accpetable to use aad is that authentication failure stops the recipient processing. And in fact, if using info, it is that same authentication failure that stops message processing! Basically, I think info should be for application/context separation and aad should be for layer-level authenticated data. However, that would run into problems with HPKE recommendations. > 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. As note, there is at least one HPKE implementation that does not do static nor dynamic allocations for info. :-) > Switching to “aad” seems better to me. It has no limits. It’s a simple > switch. Nitpick, there are limits, but those are too large to matter in practice. I suppose the real practical limit would be allocating buffer for the aad, as HPKE implementation likely requires that. > Does anything like this happen in JOSE-HPKE? Well, there is SuppPrivInfo for Key Encryption, but using that is a Bad Idea. > 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. Nor the speed difference — aad is processed faster than info. > I don’t know why it says both should not be used, but it’s only a > lowercase “should”. Apparently the logic is that both end up geting bound, but info causes things to diverge earlier, so it is preferable — which is not actually quite correct. Unfortunately, some implementations apparently interpret that in whacky ways. There are cases where I think both should be used. Basically anything that involves layer-level authenticated data, like JOSE HPKE integrated encryption or COSE-HPKE. > 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). IMO, NIST SP800-56A is way overcomplicated for the stated security reasons. E.g., the PartyU/PartyV stuff instead of doing a spaceship on public keys to break the static-DH symmetry. That spec gives a lot of rope to hang yourself interop-wise. > 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. And seems like aad vs. info is part in why there are two versions of every COSE-HPKE algorithm. I think it is much preferable to make stuff always do the right thing, instead of having to check if it is used in the correct context or not. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
