On Sun, Apr 23, 2023 at 05:19:38PM +0900, AJITOMI Daisuke wrote:
> 
> Therefore, I believe the description regarding "hkc" would be as follows.
> 
> - When a recipient provides senders with its public keys for HPKE KEM in
> the form of JWK or COSE_Key, the recipient can declare the supported HPKE
> ciphersuites using hkc. If the recipient does not support all of the KEMs,
> KDFs, or AEADs which can be used with the key, the recipient
> SHOULD indicate the supported ciphersuites using "hkc".
> - If the recipient's public keys are provided in JWK or COSE_Key format,
> the senders of HPKE SHOULD check whether the "hkc" parameter is included in
> them, and if so, SHOULD select a specific ciphersuite to be used from the
> "hkc" value.
> 
> The "alg" value is not mentioned above. This is because "hkc" is an
> auxiliary parameter independent of the "alg" value.


I believe that it would furthermore be that (this does not contradict
what is above):

- If kty is HPKE-KEM, then senders MAY assume that the KEM of key is
  supported, regardless of if it appears in the "hkc" KEM list or not.

- Senders SHOULD use the same KDF as the internal KDF used in KEM.

- If using COSE-HPKE two-layer structure, senders SHOULD check if the
  key has "cbc" (COSE Bulk Ciphers) parameter (value is array of
  integers and text strings), and if yes, SHOULD use it to select the
  cipher used on layer 0.

- In JWK, any integer elements in "cbc" parameter SHOULD be encoded
  using only digits and minus sign. Note that these values might
  exceed interoperable JSON integer range (currently no registered
  algorithm comes even close).

- In JWK: "use" value "HPKE" indicates that the key is intended for
  use with HPKE.



There is a subtle point regarding the second item on KDF selection:

If the KEM existed first without matching KDF, but the matching KDF
was later added, implementations might support the KEM, but not the
matching KDF.

This might happen in the future with MLWE-KEM-1024 (or whatever the
thing from CNSA 2.0 will be: Its internal KDF is 256-level SHAKE,
but HPKE does not currently have any 256-level SHA-3 KEMs. However,
that is No Earlier Than 2024.




-Ilari

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to