On Fri, Jun 30, 2023 at 01:52:26PM -0500, Orie Steele wrote: > Inline: > > > On Fri, Jun 30, 2023 at 1:32 PM lgl island-resort.com <[email protected]> > wrote: > > I am not exactly sure what you are talking about here, but: > > https://www.iana.org/assignments/cose/cose.xhtml > ES256K -47 ECDSA using secp256k1 curve and SHA-256 secp256k1 is a curve, > ECDSA is an algorithm and SHA-256 is a hash function. > > https://www.iana.org/assignments/jose/jose.xhtml > ES256K ECDSA using secp256k1 curve and SHA-256 alg > TLDR, JOSE and COSE treat `alg` the same way for digital signatures.
That is only for ES256K (fixed curve in both COSE and JOSE). ES256/ES384/ES512 are different (fixed curve in JOSE, but not in COSE). > > I also would say that there is no kind of vector, tuple, array or map in > > COSE or JOSE that is akin to “hkc”. There is nothing in to COSE or JOSE > > that does the kind of disaggregation in “hkc”. COSE-HPKE had to invent a > > new structure for it. > > > > > I don't really follow what you are saying, closest examples to HPKE in JOSE > and COSE are: <snip long list> Currently, in COSE, one can freely mix the following: - AES-128/192/256 key wrap (and it is not clear if also Chacha20). - SHA-256/SHA-512 KDF. - P-256/P-384/P-521/X25519/X448/Bitcoin_curve key exchange. Which excluding PQC is easily comparable to capabilities of HPKE. > There are things that are registered for COSE that are not registered for > JOSE as well... not relevant to this thread. I agree those are not relevant, but for different reason: JOSE-HPKE will work very differently from COSE-HPKE (in my sketches, it works like ECDH-ES). > Intentionally designing something to destroy JWK / COSE Key vs JWE / > COSE Encrypt interop... seems like it will raise objections. Will? I think it already has. (Using alg will absolutely destroy that interop.) > I suggest starting with a P-256 Key, and considering the case that it is > restricted for HPKE, what minimal changes to the existing registries > support it. I don't think there would be any point to doing that. COSE already has those cryptographic capabilites. > Also consider the API the developer will want: > > "I want to use this algorithm (-25)... generate a key for it".... P-256, P-384, P-521, X25519, X448 or Bitcoin curve? > "serialize the key with my restricted preferences"... etc.... Those are not your call. > https://github.com/panva/jose/blob/main/docs/functions/key_generate_key_pair.generateKeyPair.md > https://github.com/panva/jose/blob/main/docs/interfaces/key_generate_key_pair.GenerateKeyPairOptions.md > > ^ good example of a nice usable API for generating keys for use with > algorithms. What happens if developer specifies one of those six-way overloaded algs without specifying crv? -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
