Adding zero trust to cloudevents

[xibz]

I ended up creating a pre-proposal that looks like what I may I originally thought was wanted as part of the spec via SIG discussion, but after seeing the content, it was decided that it made more sense as an issue.

For reference: #1301

This issue will cover what is in and what I call the pre-proposal, and to outline some terminology and key concepts for zero trust. Discussion around zero trust can happen here which is much more appropriate than the original pre-proposal.

First, I want to call out that the pre-proposal is a dive into the various protocols that cloudevents support and to ensure that there's some place where we can add security metadata to.

---

Zero Trust

The idea of zero trust is that we do not assume that any request is trustworthy by nature. Instead cloudevents should provide way(s) to allow for verifying incoming requests.

Summary

To review the supported protocols of cloudevents to allow handling of security metadata for requests to be verified with. It is imperative that some understanding exists for each protocol to ensure what their limitations are. This will allow us to understand the limits zero trust can be implemented as.

This issue will also act as a discussion platform around zero trust, and any updates I have as I write the proposal which should help with any discussions and/or questions I may have during the SIG meetings.

I will explore existing tooling and libraries such as S/MIME (@clemensv idea), jose, and a few other libraries/tools to see what may work for zero trust. It is important to outline that this future proposal is not in the business of inventing new algorithms, tools, etc. The reason for this is there are already plenty of tooling around security that should be sufficient. Further any new algorithms would require us to maintain it and also specialize in security, e.g. handle any CVEs, which is something we do not want to do.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

[duglin]

@xibz what's the status of this one?

[xibz]

@duglin - Sorry for the lack of updates here, but we've been actively working on this internally with security folks.

So for some updates: We are looking at flexibility but also being opinionated for this proposal. I proposed both jose and s/mime, but our security folks stated that CMS based verifiability is too fragile (proposal illustrates pros and cons). Instead we are allowing for the proposal to have flexibility in choosing whatever security standard you want, but defaulting to something like DSSE

I'll see if I can attend this weeks SIG (have a conflicting meeting at the same time), and give updates there and timeframes of the proposal now that we have some of it written.

[xibz]

/remove-lifecycle stale

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.