Ilari, Yes, the issue that I ran into this discrepancy is the fact that the underlying (polymorphic) algorithm families (i.e. general AES-KW) do accept input keys of any length (provided they are valid for AES), and the crypto-function implementation I am using also will accept input keys of whatever you provide. But the COSE algorithm code point -5 described as "AES Key Wrap w/ 256-bit key" strongly implies that the input key is 256-bit as well, and the COSE library I'm using does not enforce this because... it just isn't explicitly defined anywhere AFAIK.
Brian S. > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Friday, November 21, 2025 9:28 AM > To: cose <[email protected]> > Subject: [EXT] [COSE] Re: RFC 9053 checks on symmetric key length > > APL external email warning: Verify sender [email protected] > before clicking links or attachments > > 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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
