Encrypted bags
lvh opened this issue · comments
Immutable caps are great, but if I have a deeply network of capabilities, I don't want to have to refresh a bunch of caps just because I'm rotating a key, which is still good (and sometimes necessary) security practice.
They should probably have strong consistency semantics. It might be okay in some cases if they don't, but strong consistency should be the default. Alas, this rules out using e.g. OpenStack Swift as a storage backend, which is a little unfortunate.
This comes at a performance cost which should be clearly documented. It only makes sense for some use cases. They should be optimized for infrequent writes, with high replication. This reduces latency when using them, making this cost minimal.
Data bags look like caps. You can reference them in caps, and they will be included in the context. When executed, data bags just show their contents. This is good security practice; if we pretend that you can't look inside the bags, users might expect that. However, anyone with a reference to the bag could create a cap that dumps the entire context into an HTTP server they control, so, they can already see inside the bag.