> 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 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. 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. Sorry for repeating but I think the information that should be passed from the sender to the recipient are (i) the "enc" (encapsulated key) 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 for the recipient's public key), totaling 4 bytes, and (iv) the version information of this E2E encryption application based on HPKE. What are your thoughts on this? Regards, Daisuke 2022年9月2日(金) 2:02 Ilari Liusvaara <[email protected]>: > On Thu, Sep 01, 2022 at 11:00:56PM +0900, AJITOMI Daisuke wrote: > > Hi Hannes and Ilari > > > > As an implementor of HPKE library (https://github.com/dajiaji/hpke-js), > let > > me offer my opinion. > > > > I strongly agree with Ilari's opinion. > > > > I don't know what kind of discussions were held in IETF114, HPKE spec > > (RFC9180) defines that a sender's ephemeral key (enc : encapsulated key) > > output by KEM is an octet string. > > I see no point in converting to the existing public key structure (JWK > for > > COSE), which would rather lead to more complex specifications and > > implementations, and cause security issues. > > There is a video recording of the session on IETF youtube channel. > IIRC, it discussed the NIST curve case, but not the CFRG curves. > > As for concerns about extending OKP to non-curves, OKP was meant for > that from the very begninning and the specification specifically says > that it does (albeit not in the clearest way). > > > For uncompressed NIST curves, such re-encoding would save some space, > which can be surprisingly valuable. > > For P-256, it allows compressing 65 bytes to 43. > For P-384, it allows compressing 97 bytes to 59. > For P-256, it allows compressing 133 bytes to 77. > > Adding compact NIST curves to HPKE would make this obsolete, as keys > are even smaller than the compressed ones given above. I think the > COSE-HPKE spec should register the codepoints, unless someone else > gets there first (there has been at least one I-D proposing exactly > that, but it seems to have gotten stuck in some process hole). > > > > Of course, existing key structures could be used to represent the > > recipient's public key. > > However, the sender's ephemeral key depends on the recipient's public key > > information, and there is no need to specify the many parameters such as > > kty, crv, alg, etc. which is already determined by the recipient's public > > key. > > Here, one potential issue is that the eph header is defined to take > COSE_KEY and does not allow direct-bstr. There are a few options: > > 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. > > (My test implementation does the option 3.) > > > > In my opinion, the required attributes for the sender's ephemeral key > > related information are as follows: > > - kid: bstr. the recipient's public key identifier. > > - ek (or enc?): bstr. the sender's ephemeral public key. > > - kdf: int(2-byte). optional. the KDF identifier selected by the sender > if > > the recipient's public key supports more than one KDF algorithm. > > - aead: int(2-byte). optional. the AEAD identifier selected by the sender > > if the recipient's public key supports more than one AEAD algorithm. kdf > > and aead might be able to be combined into one parameter. > > - ver: int (2-byte). optional?. the version of the HPKE application. An > > HPKE application will probably specify how to use INFO and AAD. It is > > necessary to define a version of the specification which could be > updated. > > > > Finally, I think we can learn a lot from other standards that use HPKE: > > ECH, ODoH, and OHTTP quite naturally use "enc" as it is, as an octet > string. > > As what my test implementation of COSE-HPKE currently does: > > - Public/Private keys are always OKP, with special crv values > (compressing long-term keys is not supported, since these infrequent > on constrained channels). > - The crv value also species the kdf to use (chosen to match kem as > closely as possible). > - kid is used for key filtering. Especially for COSE_Encrypt0, which > only does single attempt at decryption. > - alg is used for specifying AEAD to use, again using special values. > - The encapsulated key is put into eph field. > - This primarily abuses kty symmetric, k is the raw key. > - NIST curves can also use EC2 keys for compressed form, since > encapsulated keys are common on constrained channels. > - The crv and alg mappings are build time genrated from table. If > the underlying HPKE library supports it, adding new alg or crv > is one line addition. > - The underlying HPKE library has one major quirk: It has support > functions for that EC2 curve compression/decompression (going so > far as to use the COSE codepoints for designating the curves). > - If only single recipient is needed COSE_Encrypt0 can be used > instead of COSE_Encrypt saves few dozen bytes. > - There is 8MB message size limit when decrypting, but ciphertext > might not count. Largest message sizes I have tested exceed 20GB. > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
