Hi Ilari, I updated the PR based on your feedback.
I still have a few question regarding the processing rules. I wonder whether this procedure introduces fragility just for a very small byte saving (namely saving the kem id value). It also makes the implementations more difficult since multiple cases have to be considered. ~snip~ > * 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. This processing is already needed, it is just left unspecified. And my wording was apparently very poor. The question is, what does your implementation do if it receives: a) A message with no KEM, but there are multiple KEMs that all can be used with the private key and have Nenc = |enc|. I think it is reasonable to fail to decrypt. b) A message with no KEM, there are multiple KEMs that all can be used with the private key, but only one has Nenc = |enc|. I think it is reasonable to attempt decryption with the one KEM. (checking for Nenc = |enc| is needed in case both compact and uncompressed curves are supported with the same private key.) c) A message with KEM that can not be used with the private key. I think it is reasonable to fail to decrypt. (If the KEM can be used with private key, but Nenc != |enc|, then HPKE will fail anyway.) Ciao Hannes 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
