Jumping into this… hopefully I’m up to speed enough to not say something dumb….
The pkE starts out on the sender side represented in the internal data structure that the crypto library likes. It has to be because it is input the the DH function. This is neither a COSE_Key nor the byte string serialized format that is the output of SerializePublicKey(). It might be an MbedTLS key handle or whatever OpenSSL uses. The library-format key has to be converted to the byte string serialized format for SerializePublicKey() by the sender as that is needed as input to make the kem_context as part of implementing Encap(). It then has to be put on the wire to be sent and there are two choices: 1) COSE_Key — This requires some code to take the pkE in library format and output it COSE_Key format. This is work, but not that much because that function probably already exists in a COSE library. 2) Serialized byte string — No work here. Just output the same thing you fed into making the kem_context. So serialized byte string wins on the sending side. What about the receiving side? 1) COSE_Key — You have to decode the COSE_Key format and turn it into the structure the crypto library uses. Probably you have a function to do it so not too much work, but it is something. 2) Serialized byte string — This needs a deserialize function to take the bytes off the wire and turn it into the structure for the crypto library. Looks like it is needed nowhere else in RFC 9180, but you probably still have it around because it is not uncommon to do this and the format is standard for a key type. Looks like a draw on the receiving side. That kind of means serialized byte string wins overall from this particular line of thinking, but I don’t think it’s a large victory. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
