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

feat: support detached payloads in COSESign and COSESign1 #197

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alex-richards
Copy link

Hey,

I've extended COSESign and COSESign1 to support detached payloads, adds a parameter to the public API, not sure if that's desirable.

I'm also pretty new to Go, I've tried to copy the existing style but I'm sure there's plenty that could be improved.

Cheers, Alex

#195

@SteveLasker
Copy link
Contributor

Hi, @alex-richards,
Thanks for the PR. Several of the maintainers/reviewers are at IETF this week. Please give us a bit of time to review.

Without knowing more about the specific scenario you want to implement, you might want to check this new draft for HASH Envelopes. It addresses many of the challenges detached payloads solve and create. Here's a set of slides we're presenting this week at the COSE Working group.

While we're still generally supportive for go-cose supporting detached payloads, one of the advantages of HASH Envelope is it's "just a payload" and you won't need to detach and re-attach the payload. Just FYI, we should still support detached payloads in go-cose.

@alex-richards
Copy link
Author

Thanks Steve, I'll have a read, though I'm interested in ISO 18013-5, which specifies detached payloads.

I've removed the breaking changes.

@alex-richards alex-richards force-pushed the detached-payloads branch 2 times, most recently from 4e80ef5 to bc11d1c Compare July 22, 2024 22:59
@SteveLasker
Copy link
Contributor

Hi @alex-richards. Welcome to the verasion/go-cose project and thank you for your contributions.
As go-cose is used in many projects and products, can you provide more info about yourself? Your profile has very limited info, with no additional info in your commits.

Thank you

@alex-richards
Copy link
Author

Hi @alex-richards. Welcome to the verasion/go-cose project and thank you for your contributions. As go-cose is used in many projects and products, can you provide more info about yourself? Your profile has very limited info, with no additional info in your commits.

Thank you

Hi Steve,

Yeah, sure. Do you have a preferred private way for me to get in touch?

@SteveLasker
Copy link
Contributor

You can reach me through my linkedin profile info.

@alex-richards
Copy link
Author

Hey Steve,

I've signed as discussed.

Cheers, Alex

@SteveLasker
Copy link
Contributor

Thanks, @alex-richards,
Several folks were at IETF this week, so maintainers may take a few days to catch up with their "day jobs" and review.

Copy link
Collaborator

@OR13 OR13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems ok to me, but it would be good to get more reviews, since this touches several interfaces

@SteveLasker
Copy link
Contributor

Thanks, @alex-richards, can you please resolve the DCO error: https://github.com/veraison/go-cose/pull/197/checks?check_run_id=27984447393

sign.go Outdated Show resolved Hide resolved
sign.go Outdated Show resolved Hide resolved
@alex-richards
Copy link
Author

@qmuntal I've made those changes, yeah, they're much clearer.

Not sure what resolving etiquette is here, tag you? Resolve myself?

@qmuntal
Copy link
Contributor

qmuntal commented Aug 13, 2024

@qmuntal I've made those changes, yeah, they're much clearer.

Not sure what resolving etiquette is here, tag you? Resolve myself?

You can resolve them yourself 👍

sign.go Outdated Show resolved Hide resolved
sign.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign1.go Outdated Show resolved Hide resolved
sign.go Outdated Show resolved Hide resolved
Copy link
Contributor

@qmuntal qmuntal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@alex-richards
Copy link
Author

Any merging etiquette I should know about? Or just go for it once it's approved? Is 2 enough?

@SteveLasker
Copy link
Contributor

Due to the slightly larger change, it would be good to have an additional golang and cose expert weigh in
@thomas-fossati, @shizhMSFT l, @setrofim can either of you please take a look?

Copy link
Contributor

@thomas-fossati thomas-fossati left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good to me. Thanks a lot for the great contribution!

bench_test.go Outdated Show resolved Hide resolved
return m.sign(rand, nil, external, signer)
}

// SignDetached signs a Sign1Message using the provided Signer.
Copy link
Contributor

@yogeshbdeshpande yogeshbdeshpande Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comments here are very identical to the comments for normal Sign Method.

At the least you should refer to the
// COSE defined detached payloads in Section 2 of [RFC9052]

Copy link
Contributor

@thomas-fossati thomas-fossati Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comments here are very identical to the comments for normal Sign Method.

I'd be surprised if they weren't ;-)

At the least you should refer to the // COSE defined detached payloads in Section 2 of [RFC9052]

I reckon the reference to S4.4 of RFC8152 is precise enough. A standards nerd would probably reference S4.4 of RFC9052 :-), but for the detached payload case, there is no material difference between 9052 and 8152.

Copy link
Contributor

