> 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
I have some experience with this part in JOSE, in the cases where the sender and receiver must agree to a key type and algorithm, I prefer that these be explicit, and I don't like inferring one party's key structures from another party and assumptions about the cryptography... I've seen problems where one party represents keys differently... for example, EC with and without point compression... or 1 party has keys that need to be converted to a standard format before a software library can be used. I prefer to dump the key representations straight into off the shelf software, which expects standard key formats, and will often complain if parameters are missing (such as kty, crv, alg). For example: https://github.com/panva/jose/blob/main/docs/classes/jwe_compact_encrypt.CompactEncrypt.md#readme Takes a public key, which you get from: https://github.com/panva/jose/blob/main/docs/functions/key_import.importJWK.md#readme This example is not exactly the same for HPKE, but I think developers will be assuming that these APIs will be similar. Ajitomi, in your code I don't see anything like "importJWK"... can you comment further on the data type of "rkp.publicKey" in this code block: ``` const rkp = await suite.generateKeyPair(); const sender = await suite.createSenderContext({ recipientPublicKey: rkp.publicKey, }); ``` Your library looks awesome, thank you for sharing! Regards, OS On Thu, Sep 1, 2022 at 9:01 AM AJITOMI Daisuke <[email protected]> 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. > > 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. > > 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. > > Regards, > Ajitomi, Daisuke > > 2022年8月30日(火) 23:11 Ilari Liusvaara <[email protected]>: > >> On Mon, Aug 29, 2022 at 11:47:27AM +0000, Hannes Tschofenig wrote: >> > Hi Ilari >> > >> > The participants of the IETF#114 meeting expressed an opinion about >> > the approach of how to encode the public key in a COSE message, namely >> > to re-use the structures already defined. Those map nicely to what is >> > being defined for HPKE in terms of algorithms as well. >> >> Well, turns out x25519 and x448 do not quite map nicely to present >> structures: The encapsulated key is octet string, but putting it to eph >> requires some extra junk. At best this wastes space. At worst it causes >> security issues. >> >> Assuming redefining eph to allow bstr is not acceptable (compare >> allowing kid to be int), solving this would require a new header that >> can take bstr and cose_key. E.g., "ek" (encapsulated key). Which would >> also be used by native KEM modes. >> >> Such header would be useful for backport to JOSE, since there >> presumably will not be JOSE-HPKE, so PQC requires native KEM modes >> for JOSE. >> >> >> For long-term keys, one could specify that HPKE keys MUST be OKP unless >> specified otherwise. This would allow reusing existing x25519 and x448 >> key structures without causing a long-term mess. >> >> >> > For PQC algorithms the work on these encodings is still ongoing and I >> > am sure they will be re-usable as well. >> >> Well, judging from what I have seen about PQC (signature) work on >> COSE/JOSE, I do not think the codepoints will be reusable. >> >> And then there might be some non-PQC additions, like compact NIST >> curves. Those things would obsolete the current NIST curves in >> COSE-HPKE. There are no encodings to reuse for these. >> >> >> > In terms of implementation effort, the biggest work is on implementing >> > the PQC algorithm and the integration of it into HPKE not in the >> > integration with COSE (where we are talking about a few lines of code >> > only anyway). >> >> That is true only if the algorithm is not special in any way. >> >> If there is anything special in the way the algorithm is mapped to >> COSE, the complexity leaps up greatly: Specification is entiere >> document instead registry entry. And implementation will be way more >> than a few lines (one line in my test implementation). E.g., in >> hundreds of lines range with NIST curves. >> >> >> >> -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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
