<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <br>

    <br>

    <div class="moz-cite-prefix">On 11/27/2017 11:46 AM, Michael StJohns

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:10ef9287-a475-d6aa-030d-2819c9d3b0a5@comcast.net">On

      11/27/2017 2:16 PM, Jamil Nimeh wrote:

      <br>

      <blockquote type="cite">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.

        <br>

        <br>

        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.

        <br>

      </blockquote>

      <br>

      <br>

      Fair enough.

      <br>

      <br>

      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.

      <br>

      <br>

      Last one -

      <br>

      <br>

      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.

      <br>

      <br>

      I'm really hoping to improve cryptographic type and use safety

      along the way.

      <br>

    </blockquote>

    <br>

    I'm not quite getting what you mean here.  From looking at KDFs

    described in 800-108, it looks like the key input to the KDF is K<sub>I</sub>,

    and K<sub>I</sub> ends up being the seed for each round of the PRF. 

    If that isn't what you're referring to can you explain what you're

    looking for in more detail?<br>

    <br>

    --Jamil  <br>

    <sub></sub>

  </body>

</html>