On 11/27/2017 2:16 PM, Jamil Nimeh wrote:
See above with respect to set/getParameter. But hopefully you'll be
happy with the API after this next round. I have one other change I
will be making. I'm removing deriveObject. I'm uncomfortable right
now with the idea of the API executing an arbitrary class'
constructor. This is something I'm definitely willing to examine in
the future once the most pressing tasks both with this API, and
projects that are immediately depending on it are take care of. It is
easier to add calls to the API than it is to remove/modify/deprecate
them if there's a problem. I will file an RFE so that we can track
this enhancement.
Modifications to the KeyAgreement API are beyond the scope of this
JEP. We can certainly discuss ideas you have, but this KDF JEP isn't
going to be dependent on those discussions.
Fair enough.
The deriveObject stuff is a problem because it doesn't fit well in the
JCA. Mostly we've got KeyGenerator/KeyPairGenerator/KeyFactory that
produce objects of a particular provider. KeyDerivation is weird in
that one provider will be producing the derived key stream and
potentially others might need to provide key or cryptographic objects
from that stream. I can see the point in delaying this to a later rev
though it might make something like [KDF is Bouncycastle, keys are
PKCS11] a bit difficult to work around.
Last one -
Can I get you to buy into a MasterKey/MasterKeySpec that is not a sub
class of SecretKey but has the same characteristics (and probably the
same definitions) as those classes (and is what gets used in the .init()
argument)? This goes back to trying to prevent a SecretKey from being
used both with a KDF and the underlying PRF of the KDF. I know this is
a don't care for software based providers but would be useful for
security module based ones.
I'm really hoping to improve cryptographic type and use safety along the
way.
Thanks - Mike
