Hi Ilari Thanks for the quick response.
Regarding the first item, is this what you are looking for: https://github.com/cose-wg/HPKE/pull/10/files Regarding the changes to the COSE_HPKE_Sender structure you are making three changes: * Make the structure non-extensible, * Change the order of the field (kem is now the last field), and * you introduce rules for processing that are dependent upon the presence/absence of the kem field. You are asking the developer to determine whether "the KEM is consistent with the private key". I fear that this rule is too loose to understand. We will have to specify what "consistent" means i.e. what checks a developer is supposed to make. This also changes the text that is currently in the draft, which says that the kem is optional one the value of this field is inferred already by the key identifier. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Monday, October 24, 2022 3:49 PM To: [email protected] Subject: Re: [COSE] COSE HPKE On Mon, Oct 24, 2022 at 10:16:24AM +0000, Hannes Tschofenig wrote: > Hi all, > > I have updated the PR containing the alternative proposal discussed in > https://mailarchive.ietf.org/arch/msg/cose/oI_cRYbxTEo2Uwn7aXQV0dCmYtA > / > > Here is the PR: > https://github.com/cose-wg/HPKE/pull/9 Some small tweaks (for future extensibility and simplification): - Instead of registering hpke_sender to Common Header Parameters, register encapsulated_key: Name: encapsulated key Label: TBD2 (Assumed: -4) Value type: bstr / [*any] / {* any => any } Value registry: N/A Description: Encapsulated key for KEM-like algorithms For algorithm HPKE, encapsulated key MUST be present in unprotected bucket and its value SHALL be of type COSE_HPKE_Sender. Rationale: This parameter would be reusable for dedicated Kyber algorithm, or any other future KEM-like things. This does not alter what goes on the wire in any way, just what registeries say about the values. The weird value type is meant to say: Any bstr, array or dictionary as appropriate for the algorithm. E.g., I expect Kyber to put a bstr here. And of course, HPKE uses COSE_HPKE_Sender here. - COSE_HPKE_Sender could be simplified to: COSE_HPKE_Sender = [ kdf: uint, aead: uint, enc: bstr, ? kem: uint ]; If kem field is present, the recipient MUST verify that the indicated KEM is consistent with the private key and the length of enc, and then use that KEM in decryption attempt. Otherwise the recipient MUST fail decryption. If kem field is absent, the recipient MUST verify that there is only a single KEM consistent with the private key and the length of enc, and then use that KEM in decryption attempt. Otherwise the recipient MUST fail decryption. In case there is only a single supported KEM consistent with the private key and the length of enc, then this could be implemented by first computing the sole candidate and then verifying the kem field is either absent or contains the guessed value. In case there is none, an implementation can immediately fail, as decryption is not possible. Rationale: This structure is not safely extensible and there are 3 mandatory parameters and one optional one. No current recipient is able to deal with any extensions, so future extensions can be accomodiated by having "hpke2" that uses COSE_HPKE_Sender_v2 structure. The kem field is only needed in the unlikely case that the recipient can not guess the KEM based on the private key and length of enc. Note that even if compact NIST curves get added and recipient operates on generic long-term EC2 keys, the length of enc still allows correctly guessing the KEM (e.g., for P-256 key, 32 byte enc means it is CP-256, 65 byte enc means it is is KEM 16). -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
