On 7/31/2014 10:58 AM, Simo Sorce wrote:
I am reading this document and there are some things I need to ask
* In "Vault password and secret key" you describe a mechanism where you
store a hash of the password used to generate the secret key, why ?
What's the purpose ?
The hash is for password verification. The encryption/secret key is for
encrypting the secrets. The hash will be different from the secret key
because they are generated with different salts. The hash is stored on
the server, but since it's different it cannot be used to decrypt the
We need a password verification to make sure all secrets in the same
vault are encrypted with the same password. If we allow different
passwords for different secrets, the password change command wouldn't
make sense because it will only work on some secrets and corrupt the others.
I'm open to other ways for password verification without hash. Any
* Why shared vaults need to be in a /shared/ namespace ?
Can't a user create a vault and then share it with other users ?
Ie should the fact a vault is shared just a property that can be changed
at any time ? If not, why not ?
We want to avoid conflicting names of private vaults created by
different people, so we put private vaults under the owner's namespace.
Yes, the owner can share the private vaults in their namespace, but the
ownership can change, or it can be owned by multiple people, or probably
the original owner will not be the owner anymore. So the /shared
namespace is provided for a global, non-user-specific vaults. The owner
can move a private vault into /shared, and vice versa, as long as it
doesn't conflict with an existing vault.
* In "Listing secrets in a vault " it seem that the metadata about
various secrets is obtainable in the clear, is that so ?
I am not sure it is a good idea to give blatant hints about what is
being encrypted in the vault.
The list of secrets are available to vault members/owners/escrow
officer/admin only, but they don't need to specify a password to view
the secret metadata. Non-members will not be able to see anything in the
vault including the list of secrets. If a member is not allowed to see
the list of secrets in a vault, the secrets probably should be split
into different vaults.
If we want to protect the secret metadata with password, does it mean we
need to encrypt it too?
Or we can make the access control more granular. Only owners can see the
list of secrets.
* In "Modifying a secret" you use "ipa vault-secret-del" but you mean
-mod I guess.
Yes, that's a copy & paste error. It has been fixed now.
* Why services are in the /shared/ namespace ?
Services don't seem to be something that you want to associate with a
specific user. So in that case it's put under the /shared namespace.
Even so, the vault membership can still be limited to certain
users/service instances. Being in /shared doesn't mean it's open for public.
* The paragraph "Changing service vault password" confuses me, is it
I revised the wordings in this section, please take a look again:
Please also see the design page:
I have not fully internalized all there is there, but most of it looks
Thanks for your feedback! Please let me know if you have other questions
Endi S. Dewata
Freeipa-devel mailing list