Open Stack

On Wednesday, January 30, 2013 at 10:48 AM, Eric Windisch wrote:

> > 
> > Message signing requires that the signed message is a string including at least some bits being serialized. That message will need to include the actual message_data, but also the topic, a timestamp, ttl, etc. These are pieces that will need to become part of the envelope. They need to be either serialized along with the message data or concatenated with the message data to be signed. Serializing these pieces together seems far more optimal. However, keep in mind that the message signature chain will need to be separate.
To make further progress on the trusted messaging / rpc blueprint, these considerations will have to be resolved.

Presently, serialize_msg(msg) does not accept a topic, a timestamp, or a ttl. These are vital for the trusted messaging blueprint. It does not seem prudent to include these in the message itself, unless wrapped in a larger dict, either before being passed to serialize_msg, or as part of that method itself.

The new envelope would become:

     sub_envelope = {
'topic': topic,
'ttl': ttl, 'timestamp': timestamp   # should this just be 'expires_at' ??
'msg': raw_msg
     }
     jsonmsg = jsonutils.dumps(sub_envelope)

     msg = {_VERSION_KEY: _RPC_ENVELOPE_VERSION,
                _MESSAGE_KEY: jsonmsg,
                _SIGNATURE_KEY: jsonutils.dumps(sign_msg(jsonmsg)),
                _SIGNATURE_ID_KEY: get_crypto_id(),
                _SIGNATURE_PROTO_KEY: get_crypto_ver() }


The deserialize method would verify the key, deserialize jsonmsg, and return it (much as it does now).

Hash key names and the methods are just for the sake of example. I am intentionally avoiding nesting anything inside 'msg' per the concerns highlighted earlier (the idea of avoiding double serialization by zipping this dict).

I'm looking for thoughts and feedback,

Thank you,
Eric Windisch 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130131/af245029/attachment.html>