On Tue, Oct 25, 2022 at 10:40:36AM +0000, Hannes Tschofenig wrote: > 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
Pretty much. I noticed that text about what parameter the sender structure goes to seems to be missing. Some expert on CDDL might take a look at how that "any bstr / array / dictionary" is written. > Regarding the changes to the COSE_HPKE_Sender structure you are > making three changes: > * Make the structure non-extensible, I do not think the structure can be usefully extended. That is, if implementation supporting only baseline COSE-HPKE runs into any unknown parameter, the decryption attempt is doomed, as the message uses HPKE in some unknown mode, and base mode decryption will not work. > * Change the order of the field (kem is now the last field), and Actually, change it from dictionary (unordered) to array (ordered). And since kem is the only optional field, I think it was easier to make it '? kem: uint' (which must be at the end) than 'kem: undefined / uint'. > * 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.) -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
