Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for custom protected headers in t_cose_sign1_encode_parameters #286

Open
maxtropets opened this issue Aug 21, 2024 · 3 comments
Open

Comments

@maxtropets
Copy link

Suggesting to extend t_cose_sign1_encode_parameters with custom parameters handling.

One of the possible options - a callback(ctx) to be called after setting base parameters, so users can add more custom fields.

@maxtropets
Copy link
Author

Hi @laurencelundblade, could you please let me know if this's a valid suggestion?

We were researching means to pass more protected headers whilst working on microsoft/CCF#6445.

We ended up introducing a more complex signing code with encode_paremeters_.._ replaced(). However, if you think there're other (better) ways of dealing with this issue, we'll very much appreciate hearing your thoughts on this.

cc @achamayou

@laurencelundblade
Copy link
Owner

Hi,

The t_cose dev branch supports custom parameters in the t_cose_sign_sign interface. While there's a fair bit of work to do on the dev branch the parameters part is pretty stable. It works by passing in a linked list of header parameters you want added. It works for COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Recipient...

Maybe you want counter signatures? My thought there was to use something specific to counter signatures rather the (simple) extended parameter mechanism in the dev branch.

While the dev branch is compatible with the main branch, a switch to the dev branch is possibly a big thing for you because the dev branch is a big expansion of functionality and is not as stable.

@maxtropets
Copy link
Author

Thank you very much for your reply. We went with a workaround this time, but will track the progress of the dev branch for the future.

Maybe you want counter signatures? My thought there was to use something specific to counter signatures rather the (simple) extended parameter mechanism in the dev branch.

For our purposes we specifically needed to set custom parameters (more details on spec).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants