Some comments on the ZFS crypto design document: * Encryption policy - I'm not understanding why it is not possible to toggle the on/off encryption property on a dataset once it is defined. I think this might be viewed as a problem, or at least a minor-annoyance, in the future. When the Key Change feature (section 3.1.1) is implemented, perhaps that solution would also make it possible to toggle the crypto since it is a similar operation.
* Key Mgmt - The keys for all datasets associated with a pool are encrypted in the master key for that pool. Individual dataset keys are randomly generated. So, the person with the master pool key can unlock any of the underlying datasets. Is it possible for an individual to give their own key (rather than getting a wrapped, random key) when creating a new dataset so that the person with the pool master key could NOT view their data? Those "private" datasets would require prompting when the zfs-mount is issued so that the user could enter the correct key (or path to a keyfile or LABEL of a key stored on a token). I was thinking of a model similar to what we use internally on our devel system where individuals can create their own datasets - could users create their own, private, datasets that the admin could not decrypt? * Pool: setkey - How does ZFS identify the master keys if they are stored on a hardware token - is there a unique naming convention (i.e. the key objects CKA_LABEL attribute) that is used to identify the pool keys? * Key Modes: - Is this feature extensible for the future so that if we come up with different key mgmt methods, they could be easily added ? I'm thinking of some more complex key management solutions such as a centralized KM service that might require additional parameters to access the keys. -Wyllys Ingersoll This message posted from opensolaris.org
