On Thu, Sep 22, 2022 at 05:09:19PM +0000, Mike Jones wrote:
> As discussed at IETF 114, the HPKE draft uses the COSE_Key public key
> representation. The authors described that Ilari Liusvaara had
> proposed using a different public key representation, which is
> detailed in Slide 2 of
> https://datatracker.ietf.org/meeting/114/materials/slides-114-cose-cose-hpke-00.
> As recorded in the
> minutes<https://datatracker.ietf.org/doc/minutes-114-cose/>,
> consensus during the meeting appeared to be in favor of continuing
> to use COSE_Key.
>
> This note initiates a consensus call by the chairs on the topic of
> what public key format the COSE HPKE specification will use.
> Working group members are requested to express their preferences
> within two weeks of this note (by Thursday, September 6th) for
> either:
>
> 1. Continuing to use COSE_Key
> 2. Using the different format proposed by Ilari Liusvaara
> 3. Other (please describe in sufficient detail to enable its
> specification)
Does the term "public key" refer to only long-term public keys, or
to both long-term public keys and encapsulated keys? The two are
very different.
For long-term public keys, I have not seen anybody propose anything
that is not COSE_Key with some (possibly new) kty.
For encapsulated keys, there is no guarantee any nontrivial mapping to
COSE_Key is possible. For example, Kyber has no such mapping. And the
slide shows the long-term public key format, which is not suitable for
encapsulated key. My test program gets around this problem by abusing
Symmetic for constructing trivial mapping (which is guaranteed to
exist).
Here is list of some of the issues with the encoding my test
program uses:
- Two encapsulated key formats.
- Abuse of Symmetric kty for encapsulated key.
- Requires mapping tables between COSE and HPKE codepoints.
- Nees review COSE codepoints each time HPKE adds something.
What I think should be done:
- Get stuff from draft-harkins-cfrg-dnhpke-02, section 4.1. added to
the IANA registry, or failing that, add equivalent stuff to the
COSE-HPKE specification.
+ This is to get NIST curves without wasting space or having
multiple key formats.
- Define new kty HPKE, with following parameters:
kem: The ID of KEM this key is for. uint. Mandatory.
kdf: The ID of KDF to use with this key. uint. Manatory.
pub: The raw public key. bstr. Mandatory.
priv: The raw private key. bstr. Mandatory for private keys,
prohibited for public keys.
aead: AEAD ID hint. uint. Optional.
- Alg is HPKE. There is only a single alg to avoid having to map
codepoints.
- Form the ciphertext as aead_id || encapsulated_key || hpke_ciphertext,
where aead_id is 2 byte big-endian AEAD id.
+ The ephemeral key field is not used.
+ The receiver knows how long encapsulated_key is, so this does not
neeed to be injective (e.g., 56 bytes when decrypting to X448 key).
+ HPKE key derivation includes aead_id, so the field does not need to
be protected. But this would not be sound for kdf!
+ This makes the algorithm look like content encryption / key wrap,
instead of some weird new algorithm type.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
