Hi Ilari, Hi Daisuke,
The main decision for the group is whether there is willingness to define new
public key formats in addition to those already defined. A factor in the
decision making might be whether the existing format is insufficient.
It turns out that neither COSE nor HPKE define new cryptographic algorithms.
They just use them, including their encoding. Section 13.1 of RFC 8152 (COSE)
defines the public key encoding of elliptic curve keys and references Section
2.2 of RFC 5480, which points to Section 2.3.3
"Elliptic-Curve-Point-to-Octet-String Conversion" in [SEC1]. Section 7.1.1 of
RFC 9180 (HPKE) references the uncompressed
Elliptic-Curve-Point-to-Octet-String in [SEC1], which is in Section 2.3.3. This
means that COSE and HPKE use the same encoding for the public key (of the NIST
curves).
Hence, all we are talking about here is carrying the information in slightly
different ways. Let's take the P256r1, for example:
Your proposed public key format for NIST P256r1 where you dump the key into the
-2 (x) field.
{
/ kty => OKP /
1: 1,
/ kid /
2: h'1F677209D1C5174C',
/ crv => -65537 (HPKE P256 with SHA256) /
-1: -65537,
/ X-Y coordinates /
-2: h'040E271193..69'
}
The existing format specified by COSE places the public key is separated into
two fields, x and y. COSE also defines a compressed and an uncompressed
encoding of the public key (which we discussed at the list).
(FWIW HPKE references the uncompressed format.)
Here is the uncompressed format:
{
/ kty => EC2 /
1:2,
/ kid /
2: h'1F677209D1C5174C',
/ crv => P-256 /
-1:1,
/ x => x-coordinate /
-2:h'0072...85e5c8f42ad',
/ y => y-coordinate /
-3:h'01dc...fe1ea1d9475',
}
Here is the compressed format:
{
/ kty => EC2 /
1:2,
/ kid /
2: h'1F677209D1C5174C',
/ crv => P-256 /
-1:1,
/ x => x-coordinate /
-2:h'0072...85e5c8f42ad',
/ y => y-coordinate (sign-bit) /
-3:true,
}
So, this raises the question where the optimization potential is? While the
inefficiency was raised in discussions, I believe that this is not really the
design goal here (as I will point out in my other email to Daisuke).
Ciao
Hannes
[SEC1] https://secg.org/sec1-v2.pdf
-----Original Message-----
From: COSE <[email protected]> On Behalf Of Ilari Liusvaara
Sent: Thursday, September 1, 2022 7:02 PM
To: [email protected]
Subject: Re: [COSE] Next steps with COSE-HPKE .... was RE: HPKE: Ephemeral
public key encoding
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
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
