On Fri, Sep 02, 2022 at 08:21:29PM +0900, AJITOMI Daisuke wrote: > > There is a video recording of the session on IETF youtube channel. > > IIRC, it discussed the NIST curve case, but not the CFRG curves. > > Thanks. I've watched it. > I agree with your views in this thread, but your proposal presented in IETF > 114 was not the solution I envisioned. > > Anyway, in the IETF114 meeting, there were several erroneous comments that > the fact that enc is an octet string is implementation-dependent. > The fact that the output of KEM is an octet string of the raw key is > specified by the HPKE specification and is an obvious misunderstanding. > > > 1) Define a new parameter that allows bstr. > > Drawback: New parameter. > > 2) Redefine eph to allow bstr. > > Drawback: Comparable to allowing int in kid, which was controversial. > > 3) Abuse symmetric kty. > > Drawback: Wastes 3 bytes. > > There seems to be no other option but 1). > > 2) has a backward compat issue, and 3) the abuse seems beyond > acceptable.
As to how bad backward compat issue 2) is depends on what implementations actually do when seeing a bad recipient. Do they reject just the recipient (good) or do they reject the entiere message (bad)? There is some requirement in COSE that certain kind of bad recipient MUST NOT cause message to be rejected. But no general requirement to skip any bad recipient. > > As what my test implementation of COSE-HPKE currently does: > > ... > > Why should we be forced to use kty, crv or alg? > I know your implementation is experimental, but it seems to abuse > "kty" and "alg" too. For long term keys, the cleanest way is to use the COSE_KEY structure, which is generic key container for COSE. In this structure, "kty" is REQUIRED. There are two values of kty that make sense: One can either use existing OKP type, or define new HPKE type. My implementation choses to use the existing OKP type. The OKP type has subtype confusingly called "crv". My implementation uses this field to encode (via lookup table) the KEM and KDF to use in HPKE. The reason for tying the KEM and KDF together is that the KEMs internally use KDF, and that KDF should be similar to the KDF HPKE itself uses. E.g., X448 (KEM #33) internally uses SHA-512, so the KDF should be based on SHA-512 (KDF #3). For the encapsulated key, the sole reason "kty" exists for the non- compressed case is that "eph" requires COSE_KEY, which in turn requires "kty". And the implementation did not And the COSE encrypted messages use certain kind of structure, where "alg" is REQUIRED. My implementation uses this field to encode (via lookup table) the AEAD to use in HPKE. And as for what I am not happy with: - The special cases for compressed NIST curves due to not having compact NIST curves. - Not being able to do direct-bstr encoding of the encapsulated key. > Sorry for repeating, the information to be passed from the sender to > the recipient is (i) this "enc" as an octet string, (ii) the kid, > which identifies the recipient's public key, (iii) the kdf id and aead > id selected by the sender(if the recipient provided multiple choices), > totaling 4 bytes, and (iv) the version information of this E2E > encryption application. > > What are your thoughts on this? As to how my implementation signals those: (i) As eph parameter, with some extra junk. (ii) as kid parameter. (iii) kdf via crv of long-term key, aead via alg in recipient. (iv) The thing is not versioned. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
