Phase 1 needs to provide the ability to change the per pool wrapping key (Here in after referred to as the Data Set Key Encryption Key: DSKEK).
I think there is a potential problem though. Each pool knows only a "reference" to the DSKEK, ie: passphrase, filename, pkcs11 token object description (by knows I mean stored in a per pool property). In order to do a change of the DSKEK value we need to decrypt/unwrap each dataset key with the current DSKEK and reencrypt/wrap with the new DSKEK (in a single transaction). How do we know if the supplied DSKEK was the correct one ? I don't believe we want to encrypt a known (even unique to the pool) bit of data to be able to verify this since that provides known plain text. We also can't provide a hash of the DSKEK value because we may not be able to extract if from the keystore (PKCS#11 token) only use it. As far as the UI (CLI and GUI) is concerned I believe we should make changing the DSKEK an explicit action that is distinct from setting the key reference and distinct from the normal operation of providing the passphrase or PIN (in the case of a sensitive PKCS#11 token object). This should mean that providing the wrong key value (ie bad passphrase, wrong file content at the correct path, or wrong PKCS#11 token but with a correctly named object) the result is just garbage being returned rather than a failure condition (resulting in EIO for example). I'd like some suggestions on who we can overcome the issues of key change and also some suggestions for how the the CLI case would look. -- Darren J Moffat
