Open Stack

Just in case I might have been seen as quiet on this front, I want to outline what work remains for trusted messaging in Grizzly, where we are, and what might be possible to complete.

First, sending signed messages will require sending RPC envelopes which will not be enabled in Grizzly. Thus, even if the trusted-messaging blueprint is completed, unless we add a flag to disable backwards-compatibility, message-signing will not be usable until the release of Havana. Having an option to disable backwards-compatibility might be a reasonable idea, considering there will be plenty of brand-new installations for which backwards-compatibility is a non-issue.

Unfortunately, as I've previously mentioned on this list, but for which no discussion has followed, the envelope format was added in a way in which I do not feel meets the requirements of the message signing blueprint.  Specifically, there had been no consideration in the envelope format that we may need to hash multiple fields.  I'm afraid it seems impossible to fix this without either sending two full copies of the message (silly), or breaking compatibility with RPC-ENVELOPE v2. The latter is fairly ugly, but the reality is that nobody is actually *sending* v2 messages because this feature is presently disabled, so I think we can and should break RPC-ENVELOPE v2 and iterate to v3.

I presently have a patch that introduces RPC-ENVELOPE v3, although it is presently failing some tests:
 https://review.openstack.org/#/c/21562/

This patch introduces much of what we need for trusted-messaging. It fixes the envelope and introduces a replay-prevention check that is a non-secure variant of what we'll do with trusted-messaging enabled.  This patch will solidify how/where we will do the signature verification, for instance. I believe there is a very strong chance we can get this patch in for Grizzly, but we do need to settle whatever concerns/questions there might be about v2 versus v3 envelope compatibility and how the API should look. I do believe we absolutely do need to resolve these questions before feature-freeze because we do not want to make breaking changes after, or worse, in Havana.

Once these changes land, doing the message signing and verification, especially if we use a high-level library such as pygpgme, is relatively straightforward. It is premature to say this can be ready for G3, the time is tight, but I don't think it is an impossible goal, either.  In doing so, we'll likely need to rev the RPC envelope again, but in a non-breaking fashion.

Finally, in regard to the implementation of crypto, through a bit of analysis, and even some trial-and-error, I've realized that crypto in Python is terribly immature.  The choice of OpenPGP over X.509 is largely to do with the availability of standardized keyserver options, also OpenPGP is *designed* for the decentralized pattern that we're using in OpenStack messaging.  These factors both considered, I've decided that the best chance to complete this work for Grizzly is to use pygpgme as an almost end-all, be-all solution. This depends on the LGPL C-library, GPGME. After some consideration and discussion, I *think* this license is compatible with the Apache license, as long as we are simply linking. Keysevers will be initially supported through HKP, for which plenty of keyserver options presently exist.  Finally, it seems reasonable that if there is a sufficient demand, a pure-python implementation can be complete for Havana.

Regards,
Eric Windisch

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