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