To get more sharp on what an addition to standard COSE would look like:
A new signature type, COSE_SignIndirect is defined. It looks the same as
COSE_Sign. A new CBOR tag is created for it and all.
COSE_SignIndirect = [
Headers,
payload : bstr / nil,
signatures : [+ COSE_Signature]
]
Hash_Structure is defined:
Hash_Structure = [
context: “Hash”,
body_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]
SigIndirect_structure is defined as an alternative to Sig_structure. They are
different enough that I don’t think it is worth tweaking Sig_structure.
Sig_structure = [
context : “SignatureIndirect",
sign_protected : empty_or_serialized_map,
body_hash: bstr
]
When signing:
- Select the hash function you are going to use and put its ID in a body
protected header (hash function is always required, so no need to mark critical)
- Create any other body protected headers of interest, perhaps a salt (mark
them critical if they are)
- Create the Hash_Structure (use deterministic encoding)
- Run Hash_Structure through the selected hash function
- For each signature
- Select the signing algorithm and put it in a signer protected header
- Create any other signer protected headers of interest
- Create the SigIndirect_structure (use deterministic encoding)
- Sign it using the selected signing algorithm
This seems the cleanest and most in line with the rest of COSE. It allows for
all the protected and unprotected headers one could want. It allows for AAD
and/or payload.
Does this seem right for a standard proposal?
What it doesn’t do is allow an implementor of this to use an off-the-shelf COSE
implementation. The implementation would have to be modified quite a bit to
support this.
LL
> On Jun 18, 2022, at 6:19 AM, Ilari Liusvaara <[email protected]> wrote:
>
> 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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
