On Mon, Sep 08, 2025 at 10:06:34AM -0700, Laurence Lundblade wrote: > Focusing on ECDH-ES + A128KW, algorithm ID -29, section 6.4.1 of > RFC 8949. > > Any fix to -29 for non-AEAD algorithms will NOT be compatible with > existing implementations. Adding the layer defined in > draft-tschofenig-cose-cek-hkdf-sha256 > will require a large change to any implementation of -29.
My understanding is that it is not a layer, but a transform on the key used on a layer. And it is only supported on layers with symmetric input keys, which does not include -29. And yes, using it will not be compatible with existing implementations. I do not think it is a large change, but I would need to try to modify my COSE-HPKE prototype implementation (the encryption side does support any other-type recipient). > So what we should do instead is define ECDH-ES + A128KWbis, with a new > algorithm ID like -129, that authenticates the algorithm ID properly. > The solution would look a lot like what we did for COSE-HPKE. While it would be possible to hack algorithm ID authentication to composed KAwKW, it would not work with algorithms that do not have any capability for authenticated data, like Authenticated Encryption or Key Transport. CMS faces analogous problem, which is why the CMS fix is done the way it is. > I would also like to replace Context Information Structure like we did > for COSE-HPKE. Note that COSE does support ECDH-SS, which needs more complex Context Information Structure, in order to break the symmetry and to inject entropy. Breaking the symmety could be done with a one-byte key spaceship field (is the sender key less, equal or greater than reciver key in some total order), and injecting entropy with a bstr field. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
