Hi Fraser, Given that today is the code freeze for this round, and I need to wrap up a ticket today so it's hard to squeeze it into my time to context switch and give your question a proper thinking, I suggest we handle it after this release. Hope it's okay with you. thanks, Christina On 04/28/2017 03:32 AM, Fraser Tweedale wrote:

or, "can I pretty please delete all this code?" ^_^

Hi Christina,

Ade has reviewed my PKCS #12 AES patches for CC effort (thanks Ade!) We have one main area where we need your feedback.

The KRA PKCS #12 recovery process for encrypted (cf. wrapped) keys previously performed the encryption and assembled the EncryptedPrivateKeyInfo structure in a rather "manual" way (~80 LOC). In my patch to convert this code path to use AES encrypted, I take an alternative (and much fewer LOC) approach: importing the private key to the *internal* key storage token, as a *temporary* key, and then invoking the same routine as is used for the wrapped key case.

Our question: is this fine to do when the system is in FIPS mode? The assumption is that the internal crypto token is always available and that it can do raw (unencrypted) private key import, and wrapping private keys to a symmetric key, while in FIPS mode. We just need to check this assumption.

The gerrit review of the patch involved is here: https://review.gerrithub.io/#/c/359027/

Thanks, Fraser