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
