[Freeipa-devel] Password Vault Implementation

Endi Sukma Dewata edewata at redhat.com
Fri Aug 1 15:28:28 UTC 2014


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:
>
> plaintext:
>      {
>          { 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




More information about the Freeipa-devel mailing list