Add support for CWT Claims & Type in Protected Headers #183

OR13 · 2024-01-26T17:23:15Z

closes #173

closes #184

This PR should remain open until numbers are assigned to:

codecov · 2024-01-26T17:24:16Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.20%. Comparing base (2b6f94f) to head (0906ae5).
Report is 1 commits behind head on main.

❗ Current head 0906ae5 differs from pull request most recent head 1980457

Please upload reports for the commit 1980457 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #183      +/-   ##
==========================================
+ Coverage   92.04%   92.20%   +0.16%     
==========================================
  Files          12       12              
  Lines        1973     1976       +3     
==========================================
+ Hits         1816     1822       +6     
+ Misses        108      105       -3     
  Partials       49       49

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

cwt_test.go

headers.go

OR13 · 2024-01-26T17:29:09Z

cwt.go

+	CWTClaimConfirmation   int64 = 8
+	CWTClaimScope          int64 = 9
+
+	// TODO: the rest upon request


I don't think it is smart to add the whole registry in the first PR.

Based on the above, it looks like we have the minimal code needed to proceed.

We should add what is bare minimum required, and then extend it when a new point needs to be registered!

[...] and then extend it when a new point needs to be registered!

Sorry, I have probably missed the right conversations, but I am not sure I get what the strategy is. There are 10's of claims already registered. What is the criterion for promoting them from the CWT Claims registry to consts in the cose package?

I think we should explicitly document how to add new claims here.

cwt_test.go

OR13 · 2024-01-26T17:39:58Z

cwt_test.go

+	fmt.Println("message verified")
+
+	// tamper the message and verification should fail
+	msgToVerify.Payload = []byte("foobar")


for this test, it might be better to tamper with the protected header.

SteveLasker · 2024-02-23T16:16:22Z

@qmuntal, @shizhMSFT, @thomas-fossati, @henkbirkholz can you please take a look, and provide some feedback to @OR13

shizhMSFT

Does CWT deserve its own package package cwt under package cose?

SteveLasker · 2024-03-08T16:12:55Z

go-cose call feedback: consensus was to do it in this package.

OR13 · 2024-03-08T16:30:24Z

related issue #184

SteveLasker · 2024-03-08T16:31:14Z

blocked, awaiting: https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/

SteveLasker · 2024-04-05T15:09:09Z

https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/ is progressing is progressing. Expectation a few more weeks.

henkbirkholz

correctly reflects:
https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/10/
which will move with:
https://datatracker.ietf.org/doc/draft-ietf-cose-typ-header-parameter/05/

SteveLasker

Approve of the changes, however we decided to wait for https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/ to be completed, with a comment added referencing the RFC #.

@OR13, please add the RFC # as part of this pending PR/Issue as well: #184

OR13 · 2024-04-07T18:34:42Z

I added support for the typ header parameter:

18([
h'a30138230fa2016e6973737565722e6578616d706c65026f7375626a6563742e6578616d706c65106f6170706c69636174696f6e2f637774', 
{4: h'31'}, 
h'68656c6c6f20776f726c64', h'00b8f0fbee7d5ca003678a173a1f1cb5f6233e85f2dd421d4d56d13541a67e01fd0c7addabc2c3b07d5b08a027382629aac41dd3f62f69d6c9209e2ca99255bda78600f3ca500d482c9b3a220dfd14395c42d02e0fa423e9192deb83c27b41257bcb3e9162db9e3de0895a81fb51d2ae41e9f07d91146832cbe91fa85b48456aef8ebc82'
])

Decoded protected header:

{1: -36, 15: {1: "issuer.example", 2: "subject.example"}, 16: "application/cwt"}

Signed-off-by: Orie Steele <orie@transmute.industries>

OR13 · 2024-04-07T18:40:31Z

I suppose there is an API consideration here, perhaps the validation checks should only happen when serialization occurs, instead of causing an error to be thrown when for example invalid claims or invalid cose type is set.

SteveLasker · 2024-06-21T15:06:20Z

Sooooooo, close.

cwt.go

thomas-fossati

marvellous, thanks!

I have left a few (mostly silly) comments for your consideration.

thomas-fossati · 2024-06-21T15:43:02Z

cwt.go

+	CWTClaimConfirmation   int64 = 8
+	CWTClaimScope          int64 = 9
+
+	// TODO: the rest upon request


[...] and then extend it when a new point needs to be registered!

Sorry, I have probably missed the right conversations, but I am not sure I get what the strategy is. There are 10's of claims already registered. What is the criterion for promoting them from the CWT Claims registry to consts in the cose package?

I think we should explicitly document how to add new claims here.

cwt_test.go

headers.go

cwt_test.go

Signed-off-by: Orie Steele <orie@transmute.industries> Signed-off-by: steve lasker <stevenlasker@hotmail.com>

Co-authored-by: Orie Steele <orie@or13.io> Signed-off-by: Orie Steele <orie@transmute.industries> Signed-off-by: steve lasker <stevenlasker@hotmail.com>

Signed-off-by: Orie Steele <orie@transmute.industries> Signed-off-by: steve lasker <stevenlasker@hotmail.com>

Co-authored-by: Thomas Fossati <tho.ietf@gmail.com> Signed-off-by: steve lasker <stevenlasker@hotmail.com>

Co-authored-by: Thomas Fossati <tho.ietf@gmail.com>

OR13 · 2024-06-21T20:29:23Z

@thomas-fossati regarding #183 (comment)

Its a fair point.

My lazy answer is, people can add pull requests for the IANA registry entries they wish the library supported, and they can use the registries without adding "developer experience for them", even if we don't support them here.

We could decide to not add any registry entries from the CWT registry, and only support the registered headers.

OR13 · 2024-06-21T20:43:59Z

The combination of a cross fork PR, and the DCO rebase + github suggestion merges... has made this more trouble than its worth.

@thomas-fossati If you think we should drop the CWT side of this, I will probably just do a fresh PR that only defines the header parameters, and provide some examples that show how to use them, without defining any CWT registry specific stuff.

thomas-fossati · 2024-06-21T21:00:34Z

The combination of a cross fork PR, and the DCO rebase + github suggestion merges... has made this more trouble than its worth.

@thomas-fossati If you think we should drop the CWT side of this, I will probably just do a fresh PR that only defines the header parameters, and provide some examples that show how to use them, without defining any CWT registry specific stuff.

I believe this PR is good and worth adding into the mainline as-is.

Let's raise a couple of tracking issues (one for the registration, one for the potential refactoring) and let's get it merged.

Thanks again for the great contribution.

thomas-fossati

🚢 it

SteveLasker · 2024-07-10T15:17:59Z

@OR13, did you want to re-submit this as a new/clean PR, or can we merge as-is?

With #187 and #188 queued up, we're ready for a new release.

SteveLasker · 2024-07-12T20:42:31Z

Per discussion with @OR13, it was easier to close and redo this PR than fix the DCO issues.
Closing as this with replaced PR #189

OR13 requested review from henkbirkholz, qmuntal, roywill, setrofim, shizhMSFT, SimonFrost-Arm, SteveLasker, thomas-fossati and yogeshbdeshpande as code owners January 26, 2024 17:23

OR13 force-pushed the feat/cwt-claims-in-headers branch from 83f2079 to bd3d70d Compare January 26, 2024 17:25