On Mon, Jan 30, 2023 at 05:54:30AM +0900, AJITOMI Daisuke wrote:
> Hi folks,
>
> Last weekend I submitted an Internet-Draft entitled "COSE Key and JSON Web
> Key Representation for Key Encapsulation Mechanism (KEM) of Hybrid Public
> Key Encryption (HPKE)".
>
> https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/
>
> The COSE-HPKE under discussion defines the information including an
> encapsulated key sent from the sender to the recipient (HPKE sender
> information), but on the other hand, the sender needs to know the recipient
> public key and HPKE key configuration information (KDFs/AEADs supported by
> the recipient, etc.) beforehand.
>
> I thought this information (HPKE recipient information, so to speak) was
> worth expressing in COSE_Key and JWK and I wrote this draft.
>
> Maybe it's controversial, but this draft defines (1) a common key parameter
> for defining the HPKE key configuration information in existing key types
> that can be used for key derivation ("EC" and "OKP") and (2) a generic key
> type for HPKE that can also be used to represent post-quantum KEMs to be
> defined in the future.
>
> I would very much appreciate your comments.
Some comments:
- HPKE is not standardized (and AFAIK, IRTF is not allowed to
standardize anything). It is informational RFC, intended to be used
as a building block.
- For EC2 or OKP keys, there is possibility that there are multiple
valid KEM values. For example, due to future compact curves (EC2
only) or SHA-3 support. The first seems very likely, the second seems
unlikely.
For HPKE-KEM, supporting multiple KEMs would be very annoying, so
one can restrict to a single KEM.
- If compact NIST stuff gets added to HPKE, there is no longer guarantee
there is unique KEM for EC2 keys, as the keys could be used
- I don't think one can specify default value for alg outside definition
of kty itself, as key parameters can not be critical.
After all, if one feeds key with hkc but not alg to an old COSE
implementation (that does not support HPKE), it will probably happily
use the existing ECDH-ES mechanism (that the recipient may or may not
be able to handle).
- I think the hkc stuff should be inlined for HPKE-KEM keys, as kem
(which is always a single value) is now very important as it subtypes
the key (all the existing kty's which have subtypes always have the
subtype at top level).
- The JOSE stuff seems premature. I don't think there is any serious
proposal on how to integrate HPKE, and the COSE-HPKE stuff does not
port over, due to compact representation working differently and the
alg/enc split (plus probably some more details).
- The PSK and AUTH modes seem premature:
* Auth modes require rather different usage from non-auth modes
to avoid significant attacks. This would likely even show up in
sender structures.
* I don't think anyone what a worked out proposal for adding PSK modes
to COSE. I only went so far as to observe it would need a new header
parameter.
- Section 4.2. "Key Type for COSE_Key" seems to have copypasted from
the corresponding JOSE text without chagning base64url to bstr.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
