On 7/31/2014 5:34 PM, Simo Sorce wrote:
I think you misunderstood what I was proposing.
I was proposing the vault is the unit of encryption, as a single blob of
data. But the vault would still contain multiple secrets, simply
formatted into a json object.

Something like:

         { id: "email",
           data: "Passw0rd",
           description: "my email password"
         { id: "redhat.com",
           data: "Secret5",
           description: "redhat.com website password"

OK, understood. This means in the service use case the service vault password will have to be provisioned to service instances using separate vaults that use asymmetric encryption key. This type of vaults will become a "drop box" and will not support escrow.

Any concern about the crypto operations being computationally expensive,
or retrieving the whole blob just to see the metadata would waste bandwidth?

How big do you think the vault would be ?
It is not meant to contain anything more than a bunch of passwords, do
we really have a problem if the blob is a few tens of kilobytes ?

I can't say how people will use it, but regardless, we can configure the size limit on the server.

Given service passwords is an actual use case I think /services should
be a top level namespace available by default.

OK. Any preference how the service vaults should be structured?
* /services/<service name>@<server name> -> repetitive server name?
* /services/<server name>/<service name> -> more organized

Is this going to be the service drop box (to provision the service vault password) or the service vault (that the instance is going to access using the service vault password)? Or will the instances access a shared service vault?

Endi S. Dewata

Freeipa-devel mailing list

Reply via email to