On Thu, Nov 20, 2025 at 09:35:24PM +0000, Sipos, Brian J. wrote: > WG, > > In reviewing existing symmetric keyed algorithms defined in RFC 9053, it > seems like there is an implicit constraint on input key length which is not > actually required anywhere. I'm not sure that this constraint actually > matters in practice, because I expect that using an alternate input key > value would fail verification/decryption but it seems like something that > would be a useful check for an implementation to make (rather than wasting > the time to verify / decrypt and then discover the failure). > > > > The algorithms are in Section 3.1, 3.2, 4.1, 4.2, 4.3, 6.1.1, 6.1.2, and > 6.2.1 all with the constraint: > > The "kty" field MUST be present, and it MUST be "Symmetric". > > > > The definition in Sections 3.1 actually does add a constraint that the > others appear to not have: > > Implementations creating and validating MAC values MUST validate that the > key type, key length, and algorithm are correct and appropriate for the > entities involved. > > Or maybe the general requirement in Section 3.1 actually is meant to apply > to all MAC algorithms and not just the ones in that subsection..?
Well, this gets even odder: - Section 3.1 (HMAC) can accept key of any length. - As can Section 6.1.2 (Direct Key with KDF). - The rest can only take key of fixed length. - The only other MAC algorithm is section 3.2 (which takes key of fixed length). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
