Remote Signing

[shizhMSFT]

This PR fills the gap to a mature go-cose implementation with security improvements and remote-signing extensibility.
Details are available at DESIGN.md.

It resolves #37 and the following highlighted issues:

• Protected header should not be re-serialized for verification. #7
• nil external data should imply empty slice, not nil #8
• Key extensibility support #9
• More algorithms support #10
• negative tests #22
• Validate crit in protected header #23
• Enforce alg protected header when Sign and Verify if external data not supplied #32
• Algorithm Test Coverage #36
• Unit Tests #41

This PR is co-authored by @qmuntal.

[shizhMSFT]

@thomas-fossati The DCO check fails on 5 commits with error message:

Author: Quim Muntal, Committer: GitHub; Expected "Quim Muntal quimmuntal@gmail.com", but got "qmuntal qmuntaldiaz@microsoft.com".

How can we resolve it? or should we just set DCO to pass?

/cc @qmuntal

[SteveLasker]

unfortunately, bypassing dco bypasses the licensing and introduces the potential for ownership of the code.
Can you resolve in the branch and resubmit?

[shizhMSFT]

Squashed commits with DCO fixed.

[thomas-fossati]

LGTM, thanks all for the incredible work.

Should we explicitly tag main before merging? (I think Steve suggested this some time ago.)

[SteveLasker]

awesome work!
Yeah, let’s tag main into a branch.
Naming is hard. @thomas-fossati, what tag/branch name would be meaningful for you? If we look 6 months from now, what name would make sense?

[thomas-fossati]

Naming is hard. @thomas-fossati, what tag/branch name would be meaningful for you? If we look 6 months from now, what name would make sense?

I'm after something that evokes legacy / impending deprecation.
Any suggestions? :-)

[yogeshbdeshpande]

I think the tense of the sentence should now reflect past tense with the implementation, example like earlier implementation. It should also say, had caused issues like #7 and #8 which is been fixed in the current implementation.

[SteveLasker]

@shizhMSFT, can you make this minor wording change?
Suggested change:

Prior versions of go-cose implemented COSE_Sign and COSE_Sign1. However, the verification process did not follow RFC8152 which had caused issues like #7 and #8 which have been fixed in the current implementation.

[shizhMSFT]

updated in 6ef3dd4

[yogeshbdeshpande]

Is Line 28 referring to veraison/go-cose or some other repo? when it refers to golang nativity ?

As far as I reckon that was with older notary implementation ? If so needs to be specified clearly.

[SteveLasker]

@shizhMSFT, what do you think?

[shizhMSFT]

updated in 6ef3dd4

[SteveLasker]

Agreed on the fork info atop. We can update the readme a bit later when we’ve decoupled. For now, just getting the code merged is a great start so we can start the dependencies and flush out the next round of issues

[yogeshbdeshpande]

anch name would be meaningful for

I suggest a simple strategy, example(Feel free to shoot it down):
go-cose-v.1.0.0

and then when Notary major release comes go-cose-v.2.0.0
2.0.1 for notary patches and 2.1.1 for notary enhancements?

[qmuntal]

anch name would be meaningful for

I suggest a simple strategy, example(Feel free to shoot it down): go-cose-v.1.0.0

and then when Notary major release comes go-cose-v.2.0.0 2.0.1 for notary patches and 2.1.1 for notary enhancements?

Module tags should strictly follow semantic versioning with v prefix, else Go toolchain won't like our releases. This is what I would do:

• Tag main as-is now with v0.1.0.
• Merge this PR and create a new tag named v0.2.0.
• Once we pass all security reviews and we are confident we have a stable API, we can aim for the v1.0.0.

[yogeshbdeshpande]

anch name would be meaningful for

I suggest a simple strategy, example(Feel free to shoot it down): go-cose-v.1.0.0
and then when Notary major release comes go-cose-v.2.0.0 2.0.1 for notary patches and 2.1.1 for notary enhancements?

Module tags should strictly follow semantic versioning with v prefix, else Go toolchain won't like our releases. This is what I would do:

• Tag main as-is now with v0.1.0.
• Merge this PR and create a new tag named v0.2.0.
• Once we pass all security reviews and we are confident we have a stable API, we can aim for the v1.0.0.

Works for me!

[shizhMSFT]

Golang projects follows SemVer2.

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

The previous go-cose implementation is not SemVer2 versioned. To golang, it is still at v0.0.0. Then we can start with v1.0.0.

If the previous implementation is required to be v1.0.0, then we can have this implementation as v2.0.0. However, if we do want v2.0.0, we need to update the go.mod file to github.com/veraison/go-cose/v2. Meanwhile, we have to fix all vulnerabilities in v1.0.0 or deprecate v1.0.0 immediately after tagging it for security concerns.

[SteveLasker]

what about v0.0.0-sign1 , with comments that this is NOT a supported release with 1.0 as the supported codebase

[qmuntal]

what about v0.0.0-sign1 , with comments that this is NOT a supported release with 1.0 as the supported codebase

Like it and +1 one what @shizhMSFT said. I would just not start with the v1.0.0 but with v0.1.0 so we can still iterate on the API a few weeks more without breaking any compatibility promise.

[SteveLasker]

I've created tag v0.0.0-sign1-alpha.0 and created the branch v0.0.0-sign1-alpha.0

I've also updated issue #37 to reflect the steps

@shizhMSFT, if you could make the minor changes noted above

• line 20
• line 28

I believe we're ready to merge

[thomas-fossati]

🚢 it!

[yogeshbdeshpande]

Great Job Shiwei! Thank you for all the Hard Work.

[SteveLasker]

LGTM