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. It seems like a helpful errata to indicate alongside the kty-must-be-symmetric requirement an explicit statement similar to: The "k" field byte string length MUST match the input key length of the algorithm being used. 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..? Brian S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
