On Mon, May 01, 2023 at 09:33:26AM -0700, Laurence Lundblade wrote: > - I don’t think there should be a new kty for HPKE. There’s probably > some HPKE-KEM ID and COSE_Key curve mapping, but I don’t think that > requires a new kty.
What my implementation does if it can not otherwise encode the key is to add 1212481536 to the HPKE kem ID to obtain crv to use with OKP. And similarly if it sees OKP key with crv in range 1212481536 to 1212547071 (inclusive) it subtracts 1212481536 from the crv id to get the HPKE kem id. This happens regardless of if the code actually writes out that crv in any case (e.g. crv 1212481568 and 1212481569, which stand for X25519 and X448). As concrete example, suppose HPKE library (it can be dynamically linked!) is updated to support KEM 0x0030, then: - Requesting generating key of type "TYPE30" will write out public and private keys with crv 1212481584. - Encrypting to OKP public key with crv 1212481584 will write KEM 0x0030 into sender info. - If kid matches, the code will attempt to decrypt message with sender info containing KEM 0x0030 with OKP private key with crv 1212481584. And this happens even if the COSE-HPKE library is not updated. Hacky, yes. Maybe too hacky. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
