Event Confidentiality

[erikerikson]

As part of #276, protections of the data in an event can be lost once the connection across which the event is sent gets terminated. Does partial or complete encryption of the event solve this? Are there means to specify the protections required for data that touches disk? Are solutions for addressing event confidentiality in scope for CloudEvents?

[clemensv]

End-to-end encryption is a battlefield I would urge the group to stay out of. I realize that the requirement is real, but binding an encryption and signing model to this standard has a good chance of blowing a hole into the ship and sinking it.

Exhibit A: SOAP and WS-Security.

There are several options for end-to-end security. A comprehensive recent framework is Javascript Object Signing and Encryption (JOSE: JWS/JWE/JWT), which includes JWE https://tools.ietf.org/html/rfc7516 and JWS https://tools.ietf.org/html/rfc7515.

S/MIME is another option.

In messaging and eventing we largely see proprietary solutions today, also due the fact that key management is not trivial for one-way messaging without the ability to negotiate session keys, because of the degradation of key strength through frequent use, and because the receiver needs to be able to get at the required key material and through several layers of routing that might be a nontrivial challenge.

As I would love to see a standards-based model for messaging/eventing all up that builds on something like JOSE or S/MIME, I absolutely would want to avoid diving down into that rabbit hole in the core CloudEvents effort, certainly not before version 1.0.

[JemDay]

From a cloud-events perspective i would hope we can make statements along the lines of:

"... sensitive information SHOULD NOT be placed in event context attributes .."
"... data SHOULD be encoded/encrypted when sensitive information is present in the payload"

I don't think we need to into the weeds of the end-to-end mechanisms at present.

[duglin]

@erikerikson two questions for you:
1 - if we address #373, will that cover this issue?
2 - what do you think of this proposal: #373 (comment) ?

[erikerikson]

1 - yes, sorry for duplication
2 - broadly good proposal, response will come there

[JemDay]

See PR #399

[duglin]

Per the above discussion, and the closing of #373 (and merging of #399), I believe we can close this. If I'm mistaken please let me know and I'll reopen it.