@yogeshbdeshpande yogeshbdeshpande Aug 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thomas-fossati I beg to differ. Section 4.4 RFC8152 talks about general signing. There is no reference to Detached Signing in 4.4

My intention was also to reference to specification which clarifies aspects of DetachedSigning, which is lacking in the reference!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thomas-fossati I beg to differ. Section 4.4 RFC8152 talks about general signing. There is no reference to Detached Signing in 4.4

And rightly so, because there's nothing special about detached/non-detached in terms of signing and verification.

S4.4, Bullet point 5, second sentence:

[T]he full payload is used here, independent of how it is transported.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any decision here?

Comment on lines +487 to +488
// Notice: The COSE Sign API is EXPERIMENTAL and may be changed or removed in a
// later release.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Line 487 and 488 relevant here ?, given that we are commenting on Verify here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied these lines from the existing methods. I took it to mean the whole of the Sign/Verify API together.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should change this to sign/verify

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm waiting to see if anyone else has strong opinions on this.

Copy link
Contributor

@yogeshbdeshpande yogeshbdeshpande left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some minor points on the comments to Verify, but in general LGTM!

Copy link
Contributor

@shizhMSFT shizhMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to discuss more about the design in #195 before merging this PR as I have commented at #195 (comment)

bench_test.go Outdated Show resolved Hide resolved
sign.go Outdated Show resolved Hide resolved
sign.go Outdated Show resolved Hide resolved
Comment on lines +299 to +308
func Sign1Detached(rand io.Reader, signer Signer, headers Headers, detached, external []byte) ([]byte, error) {
msg := Sign1Message{
Headers: headers,
}
err := msg.SignDetached(rand, detached, external, signer)
if err != nil {
return nil, err
}
return msg.MarshalCBOR()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need

func (m *SignMessage) SignDetached(rand io.Reader, detached, external []byte, signers ...Signer) error
func (m *Sign1Message) SignDetached(rand io.Reader, detached, external []byte, signer Signer) error

?

Can Sign1Detached be implemented as

Suggested change
func Sign1Detached(rand io.Reader, signer Signer, headers Headers, detached, external []byte) ([]byte, error) {
msg := Sign1Message{
Headers: headers,
}
err := msg.SignDetached(rand, detached, external, signer)
if err != nil {
return nil, err
}
return msg.MarshalCBOR()
}
func Sign1Detached(rand io.Reader, signer Signer, headers Headers, detached, external []byte) ([]byte, error) {
msg := Sign1Message{
Headers: headers,
Payload: detached,
}
err := msg.Sign(rand, external, signer)
if err != nil {
return nil, err
}
msg.Payload = nil
return msg.MarshalCBOR()
}

?

Same question for SignDetached.

Copy link
Author

@alex-richards alex-richards Aug 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fussy to me, would making detached the base case and calling from Sign1 be ok? Saves unsetting the payload on the detached object.

if detached == nil {
return ErrMissingPayload
}
return m.verify(detached, external, verifiers...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can it be simplified as

Suggested change
return m.verify(detached, external, verifiers...)
msg := *m
msg.Payload = detached
return msg.Verify(external, verifiers...)

?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This clones the SignMessage object, correct?

@shizhMSFT shizhMSFT linked an issue Aug 15, 2024 that may be closed by this pull request
Signed-off-by: Alex Richards <alex-richards@users.noreply.github.com>
Copy link

codecov bot commented Aug 16, 2024

Codecov Report

Attention: Patch coverage is 64.86486% with 26 lines in your changes missing coverage. Please review.

Project coverage is 91.16%. Comparing base (2b6f94f) to head (fa0344c).
Report is 7 commits behind head on main.

Files Patch % Lines
sign1.go 40.90% 26 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #197      +/-   ##
==========================================
- Coverage   92.04%   91.16%   -0.88%     
==========================================
  Files          12       12              
  Lines        1973     1676     -297     
==========================================
- Hits         1816     1528     -288     
+ Misses        108       92      -16     
- Partials       49       56       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@SteveLasker SteveLasker added this to the v1.4.0 milestone Aug 16, 2024
@SteveLasker
Copy link
Contributor

Thanks for all the feedback.
To move forward, there are a number of questions, which seem to be change requests on this PR. Yet, there are several approvals.
Can folks please update their comments?
If you have a comment you expect to be addressed before merging, please change to a change request.
If there are no "change requests" by August 23, 2024, and we have 2 or more approvals from maintainers, we'll move to merge.

Copy link
Contributor

@shizhMSFT shizhMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing to "Request changes"

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

Successfully merging this pull request may close these issues.

External Payload Support for CoseSign1
7 participants