On Mon, May 02, 2022 at 10:38:44AM +0000, Hannes Tschofenig wrote: > > Having said that COSE allows two ways to encode keys of type "EC2", as > you also mention in your email below and as I just posted to the list > as well, and they work for NIST curves (P-256r1, P-384r1, P-521r1).
My use of EC2 is solely for point compression. > You bring up X25519 and X448 KEMs, which use the key type "OKP" > (Octet Key Pair). Using OKP requires the crv parameter since somewhere > you have to indicate what type of key it is. Note that cose_key structures are used in two places: 1) Public/private keys: These need specifying the KEM, which fixes the key type. 2) Encapsulated keys: - If uncompressed, these never need specifying the key type, as fixing the private key will fix the key type. This is why I abused kty=symmetric for these (can't just stuff raw bstr because that would violate RFC8152). - If compressed, fixing private key would still fix the key type. However, I think for implementation reasons it is better to have an explicit key type to indicate what compression has been used. > Regarding future KEMs: draft-harkins-cfrg-dnhpke-01 is still an > individual draft and it remains to be seen whether it will get > standardized. It makes me wonder whether it is unavoidable to have > new KEMs to go through some standardization also in the COSE WG to > decide how they are best encoded (if they do not fit into an existing > pattern). We can hardly anticipate every new HPKE KEM people will > propose. I prefer to standardize those HPKE KEMs first where we know > how they look like and where they will be implemented. If Dan cares > about the COSE usage, he may register his new KEMs for COSE HPKE > usage as well. Well, I expect virtually all future KEMs to fit into an existing pattern: - Some uncompressed elliptic curve thingy (a'la NIST curve KEMs). - Some compactified ball of mud (a'la X25519 and X448). ... Mostly the latter. Any other KEM would likely be too exciting (in a bad way) or not very suited for COSE (e.g., RSA). > If you think we should create a new key type then we should take a > look at it. We will have to encode the same information in this new > structure and you seem to have an idea how you would want this new > key structure to look like. If KEM and KDF are coupled, the resulting keyshape is already OKP (or EC2 if you want to compress the public key), so new kty would make little sense to me. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
