On 8/1/2014 3:04 PM, Endi Sukma Dewata wrote:
On 8/1/2014 2:45 PM, Simo Sorce wrote:
On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote:
On 8/1/2014 12:21 PM, Simo Sorce wrote:
OK, understood. This means in the service use case the service vault
password will have to be provisioned to service instances using
vaults that use asymmetric encryption key. This type of vaults will
become a "drop box" and will not support escrow.
I do not understand why escrow would not be supported, can you
With a normal vault (symmetric key) the secrets will be encrypted
symmetric secret key, then the secret key itself will be encrypted with
the escrow officer's public key and stored on the server. On recovery
the escrow officer will decrypt the encrypted secret key with the
private key, and use it to decrypt the secrets.
I suppose with a drop box (asymmetric key) the secrets themselves will
be encrypted with the public key of the owner (i.e. the service
instance), not the escrow officer. The secrets can only be
retrieved/recovered using the owner's private key. There's no secret
to escrow, unless we want to escrow the owner's private key?
The service can create a symmetric key and encrypt it with its public
key and the escrow public key.
Not sure I understand. How does the admin provision the service vault
password to the instance? How does the instance retrieve the service
vault password? How does the escrow officer recover the service vault
Please take a look at the revised design:
The design now supports two types for vaults:
- regular vault with symmetric key derived from vault password,
- and drop box with asymmetric keys which may be new keys generated for
vault, not necessarily the owner's personal keys.
Both types will support escrow now. On regular vault we escrow the vault
encryption/secret key. On drop box we escrow the vault private key. It
will also support multiple escrow officers. The escrow officers need to
share the escrow private key (not the escrow officer's personal keys).
I removed the password hash used previously to verify the password.
Assuming that retrieving secrets with a wrong password/key will not
produce a usable result (invalid JSON structure), it's no longer
necessary to verify password.
The Client API has been simplified as well by handling the secrets as a
single collection. The CLI will still provide the interface to manage
the secrets individually. There's no service-specific API, it will be
handled by the CLI.
Please let me know if you have any comments/questions. See also the FAQ
and To Do list at the bottom of the page. I'll be out of the office
until Thursday, but I'll be back on Friday 22nd. Thanks!
Endi S. Dewata
Freeipa-devel mailing list