On Mon, Oct 31, 2022 at 11:30:13AM +0000, Hannes Tschofenig wrote: > 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.
Alternative rules (which are a bit simpler) could be: - If the COSE-HPKE implementation is able to guess a single KEM, based on the private key and length of ek, it MAY ignore KEM field and use the guessed KEM. - If the COSE-HPKE implementation has multiple candidates for the KEM, based on the private key and length of ek, it MUST require KEM field to be present, and contain one of the candidates, which it will use. The second case is very much edge case. It is currently impossible to hit it, and no KEM I can foresee being added[1] to HPKE enables the second case to be hit. If the KEM field is mandatory, then implementations must check it against the private key. [1] List of stuff (in no practicular order): - Some new national elliptic curve (Brainpool? Whatever the chinese one is called?). - Compact NIST curves. - Kyber1024 (Being part of CNSA 2.0) - Various Kyber/ECDH hybrids. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
