Interface change request for Detached Content about t_cose HOT 4 CLOSED

Yes, the interface can change in t_cose 2.0, but we have to support the t_cose 1.0 interface in a backwards compatible mode.

Your change would make the internals of t_cose_sign simpler which is good, but it would also make the use of the two-step signing more complicated. Look at two_step_sign_example(). All the BstrWrap stuff that is in t_cose_sign_encode_start() and t_cose_sign_encode_finish() would have to be implemented by the caller making it harder to use the two-step option. Example code will help, but not completely simplify it. I also worry it will make the 1.0 compatibility more complicated.

How does this help with detached payload encrypt-then-sign? At some point there should be an encrypt-then-sign API in t_cose. It should work for detached and non-detached payloads. It would probably be the t_cose_message object/API/context.

from t_cose.

With proposed interface the caller must call QCBOREncode_BstrWrap() and QCBOREncode_CloseBstrWrap2() on two-step signing. It is certainly harder because the caller may not know that the payload should be bstr-wrapped in COSE struct.
I'll modify the interface in my forked repository as a trial, so judge that the change is appropriate.

from t_cose.

I have a pretty good idea what the calling code would look like. I also can see how the t_cose 1.0 backwards compatibility mode can be handled too.

I'm still trying to understand the benefit of this change.

I know for sure that it will simplify the internals of t_cose.

Are there use cases where it will benefit the user of t_cose? So far it just seems like it makes it harder for the user. In particular, does it make things easier for encrypt-then-sign with detached content?

from t_cose.

Fixed by baa6001

from t_cose.