[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