On Fri, Jun 30, 2023 at 06:32:42PM +0000, lgl island-resort.com 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: > > > > 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.
What about using a stronger key? All the integrated key wraps have SHA-256 KDF, which fails to reach nominal strength of stronger key exchange (even if I can not come up with an attack). > 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. COSE-HPKE did not need to invent "hkc". COSE-HPKE itself is defined by draft-ietf-cose-hpke which does not mention "hkc". The COSE-HPKE prototype code I have written does not support "hkc" at all. "hkc" only appears in the HPKE keys draft, where the only place where it is not optional is using it for subtyping hpke keys, which I think is a very bad idea (and mixes really badly with key fingerprints draft). And "hkc" is a new kind of capability, so it is not surprising that there is nothing like that currently in COSE nor JOSE. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
