Re: [jose] [COSE] JOSE/COSE RSA Kem without HPKE?

[Ilari Liusvaara <[e-mail]>]

On Mon, Feb 12, 2024 at 04:55:26PM -0600, Orie Steele wrote:
> Inline:
> 
> On Mon, Feb 12, 2024 at 3:09 PM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Mon, Feb 12, 2024 at 12:41:52PM -0600, Orie Steele wrote:
> >
> > However, stuff like this might be more interesting:
> >
> > https://github.com/lamps-wg/draft-composite-kem/pull/11
> >
> >
> Yes, this is another reason to ask... will we see composite kems as
> standalone building blocks (like RSA Kem)
> Or will we see HPKE Suites that pair those building blocks with specific
> choices of KDF and AEAD.

Yes, composite KEMs will be standalone building blocks.

(In fact, that is prerequisite for KEM to be added to HPKE.)


> > In JWE and COSE, KEMs act similarly to ECDH-ES and have the same types
> > (Direct Key Agreement, Key Agreement with Key Wrap(ping)).
> >
> > Anything one can use ECDH-ES for, one should be able to use KEM for.
> 
> epk is already used for this case, the ES part, is what pairs with the
> "epk" part.

I was referring to where it can be used, not the precise encoding.

 
> > > Is it ok if JOSE uses "epk" and JWK, COSE uses a new header
> > > parameter instead of using "epk" and COSE Key?
> >
> > Well, I think using new header parameter is easier for implementations
> > than using a JWK (or COSE_Key). The JWK seems just pointless wrapping
> > of a byte string.
> 
> It's not pointless.
> It uses the existing code points for headers, which reduces the burden on
> applications that will have to keep processing those headers.
> The applications only need to switch on "alg", and then process the
> associated epk.... which is what they are already doing for
> "ECDH-ES" and "epk" today.

For application that switches on "alg", it much easier to just:

- Pull a new header parameter out of headers
- Base64url-decode that

Than:

- Pull "epk" parameter out of headers.
- Pull "kty" out of key
- Check the key type is correct.
- Pull "ek" out of key.
- Base64url-decode that.

And every one of those steps can also fail.

I count that there are currently 18 different algorithms for JWE. Only
4 of those use "epk". Not even all Key Agreement with Key Wrapping
algorithms do.

In COSE, it is even more lopsided, since there is no base64url.


> If we didn't have these existing application processing considerations, it
> would be easier to say adding a new header param is the correct solution in
> my opinion, but we are probably headed for testing RSAES-OAEP, ECDH-ES, and
> HPKE recipients for the same encrypted messages.... if we add
> RSA-KEM+A128KW to that mix, it's better to consider the design cost of that
> now... before the drafts become standards... I think either path will work,
> but we should force the API design to align, for the sake of developers...
> I would call it a win if JOSE and COSE handle this in a similar way, and a
> loss if they decide to handle it differently... I am not attached to the
> design using epk, but I do think it is easier for implementations that have
> to keep supporting ECDH-ES alongside HPKE and RSA Kem.

RSA-KEM+A128KW is Bad Idea.

Trying to internally handle RSAES-OAEP, ECDH-ES, HPKE and KEM in common
way will just lead to nasty abstraction rot. And abstraction rot is a
vicious kind of technical debt. So using "epk" for anything that is not
ECDH-ES will make things harder, not easier.

As for API design, the main issue are algorithms that do something that
is unexpected. There is nothing unexpected in using a new header
parameter.

In contrast, both JOSE-HPKE modes do very unexpected things. And
Integrated Encryption is something so fundamentally unexpected that it
not being aligned with HPKE as Key Encryption is not an issue for any
implementation.

It would be much smaller problem for implementators if:

- JOSE-HPKE-KE used new parameter for enc, Encrypted Key for ct.
- JOSE-HPKE-IE used Encrypted Key for enc, Ciphertext for ct.

Than if JOSE-HPKE-IE put enc in parameters, forcing multishot.

The reason for this is that even trying to use the same algorithm
dispatch for Integrated Encryption will already lead to nasty
abstraction rot.

That forces duplicate implementations of all JOSE-HPKE algorithms. And
once you have duplicate implementations, those can freely diverge.


And given how unaligned JWE and COSE_Encrypt are, why should any new
stuff even try to be aligned in any way? Especially if that would lead
to worst-of-both-worlds.




-Ilari