On Fri, Jun 17, 2022 at 10:03:54AM -0700, Laurence Lundblade wrote: > Hello, > > There may be no good answer to this, but I wanted to check. > > - The payload is large, say a big chunk of SW, maybe a SW update. > - The HW hash engine is costly to spin up > - Signing twice, once with ECDSA once with LMS for PQ is required > > Because of the way COS_Signatures and the Sig_structure works the > hashes signed by ECDSA and LMS are not the same. One of the reasons > they’re not the same is that the hash covers the algorithm ID. You > have to hash all the bytes in the payload twice. > > > It seems like the thing to do here is add a level of hashing > indirection — hash the actual payload bytes, then that hash becomes > the COSE payload. Probably the right way to do this to define this: > > Hash_structure = [ > context : "Hash", > body_protected : empty_or_serialized_map, > payload : bstr, > ] > > as the bytes to hash. That way the algorithm identifier and other body > protected headers are covered. > > But given we’re probably not going to create COSE_SignIndirect, I can > still get most of what I need by creating a new header parameter > called body_hash_alg, and by making the above Hash_structure the body > for a COSE_Sign. The actual payload bytes would be transmitted > separately outside of COSE.
There is something a bit similar in JOSE: The unencoded singature option. That thing is a bit messy, but looks to be workable (I have actually implemented it). And looking at COSE signature format, the body_hash_alg does not look to be much worse. The way it is done looks to be relevant: - MUST be in protected bucket. - MUST be marked critical. There are some differences tho: This parameter would be int/bstr, not false (the JOSE parameter has weird polarity: false means unencoded). And Hash_structure needs to specify canonical encoding. Which in this case means using 0x83 for the array, and single fragments with minimal lengths for the bstr's. And might be a good idea to require at least 256 bit hash output length, in order to cut out crap like SHA-1 (-14) and overtruncated SHA-2 (-15). Then folks might want to use salted hashes in order to prevent some attacks. Fortunately seems like COSE registries already have salt parameter (-20). With hash_structure as given above, sticking that into body_protected does the trick. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
