feat(extensions): add verifiable CloudEvents with DSSE#1386
Conversation
|
@duglin - I decided to recreate the PR. There were too many merge conflicts, 800+ T-T, because of how poorly it diverged. I tried to force push by hard resetting then cherry picking, but it autoclosed the PR :(. Anywho updated! But the verify tools look broken since the removal the locale files references #1371 |
|
@xibz no worries. I’ll fix the CI issues tomorrow. They’re not related to your changes |
|
@xibz can you rebase using the latest 'main' branch? I think that should fix your CI issues. |
Introduces the verifiability extension, enabling producers to cryptographically sign CloudEvents and consumers to verify authenticity and integrity using DSSE (Dead Simple Signing Envelope) v1.0.2. Key design points: - Canonical value serialization per CloudEvents type for format-neutral signatures (no wire-bytes requirement for context attributes) - Optional signing of extension attributes via signedextattrs - Consumer behavior configuration matrix (strict/passthrough/core-only) - Proxy guidance: SHOULD re-sign when modifying signed fields - SDK phased rollout: JSON format first, additional formats by vote - Timestamp normalization to RFC 3339 Zulu with second precision Signed-off-by: xibz <bjp@apple.com>
|
@duglin - Done! |
|
Yep, it's good for a final review |
| Upon successful verification, implementations MUST return a result that | ||
| identifies what was verified: core only, core and extensions, or core with | ||
| extensions skipped due to unknown types. The verified event returned to | ||
| application code MUST contain only verified data, what exactly is included |
There was a problem hiding this comment.
This seems to contradict the passthrough mode below. I think we could just remove the first half of the sentence here.
jskeet
left a comment
jskeet
left a comment
There was a problem hiding this comment.
I won't claim to have exhaustively re-reviewed everything, but I've looked for the bits that I know I'm interested in :) Just a couple more comments.
| A proxy that modifies any signed field, including event data, core context | ||
| attributes, or any attribute named in `signedextattrs`, SHOULD re-sign the | ||
| event using a key that downstream consumers are configured to trust. A proxy | ||
| that cannot re-sign MUST NOT silently forward the modified event as if the |
There was a problem hiding this comment.
This requires that every proxy is aware of this extension, which I don't think is reasonable. (It would mean that a proxy which is valid today becomes invalid when this PR is submitted.)
I think it would be reasonable to say "a proxy that conforms with this extension" or something similar.
| | `Boolean` | UTF-8 encoding of `"true"` or `"false"` (case-sensitive) | | ||
| | `Integer` | UTF-8 encoding of the decimal representation without leading zeros, fraction, or exponent (per RFC 7159 Section 6) | | ||
| | `String` | UTF-8 encoding of the string value | | ||
| | `Binary` | Base64 encoding per RFC 4648, then UTF-8 encoded | |
There was a problem hiding this comment.
This feels unnecessary to me - why not just hash the bytes themselves? (The point is to get a byte sequence, and this is a byte sequence already.)
3 participants
Proposed Changes
feat: Add DSSE-based cryptographic signing for CloudEvents verification
Implements verifiable CloudEvents using DSSE (Dead Simple Signing Envelope) to ensure event authenticity and integrity across untrusted transport layers.
Key features:
Technical approach:
This enables cryptographic proof that events:
Does NOT address: event ordering, completeness, replay attacks, or confidentiality
Fixes #1302
Release Note