[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] Questions about KMIP 1.4 test cases
On Sat, Feb 10, 2018 at 1:07 AM, Gabriel Mandaji <gabriel@kryptus.com> wrote:> TC-ECDSA-SIGN-1-14I have removed the spurious (extra) </KMIP> (for both 1.4 and 2.0).> TC-STREAM-MAC-1-14The HMAC outputs are all for a fixed key - so they are all a fixed value. The $MAC_DATA is in the correct place - and the verification should be performed against the fixed values.As all the values are fixed (defined deterministic output) I have updated the test case to have no use of $MAC_DATA (for both 1.4 and 2.0).> TC-STREAM-SIGNVFY-1-14The ValidityIndicator should be only on the final response - the specification does indeed need updating. We discussed this at the face to face I thought - but I will check with the specification co-editors to see what the state of that is.Both the 1.4 and 2.0 test cases only have the ValidityIndicator on the final response.I will upload the current versions of the 1.4 test cases (basically pending for errata1 if we decide to issue a formal errata) and the 2.0 test cases (next working draft versions) shortly.Thanks,Tim.On Sat, Feb 10, 2018 at 1:07 AM, Gabriel Mandaji <gabriel@kryptus.com> wrote:Hi all,After the recent document describing this year's KMIP Formal Interoperability Demonstration Event and Interoperability Tests, we have looked into some tests that we had not claimed last year but that we should support now.In doing so, we ran into issues with two tests: TC-ECDSA-SIGN-1-14.xml and TC-STREAM-MAC-1-14.xml.TC-ECDSA-SIGN-1-14.xml has a repeated closing '</KMIP>'. The following patch simply removes the extra closing tag.```patchdiff --git a/TC-ECDSA-SIGN-1-14.xml b/TC-ECDSA-SIGN-1-14.xmlindex 433c7f2..b883c9c 100755--- a/TC-ECDSA-SIGN-1-14.xml+++ b/TC-ECDSA-SIGN-1-14.xml@@ -489,5 +489,3 @@</ResponseMessage></KMIP>--</KMIP>```TC-STREAM-MAC-1-14.xml, on the other hand, fails to verify the data because out tester cannot find the $MAC_DATA indentifier. Looking at the test, seems like the identifier should have been part of the reponse to the MAC operation, as suggested on the following patch:```patchdiff --git a/TC-STREAM-MAC-1-14.xml b/TC-STREAM-MAC-1-14.xmlindex 01fbb7e..d8fd2be 100755--- a/TC-STREAM-MAC-1-14.xml+++ b/TC-STREAM-MAC-1-14.xml@@ -181,7 +181,7 @@<ResultStatus type="Enumeration" value="Success"/><ResponsePayload><UniqueIdentifier type="TextString" value="$UNIQUE_IDENTIFIER_0"/>- <MACData type="ByteString" value="c911e78196d64c30f631bb079ea37b97a95936d4da764d6a171df 030c895ecf9"/> + <MACData type="ByteString" value="$MAC_DATA"/></ResponsePayload></BatchItem></ResponseMessage>```Still on the TC-STREAM-MAC, the test expect a 'ValidityIndicator' only on the final response of multi-part MACVerify operations. However, the spec (at least up to version 1.4) still says that this field is always required. We had run into this same situation last year, while testing TC-STREAM-SIGNVFY-1-14, but it doesn't look like neither the test nor the spec has been updated (and, until now, seems like we had also forgot about this). How are we going to handle this behaviour in the RSA Interop tests?Best Regard,Gabriel Francisco Mandaji,Desenvolvedor de Software
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]