Need a representation of authenticity

[ebopalm]

When Eiffel flow is moving closer to the release stage and into delivery, the importance of each event will increase. To safeguard the quality of the pipeline, a way to validate an events authenticity is crucial.
The reason for introducing this issue now is that it has an impact for all messages even though the first usage is not likely to be found in any of the existing CI based flows.
One way to do this is to introduce an optional field in the "meta" area consisting of the following:

• Issuer (This is an identification of the originator of the event)
• Realm (This is a pointer to how/where to validate the Issuers identity and authorization)
• Checksum (This a a computed checksum of the entire event, including Issuer and Realm, using an apropriate checksum technology, encrypted using the Issuers private key using asymmetric cryptography technology of choice.)

In order to have a complete control of secure event handling, an external register of "autorized Issuers per Object" is needed. That particular system is left open for further design.

[d-stahl-ericsson]

Issuer and Realm should be covered by the meta.source property, no?

As for checksum, I don't see how putting a checksum in the message really solves anything. If I were a malicious third party and was able to tamper with the message en route, then I could also tamper with the checksum property. So we're back to square one.

Essentially, the problem can't be solved internally within the protocol, but externally, in infrastructure. For instance, you could expect a producer to keep a record of what it produced recently. Then, upon receiving a request, if you want to be really sure, you ask the producer, "Did you just produce an event with checksum X?". That could be a feature in Remrem.

[ebopalm]

Issuer/Realm could possibly be covered by the meta.source property its current usage is not colliding with its usage for Authenticity.
About tampering with te checksum. Yes, you can possibly create a fake message with fake Issuer, content and real checksum. But you cannot encrypt it matching a Issuer that has Authority to send events of a sort.
A fake message would therefore be detected if the encrypted checksum does not add up.

[d-stahl-ericsson]

Ok, I'm with you. And then your use of Issuer would be to select the correct decryption key, which is different from current use of meta.source.

How about an optional meta.authentication object, containing issuer, realm and encryptedChecksum?

[ebopalm]

After a review of the needed security features:

• Good enough event security can only be achieved by both defining events and their handling,
• Validation of events with embedded security information should take place before event has reach any consumer including any Event Storage features.
• The expected extra effort to validate security information should be offered as a core service and only applied to those events it concern.

Therefore it is not a feasible suggestion to insert security related information as an optional subset of all messages but make it a mandatory part of events with specific security classing. The reason for classify specific events as secure is to ease the identification of those for validation purpose and ease information handling that wants to reach certain security levels.

The ideas here will be the basis for a new proposal where not only secure event types are defined but also the corresponding validation and mechanisms for definitions of authorities.

I suggest this issue to be closed.

[d-stahl-ericsson]

I disagree, I don't think the issue should be closed. Supporting authenticity is a valid concern, the only question is how.

But when considering how, it is important to keep in mind that we are here strictly limited to the protocol. What features may we design into the protocol such that authentication of messages is facilitated? You are proposing the inclusion of checksum and issuer information - that seems reasonable, let's look at a concrete proposal of that linked to this issue.

As for optional/mandatory. From the point of view of a specific implementation, what you suggest makes sense: adopting Eiffel in my organization I want to ensure that certain sensitive events are authenticated before I process them. That decision may not be the same for you in your organization. In other words, it needs to be an optional part of any event - which you may then require in your particular case.