On Thu, Mar 21, 2024 at 06:54:16AM +1000, Orie Steele wrote: > This is the main thing we need to address in COSE HPKE: > > > What matters is that the algorithm ID at layer 0 is protected. It must > always be protected no matter what type of COSE or HPKE or CMS or JOSE we > are considering.
Unfortunately, currently no algorithm that takes a key (as opposed to giving a key) can protect the algorithm at next layer. And then some such algorithms can not even be easily modifed to do so (RSA-OAEP is the worst here, but even AES-KW is pretty bad). CMS went with different solution due to having this exact same issue with algorithm chaining and allowing unauthenticated encryption. JOSE takes care of this issue by strictly prohibiting unauthenticated content encryption (RFC 7516, section 4.1.2.). > >From a terminology perspective, I think "next alg" is not a great name, and > while I liked the generic depth construction from illari, it seems overkill > for HPKE, which only supply 2 layers. There can be more than 2 layers (pull-pull). That nobody has figured out any sensible use for that does not mean it is not valid. (Maybe COSE BCP could recommend against using anything except the four cases with known sensible use: direct, push, pull and pull-push). > Let me try a refinement of the previous proposals: > > HPKE_AAD = CBOR([ > "HPKE-Key-Encryption", content_encryption_algorithm, > recipient_protected_header, > external_aad > ]) > > Yes, external AAD at this layer is strange, but it enables private > information, which we lost when rejecting COSE KDF Context. That situation already arises if one composes Key Agreement with Key Wrap from some Direct Key Agrement and some AEAD algorithm (pull-push). Perfectly valid and sensible thing to do, despite no known implementation supporting it. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
