S/MIME, `multipart/encrypted`, `multipart/signed`

[alexec]

I’ve created this issue to talk about using S/MIME with CloudEvents. It’s been discussed and alluded to before, but I want a place to to centralize discussion.

This maybe a simple as setting datacontenttype to the appropriate content-type.

[clemensv]

I think we would need a proper extension specification for S/MIME. https://www.rfc-editor.org/rfc/rfc8551

I also think that the bulk of what's needed already exists.

a) RFC8551 applies to the "Internet Message" as defined by RFC5322, extended by MIME RFC2045 b) HTTP leans on RFCs 5322/2045 for its own message format. The differences are largely constraints to MIME imposed by HTTP, see https://www.rfc-editor.org/rfc/rfc7231#appendix-A c) The CloudEvents HTTP binding binds CloudEvents to "HTTP request and response messages" as it says in the abstract, very intentionally. https://github.com/cloudevents/spec/blob/main/cloudevents/bindings/http-protocol-binding.md#abstract

That means there already is a clean mapping for any CloudEvent to map to a MIME message via c) and MIME messages can be signed and encrypted using S/MIME, yielding an output Internet message. The reverse uses the same mappings.

Moving that Internet message to a destination without disclosing that a CloudEvent is even involved would then a matter of mapping it to the respective application transport (trivial for HTTP), which is arguably out of scope for us, but can be described non-normatively.

A CloudEvents extension would be concerned with describing the above and may then further explain how to map the S/MIME message to a CloudEvent and back so that it can travel via CloudEvents infra. That again will likely lean on the HTTP binding for a start and will have to explain canonicalization and header mapping rules.

A principle I would want to apply here is that we do not discuss any of the cryptography aspects and leave those to S/MIME, but rather focus on consistent metadata mappings.

For instance, I would expect all S/MIME processing to occur on an Internet message representation and that will use header names as described in the S/MIME spec. Those violate our conventions since they're mixed case and have separators, but they might factor into signatures. Therefore, we might need explicit translations for header names that must surface as extensions on the CloudEvent envelope.

[alexec]

Let me paraphrase so I can be sure I understand:

Encryption:

1. Convert the CloudEvent into a HTTP message (using the CloudEvent/HTTP binding).
2. Encrypt the HTTP message. The encrypted message might be a Internet Message.
3. Send that to your transport (using some kind of Internet Message/Kafka binding).

Decryption:

1. Receive the message.
2. Re-constitute the Internet Message from the transport (e.g. Kafka/Internet Message binding).
3. Decrypt the Internet Message into a HTTP message.
4. Re-constitute the CloudEvent from the HTTP message using HTTP binding

Am I right in thinking that any CloudEvent can be represented as a Internet Message? But the converse is not true?

[duglin]

ping @clemensv

[clemensv]

Yes.

In binary mode, CloudEvents is mapped to the transport message and then any mechanism defined for that transport message is used. So mapping to the Internet Message (via CloudEvent HTTP) will allow S/MIME to work "as normal" and then the message gets sent via SMTP or HTTP and decrypted on the other side and then converted back into CloudEvents. No need to invent anything new, just describe that model.

[duglin]

@alexec is more discussion needed on this or can we close it?

[alexec]

Yes. I think we're good.

[alexec]

[alexec]

[alexec]

I don't even need to think anymore.

[duglin]

hmm I would love for you to continue that chat to ask it how people know how to merge the password back into the event - for example, how does the receiver know the 2nd part contains CE properties and does the "encrypted password" include the key ("password") or just the value?

[alexec]

i'd noticed that, it should be encrypted data. You can always ask yourself. I find it an exceptional (if often stupid) research tool: https://chat.openai.com/chat

[duglin]

I can't seem to login/create an account. Can't do it for Bing either :-(