On Tue, Nov 01, 2022 at 02:20:50PM +0200, Ilari Liusvaara wrote:
Some more thoughts on COSE-HPKE design space:
1) Trying to align COSE and JOSE seems like a lost cause. The two
seem too different in how things are represented (it goes far
beyond just needing some base64url encodings).
2) HPKE has four modes: base, psk, auth and authpsk. Presently
COSE-HPKE only supports base. If more is to be supported, I think
all modes should be their own alg's, since the modes are mutually
incompatible.
Regarding any more modes defined in the future or future HPKE
versions, I don't think it is good idea to even speculate what
those would be like.
3) The auth/authpsk modes (if those are to be supported) require
knowing sender public key to decrypt. COSE already has existing
static key / static key id parameters that could be used (since
the types are suitable).
4) The psk/authpsk modes (if those are to be supported) require
knowing PSK identifier to decrypt. Possible places for carrying
that would be:
- A new parameter
- Extended version of the HPKE context structure.
For the latter to be possible, either:
- The parameter must allow many types (and then use
COSE_HPKE_Sender_Psk instead when using psk modes).
- The COSE_HPKE_Sender has to be extensible.
5) Implementation complexity implications of multitype parameter or
extensible structure:
- Multitype parameters cause issues for implementations that first
decode all parameters they know and then look at alg. I do not
know how common such implementations are, compared to
implementations that first look at alg and then decode the needed
parameters (for which multitype is no extra complexity).
- Making sender structure to be dictionary makes it more complex to
decode versus array structure, since implementation has to look up
the required keys (and handle those being missing!) instead of
just doing array indexing (after having ensured that array is big
enough).
And the way HPKE is designed, it seems like everything in the
sender structure has to be understood for succesful decryption.
6) Most of the time, the KEM parameter is worse than useless, as the
receiver knows that there is only one KEM that could possibly work.
All the KEM parameter could do is contradict that, and then the only
possible choices are to ignore the KEM parameter or fail immediately.
With HPKE adding more KEMs there could be situations where multiple
KEMs could work. However, I am not able to foresee any KEMs that
would need this (CP-* or Kyber variants certainly do not), so this is
probably not worth supporting.
So probably one would not need the KEM parameter in the sender
structure at all.
7) If COSE is to add KEMs (e.g., Post-Quantum) of its own outside
COSE-HPKE, either:
- One needs a new parameter to carry the encapsulated key, as both
"ephemeral key" and "HPKE sender" parameters have wrong format.
- The parameter used for HPKE sender structure has to allow mutiple
types. Most probably the encapsulated key is bstr (or pair of
bstr's for hybrid?).
It seems "encapsulated key" is a bad name for the parameter (I have
privately gotten some pushback).
8) For the current HPKE KEMs (and CP-*), it is possible to use present
COSE_Key structures for long-term keys (unless hinting kdf/aead is
needed).
KDF hinting is unlikely to be needed, since for any current kem,
there is only one kdf that makes sense.
AEAD hinting would be possible to implement by adding a new key
parameter (for both ec2 and okp, since both can carry HPKE-compatible
keys).
For things like future post-quantum KEMs, to avoid hacks, one needs
a new kty "hpke" with something like:
- kem: The KEM used (uint, mandatory).
- priv: The private key (bstr, private keys only).
- pub: The public key (bstr, mandatory).
- kdf: KDF hint (optional).
- aead: AEAD hint (optional).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
