Inline:
On Fri, Jun 30, 2023 at 1:32 PM lgl island-resort.com <[email protected]> wrote: > Still trying to keep this to objective facts and not express any opinion > of mine. > > > > On Jun 30, 2023, at 10:53 AM, Ilari Liusvaara <[email protected]> > wrote: > > > > On Fri, Jun 30, 2023 at 05:29:32PM +0000, lgl island-resort.com wrote: > >> > >> > >> On Jun 29, 2023, at 1:41 PM, Ilari Liusvaara <[email protected] > <mailto:[email protected]>> wrote: > >> > >> On Thu, Jun 29, 2023 at 04:00:09PM +0000, Jeremy O'Donoghue wrote: > >> > >> COSE_Sign1 and COSE_Sign+COSE_Recipient > >> Single integer — The integer specifies the hash, signing algorithm and > >> the curve > > > > It does not specify the curve (it does in JOSE, but not in COSE). > > Yes, you are right about that. My mistake. > > Also, I wrote the title wrong. It should be COSE_SIgn1 and > COSE_Sign+COSE_Signature. > 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. > > >> COSE_Encrypt+COSE_Recipient or COSE_Mac+COSE_Recpient > >> This is the one of interest. It has at least two algorithm identifiers: > >> > >> * The COSE_Encrypt bulk content encryption algorithm, typically > AES-GCM > >> * The COSE_Recipient algorithm > >> > >> In the case of ECDH, the curve comes from the key, not from the > algorithm ID, so for RFC 9053 6.3 and 6.4 encryption there are 3 > identifiers: > >> > >> * COSE_Encrypt bulk alg, e.g. AES-GCM > >> * COSE_Recipient alg, e,g, ECDH-ES + A128KW > >> * Curve which comes from the key, e.g. NIST P-256 > >> > >> There is also the case of nested COSE_Recipients, in which case there > is an algorithm identifier per nesting level. > > > > Yes, one can also do ECDH as follows: > > > > * COSE_Encrypt bulk alg, e.g. AES-GCM > > * COSE_Recipient alg, e,g, A128KW > > * ECDH alg, e.g., ECDH-ES + SHA256 > > * Curve which comes from the key, e.g. NIST P-256 > > > > 3 algs, plus key subtype... > > Yes, that is described in Appendix B of RFC 9052, but ECDH-ES + A128KW > (-29) is a short-cut for it. There’s no point in using that particular > 3-layer structure. > > > > Then COSE is not limited to 3 layers, even if nobody has yet invented > > use for that yet. > > > > > >> COSE_Key > >> A single algorithm identifier from the same space used by > >> COSE_Sign1…COSE_Recipient plus a curve identifier for EC keys. > > > > The alg there is optional. Not a good idea with symmetric algorithms, > > but asymmetric algorithms are much less troublesome without alg in key. > > > > > >> While a COSE_Encrypt may have more than one algorithm identifier, that > >> algorithm identifier is never a tuple, vector, array or map like > >> “hkc". It is alway a single integer (or string). > > > > The point is that there is no single ciphersuite, but the information is > > disaggregated. > > Let’s call it partially disaggregated. There is aggregation of (pub key > alg + HKDF + Keywrap) in ECDH-ES + A128KW (-29), and that aggregation > doesn’t include the bulk content encryption algorithm or the curve. > > There is aggregation within major COSE structures and messages, but > disaggregation when multiple COSE structures and messages are combined. > Plus COSE disaggregates the curve. > > 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: https://www.iana.org/assignments/jose/jose.xhtml ECDH-ES ECDH-ES using Concat KDF alg Recommended+ [IESG <https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section 4.6 <https://www.iana.org/go/rfc7518>] n/a ECDH-ES+A128KW ECDH-ES using Concat KDF and "A128KW" wrapping alg Recommended [IESG <https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section 4.6 <https://www.iana.org/go/rfc7518>] n/a ECDH-ES+A192KW ECDH-ES using Concat KDF and "A192KW" wrapping alg Optional [ IESG <https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section 4.6 <https://www.iana.org/go/rfc7518>] n/a ECDH-ES+A256KW ECDH-ES using Concat KDF and "A256KW" wrapping alg https://www.iana.org/assignments/cose/cose.xhtml ECDH-SS + A256KW -34 ECDH SS w/ Concat KDF and AES Key Wrap w/ 256-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-SS + A192KW -33 ECDH SS w/ Concat KDF and AES Key Wrap w/ 192-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-SS + A128KW -32 ECDH SS w/ Concat KDF and AES Key Wrap w/ 128-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-ES + A256KW -31 ECDH ES w/ Concat KDF and AES Key Wrap w/ 256-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-ES + A192KW -30 ECDH ES w/ Concat KDF and AES Key Wrap w/ 192-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-ES + A128KW -29 ECDH ES w/ Concat KDF and AES Key Wrap w/ 128-bit key [kty] [RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-SS + HKDF-512 -28 ECDH SS w/ HKDF - generate key directly [kty] [ RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-SS + HKDF-256 -27 ECDH SS w/ HKDF - generate key directly [kty] [ RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-ES + HKDF-512 -26 ECDH ES w/ HKDF - generate key directly [kty] [ RFC9053 <https://www.iana.org/go/rfc9053>] Yes ECDH-ES + HKDF-256 -25 ECDH ES w/ HKDF - generate key directly [kty] [ RFC9053 <https://www.iana.org/go/rfc9053>] YesYou can see that they are intentionally aligned so you can upgrade from JOSE to COSE for cases when ECDH ES w/ Concat KDF is used. There are things that are registered for COSE that are not registered for JOSE as well... not relevant to this thread. Intentionally designing something to destroy JWK / COSE Key vs JWE / COSE Encrypt interop... seems like it will raise objections. 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. Also consider the API the developer will want: "I want to use this algorithm (-25)... generate a key for it".... "serialize the key with my restricted preferences"... etc.... 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. OS LL > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
