[kmip-interop-tech] Expected Key Format Type

The KMIP operation is Create Key Pair.



John
From:
Bruce Rich [mailto:]

  Sent:  Friday, 23 March 2018 6:41 AM
To:  Prashant V Mestri <>
Cc:  Tim Hudson <>; ; Felipe Kendi <>; John Leiseboer <>
Subject:  Re: [kmip-interop-tech] Expected Key Format Type



  Interesting discussion.  Just to frame it a bit, we're only discussing the usecase around creation, not registration, right?

Because for those exchanges where the client REGISTERs the managed cryptographic object (and provides the key material), the spec is pretty clear that the server is required to
  record the Digest with the Key Format Type the client sent (and may record other formats).

However, for those exchanges where the server CREATEs the managed cryptographic object, the spec doesn't clearly mandate a Key Format Type.  To choose something other than PKCS#1
  format for RSA keys seems a bit disrespectful to Rivest, Shamir and Adleman, but what wasn't mandated and isn't prohibited is probably permissible.



BTW, these profiles have been out a while, so seems like we're a little late-to-the-party at this point, as most folks have key representation (format) conversion code written and
  deployed already...Prashant, I know you do, because I wrote it...



This sounds like a topic for the F2F.  Originally, this was a "server knows best" approach (allegedly informed by "policy"...), and the client would deal with what the server chose.
  Now that we're eight to ten years down the road, perhaps worth revisiting.



Regards,

Bruce Rich





  On Thu, Mar 22, 2018 at 12:56 PM, Prashant V Mestri < 
> wrote:

I agree with Felipe and John.

  "The Key Format Type field in the Digest attribute indicates the format of the Managed Object from which the Digest Value was calculated."

  e.g. IBM SKLM server has PKCS8 key format type for Private Key and X509 key format type for public key. The digest key format type as per above definition will be same as the managed object from
  which digest value is calculated.

  Are we required to " hard code " PKCS1 as digest key format type in the response of the AKLC test cases even though Private Key and Public key have different key format types  ?

  or
  Are we required to have only PKCS1 key format type for Private and Public so that digest key format type is always PKCS1 ? If so the AKLC test cases do not categorically mention it!!

  Best Regards
  ___________________

Prashant MESTRI

  IBM
From:          Tim Hudson < 
>
To:          "  "
  < 
>
Date:          03/21/2018 03:55 AM
Subject:          Re: [kmip-interop-tech] Expected Key Format Type
  Sent by:          < 
>

 There are two contexts - one is the Key Format Type by itself - and the other is the Key Format Type within the Digest structure.
 There is a clearly separate rule for that - and it wasn't accidential that the rule for Digest was not updated to include variable Key Format Type.

 We have also previously discussed actually removing the variability on Key Format Type from the profiles as well - given that it is causing some interoperability challenges with vendors picking unusual values and then not supporting returning in a more natural
  format on a Get.

 Tim.

 On Wed, Mar 21, 2018 at 8:19 AM, John Leiseboer < 
> wrote:
  Hi All,

  I agree with Felipe. The key format type is a permitted variation according to the KMIP Profiles Version 1.4 document, section 4.1.1, item 12 (Key Format Type).


4.1.1 Variable Items
  An implementation conformant to a Profile MAY vary the following values:

  …

  12. Key Format Type
  a. The key format type selected by the server when it creates managed objects

  Regards,
  John
From:


[mailto:

]
  On Behalf Of  Felipe Kendi
 Sent:  Wednesday, 21 March 2018 6:29 AM
To:  Mark Joseph <

>
Cc:

Subject:
Re: [kmip-interop-tech] Expected Key Format Type

  Hi Mark,

 From the spec (3.17 Digest):
 "The Key Format Type field in the Digest attribute indicates the format of the Managed Object from which the Digest Value was calculated."

 In the previous link (variable items):
 "12. KeyFormatType
          a. The key format type selected by the server when it creates managed objects
  "
  If the "Key Format Type" can vary when when the object is created, then I think the key format type used in the "Digest" varies too.

 Regards,

 On Tue, Mar 20, 2018 at 4:17 PM, Mark Joseph < 
> wrote:
 The issue is what the key format type is used in the digest.   Looking at the variable items like you provided I did not see that.   But I am getting old so maybe I missed it :-).

 Best,
 Mark Joseph
 P6R,  Inc
  408-205-0361
  
On Mar 20, 2018, at 12:01 PM, Felipe Kendi < 
> wrote:
  Hi everyone,
  We are in a dispute with P6R regarding the Key Format Type returned in the Digest Attribute (for KMIP 1.4).

 Kryptus Server returns the Key Format Type as Transparent (this was also our behavior in the last year Interop):

  <Attribute>
  <AttributeName type="TextString" value="Digest"/>
  <AttributeValue>
  <HashingAlgorithm type="Enumeration" value="SHA_256"/>
  <DigestValue type="ByteString" value="0533e51dd2ead671fa9eb9cd08baa7868fe94b42d579b4f0d3cfdacaefbe8688"/>

<KeyFormatType type="Enumeration" value="TransparentRSAPrivateKey"/>
  </AttributeValue>
  </Attribute>

 However, P6R expects the Key Format Type to be exactly like the in the test case:

 <Attribute>
     <AttributeName type="TextString" value="Digest"/>
     <AttributeValue>
         <HashingAlgorithm type="Enumeration" value="SHA_256"/>
         <DigestValue type="ByteString" value="8eb422ae2b006a05d3c8a542a28536735241b6dc1c37926bc8007bd6220d9230"/>
         <KeyFormatType type="Enumeration" value="PKCS_1"/>
     </AttributeValue>
 </Attribute>
  Kryptus' understanding is that the Key Format may vary from server to server, as stated in the "KMIP Protocol Profiles 1.4" document, section 4.1.1 (variable items):

http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431423
  P6R thinks different and has informed us that this year the tests were expected to check for the Key Format Type.

 Can you folks please tell me when this was decided? And if this is indeed the expected behavior, why the profiles document was not updated?

 Thank you,

--
Felipe Kendi
 Desenvolvedor de Software
 KRYPTUS EED S/A
 Trust in Cybersecurity

+55 19 3112 5000

www.kryptus.com

--
Felipe Kendi
 Desenvolvedor de Software
 KRYPTUS EED S/A
 Trust in Cybersecurity

+55 19 3112 5000

www.kryptus.com

 ______________________________________________________________________
 This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
 ______________________________________________________________________



 ______________________________________________________________________
 This email has been scanned by the Symantec Email Security.cloud service for QuintessenceLabs Pty Ltd.
 ______________________________________________________________________