kmip-interop-tech — archive

[kmip-interop-tech] Expected Key Format Type

From: Tim Hudson <[email protected]>
To: [email protected]
Date: Tue, 20 Mar 2018 22:25:00 -0000

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 < [email protected] > 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: [email protected] open.org [mailto: kmip-interop-tech@ lists.oasis-open.org ] On Behalf Of Felipe Kendi Sent: Wednesday, 21 March 2018 6:29 AM To: Mark Joseph < [email protected] > Cc: [email protected] open.org 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 < [email protected] > 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 [email protected] On Mar 20, 2018, at 12:01 PM, Felipe Kendi < [email protected] > 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 =" TextStrin g " value =" Digest " /> <AttributeValue> <HashingAlgorithm type =" Enumer ation " value =" SHA_256 " /> <DigestValue type =" ByteString " value =" 0533e51dd2ead671fa9eb9 cd08baa7868fe94b42d579b4f0d3cf dacaefbe8688 " /> <KeyFormatType type =" Enumerati on " value =" TransparentRSAPriva teKey " /> </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=" 8eb422ae2b006a05d3c8a542a28536 735241b6dc1c37926bc8007bd6220d 9230"/> <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. ______________________________ ______________________________ __________