Signing a message currently requires copying the payload as an []byte into the cose.SignMessage.Payload field. For large payloads, this means copying large amounts of data. It also means the max size of a payload is limited by available memory.

Payloads are hashed and this can be done in chunks to avoid loading all that data into memory. Passing an io.Reader as Payload, perhaps as a PayloadReader variable, would allow the Sign() function to use that instead of the large []byte

refs

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

specifically in helpers_test.go

Currently throws a cbor decode error, so add a test case to cbor_test.go and get it passing.

It's OK if the test cases fail, but it'd be good to update them.

should be in terms of the overhead on top of the CBOR encoder and decoder and crypto ops

The spec says to use a salt length matching the hash length (i.e. rsa.PSSSaltLengthEqualsHash)

However, go-jose uses the auto length salt padding for the PS256 and switching it fixes the RSA verify failure for #7.

Use http://ugorji.net/blog/go-codecgen

Specifically ES384, ES512 would be good to support

• add 1.13
• drop 1.11?

@g-k 🔥 this CBOR security issue is already public knowledge and affects a library used by go-cose.

October 2013 - RFC 7049 (CBOR) is approved by IETF as an Internet Standard and RFC 7049 Section 8 describes security considerations such as malicious CBOR.

September 2019 - oasislabs finds tiny malformed CBOR data causes fatal out of memory error when decoded with latest releases of ugorji/go (CBOR library used by go-cose) and switched to fxamacker/cbor in early October 2019.

February 2020 - smartcontractkit/chainlink has a security issue with ugorji/go that is closed by switching to fxamacker/cbor. I don't have login access to view their security issue.

March 2020 - @fxamacker finds tiny malformed CBOR data that causes fatal out of memory error when decoded with any release of ugorji/go (1.1.0 - 1.1.7 as well as last commit 42bc974).

fxamacker/cbor comparisons to ugorji/go.

Click to expand:

Benchmarks used example data from RFC 8392 Appendix A.1 and default options for CBOR libraries.

1.13 is unsupported since 1.15 came out https://golang.org/doc/devel/release.html#policy so we should drop 13 and add 15 in the CircleCI config https://github.com/mozilla-services/go-cose/blob/master/.circleci/config.yml

I've been looking for a Go implementation of COSE and this is the only one I could find.

Is it still maintained/supported? Some of the issues/PRs are quite stale, and I'm wondering if it would be worth contributing fixes/improvements back up here.

see discussion around mozilla-services/autograph#76 (comment)

refs: #15

refs: #63

started in https://github.com/mozilla-services/go-cose/tree/decode-into

I think we can disable it and open an issue.

--- FAIL: TestI2OSPTiming

e.g. https://app.circleci.com/jobs/github/mozilla-services/go-cose/43

There are 20+ linters available ranging from format checks to security checks.

golangci-lint makes it easy to configure and run dozens of linters.

It was easy to use GitHub Actions Workflow (free feature from GitHub, Inc.) with golangci-lint.

Here's how it looks at fxamacker/cbor configured to run 18 required linters + 5 optional linters.

Auto-updated "linters" badge.svg on README.md indicates if any linter failed:

Screenshot of workflow results shown in pull request provided by @fxamacker

Using golangci-lint + GitHub Actions Workflow doesn't require signup with 3rd-party vendor. 😄

Using one of:

• https://github.com/dvyukov/go-fuzz
• https://github.com/google/gofuzz

Specifically:

Maybe NSS is doing additional validation on the CERT chain?

These two tests use an XOR that causes them to fail intermittently.

• test_cose_sign_verify_tampered_signature
• test_cose_sign_verify_modified_payload

This can be fixed by making the target byte XOR with 1, instead of itself.

i.e.

    --- FAIL: TestRustCoseCli/test_cose_sign_verify_P521_no_other_certs (0.10s)
        sign_verify_cose_rust_cli_test.go:56: 
            	Error Trace:	sign_verify_cose_rust_cli_test.go:56
            	            				sign_verify_cose_rust_cli_test.go:98
            	Error:      	Expected nil, but got: Byte lengths of integers r and s (9 and 8) do not match the key length 9
            	Test:       	TestRustCoseCli/test_cose_sign_verify_P521_no_other_certs
            	Messages:   	test_cose_sign_verify_P521_no_other_certs: signing failed with err Byte lengths of integers r and s (9 and 8) do not match the key length 9
        sign_verify_cose_rust_cli_test.go:91: 
            	Error Trace:	sign_verify_cose_rust_cli_test.go:91
            	            				sign_verify_cose_rust_cli_test.go:98
            	Error:      	Expected nil, but got: &exec.ExitError{ProcessState:(*os.ProcessState)(0xc00042e5c0), Stderr:[]uint8(nil)}
            	Test:       	TestRustCoseCli/test_cose_sign_verify_P521_no_other_certs
            	Messages:   	test_cose_sign_verify_P521_no_other_certs: error verifying signature with cose-rust exit status 2

from https://circleci.com/gh/mozilla-services/go-cose/23

Due to coverage error:

goveralls -coverprofile=coverage.out -service=travis-ci -repotoken 
flag needs an argument: -repotoken

https://travis-ci.org/mozilla-services/go-cose/builds/512314494

Hi,
I'm not sure if this is out of the scope for this library or it's implemented but I missed it in the docs.

I'm looking to serialize public keys in the COSE_Key format (https://tools.ietf.org/html/rfc8152#section-7), e.g., a ES256 public key would be serialized as the CBOR representation of {<kty>: 2, <alg>: -7, <crv>: ..., <x>: ..., <y>: ...}, with the specified integers replacing the keys.

Does this library support this? I noticed a general cose.Marshal function but this doesn't seem to encode it in COSE_Key format, but rather the CBOR encoding of the go/crypto ecdsa.PublicKey struct. (And if not, would a PR that does support this be appropriate for this repo?)