Hi Ilari I am not sure why you bring up the alignment with JOSE. Also, nobody suggested supporting modes beyond base since this would raise further challenges with COSE because COSE supports those already.
If we omit the kem parameter from the structure then we need to define the precise processing rules, which so far nobody has done Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Monday, November 7, 2022 4:51 PM To: [email protected] Subject: Re: [COSE] COSE HPKE 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
