On Mon, Jan 17, 2022 at 09:36:34AM +0000, Hannes Tschofenig wrote:
>
> with draft-ietf-cose-hpke-00 I have submitted the draft version that
> was subject to the working group call for adoption. John and Goeran
> provided feedback already and suggested to re-use the algorithm
> registry created by HPKE.
>
> In https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt
> the proposed -01 version can be found.
>
> Please have a look at it and let me know if the proposed changes
> are inline with the suggestions.
In can make little sense of the way HPKE is used.
- Why are the symmetric and asymmetric parts of HPKE split into two
different layers? The whole point of HPKE singleshot mode is to
combine them.
- The layer 1 algorithm is specified as COSE encryption algorithm,
but for actually performing the encryption/decryption, one needs
HPKE AEAD ID.
* How is the mapping between the two done?
* If new AEAD is added to HPKE, does one also have to register COSE
algorithm for it?
Embedding the registry would mean 5 byte algorithm identifiers, as
there is just not enough space with smaller ones (need continuous
block of 65534 (sic) algorithm ids).
- Recipients at layer 1 are specified as one-or-more. AFAICT, more than
one recipient here makes absolutely no sense.
- The algorithm ID at layer 2 needs new registrations to take advantage
of new HPKE algorithms. This especially inclures KEMs, which are one
of the most important extension points (post-quantum!).
- Decomposing the keys at layer 2 needs code changes to support new
KEMs. Which likely can not be nontrivially decomposed anyway.
However, currently HPKE does not have compact NIST curves, which
allows space saving via decomposition.
Compromise might be to embed the registries (both may be jointly
embededed into 5 byte algorithm identifier) and have special values
for decomposed stuff (and shorthands for X25519/X448).[1]
If both KEM and KDF can be sepcified, the KDFs SHOULD be matched.
- HPKE is different enough that I think both new kty and a new
operational mode are justified (I can make very little sense of
existing operational modes).
- Doing HPKE with two layers with cose_encrypt, easily extends to
doing HPKE in cose_encrypt0: The only difference is directly operating
on the plaintext instead operating on the CEK. The limitation is
only having one recipient.
[1]
E.g.:
- algid=-1 is like algid=0x00010010, but key is compressed like in C509.
- algid=-2 is like algid=0x00020011, but key is compressed like in C509.
- algid=-3 is like algid=0x00030012, but key is compressed like in C509.
- algid=-4 is alias for algid=0x00010020 (X25519 with SHA-256).
- algid=-5 is alias for algid=0x00030021 (X448 with SHA-512).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
