KMIP-interop-tech

Hi All,   Sorry about the late notice, but I will not be able to make tomorrow’s call.  Please feel free to toss me any questions via email and I’ll try to have them answered before the call.  Thanks for understanding.  Regards, Jane     Follow us on: LinkedIn:  http://linkd.in/OASISopen Twitter:  http://twitter.com/OASISopen Facebook:  http://facebook.com/oasis.open  

As previously indicated the hosting of the interop calls going forward is changing from Mathias @ IBM across to Tim @ Cryptsoft. The KMIP interop-tech calls will resume this week on the same schedule as the main TC calls (until we collectively decide otherwise) starting 30 minutes before the main call. The dial-in number for the calls going forward will also be the same as the main call number (thanks to Bob Griffin for offering to provide the dial-in facility) so remember to dial in using those details that Bob circulates each week individually to the main TC participants rather than the number we have used previously. If you don't have those details then drop me an email and I'll forward them. The tentative agenda for this weeks call: 1) lessons learnt from the RSA 2012 interop 2) result summary validation 3) test case gaps Thanks, Tim.

Hi All -- I'm planning to attend to review last week's RSA demo. Please feel free to provide any feedback. Thanks so much, Jane
Original Message----- From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Tuesday, March 06, 2012 10:13 PM To: kmip-interop-tech@lists.oasis-open.org Subject: [kmip-interop-tech] This weeks call As previously indicated the hosting of the interop calls going forward is changing from Mathias @ IBM across to Tim @ Cryptsoft. The KMIP interop-tech calls will resume this week on the same schedule as the main TC calls (until we collectively decide otherwise) starting 30 minutes before the main call. The dial-in number for the calls going forward will also be the same as the main call number (thanks to Bob Griffin for offering to provide the dial-in facility) so remember to dial in using those details that Bob circulates each week individually to the main TC participants rather than the number we have used previously. If you don't have those details then drop me an email and I'll forward them. The tentative agenda for this weeks call: 1) lessons learnt from the RSA 2012 interop 2) result summary validation 3) test case gaps Thanks, Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) result summary validation 2) attribute index discussion 3) test case gaps Thanks, Tim.

Just a reminder that as discussed on the last interop call there is no interop call this week. Thanks, Tim.

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) result summary validation 2) planning for next round of interop testing Thanks, Tim.

Based on the call last week we have a range of options (and interest) in the next round of interop testing. 1) mid-May [14th-25th] 2) mid-June [11th-22nd] 3) mid-July [9th-20th] I had assumed that the end-of-Q2 date of mid-June would not be desirable for most and that option 3) being six months from the last interop test was good timing. Could each vendor on the interop list provide their preferred date and respond either to myself or to the kmip-interop-tech list. We need to lock in a date which is workable for the majority of vendors preferably by next weeks call. The ground rules for interop will be the same as in January in that the results will be public to the KMIP TC and based on the test cases published for KMIP 1.0 and KMIP 1.1 and all vendors commit to testing against all other vendors within the schedule interop testing time frame. Any vendor with additional test cases to contribute should contact myself and/or Bob Lockhart or simply email the entire kmip-interop-tech group if you would prefer. Thanks, Tim.

All dates are fine with QuintessenceLabs. We have no preference. John Leiseboer >
Original Message----- > From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop- > tech@lists.oasis-open.org] On Behalf Of Tim Hudson > Sent: Friday, 27 April 2012 4:44 PM > To: kmip-interop-tech@lists.oasis-open.org > Subject: [kmip-interop-tech] scheduling the next interop test > > Based on the call last week we have a range of options (and interest) in > the next round of interop testing. > > 1) mid-May [14th-25th] > 2) mid-June [11th-22nd] > 3) mid-July [9th-20th] > > I had assumed that the end-of-Q2 date of mid-June would not be desirable > for most and that option 3) being six months from the last interop test > was good timing. > > Could each vendor on the interop list provide their preferred date and > respond either to myself or to the kmip-interop-tech list. We need to > lock in a date which is workable for the majority of vendors preferably > by next weeks call. > > The ground rules for interop will be the same as in January in that the > results will be public to the KMIP TC and based on the test cases > published for KMIP 1.0 and KMIP 1.1 and all vendors commit to testing > against all other vendors within the schedule interop testing time > frame. > > Any vendor with additional test cases to contribute should contact > myself and/or Bob Lockhart or simply email the entire kmip-interop-tech > group if you would prefer. > > Thanks, > Tim. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis- > open.org > For additional commands, e-mail: kmip-interop-tech-help@lists.oasis- > open.org >

Our vote is for option 2 or 3. In fact, it would be difficult for me to support option #1. Denis
Original Message----- From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Thursday, April 26, 2012 11:44 PM To: kmip-interop-tech@lists.oasis-open.org Subject: [kmip-interop-tech] scheduling the next interop test Based on the call last week we have a range of options (and interest) in the next round of interop testing. 1) mid-May [14th-25th] 2) mid-June [11th-22nd] 3) mid-July [9th-20th] I had assumed that the end-of-Q2 date of mid-June would not be desirable for most and that option 3) being six months from the last interop test was good timing. Could each vendor on the interop list provide their preferred date and respond either to myself or to the kmip-interop-tech list. We need to lock in a date which is workable for the majority of vendors preferably by next weeks call. The ground rules for interop will be the same as in January in that the results will be public to the KMIP TC and based on the test cases published for KMIP 1.0 and KMIP 1.1 and all vendors commit to testing against all other vendors within the schedule interop testing time frame. Any vendor with additional test cases to contribute should contact myself and/or Bob Lockhart or simply email the entire kmip-interop-tech group if you would prefer. Thanks, Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

The consensus from on-list and off-list email is option 3) mid-July [9th-20th]. Is there anyone who is unable to commit to interop during that time period? Thanks, Tim.

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) planning for KMIP 1.1 update testing 2) planning for next round of interop testing mid-July [9th-20th] 3) what is the correct return from a GET on a TEMPLATE 4) should it be possible to specify a Key Format Type on Create Key Pair to set the 'default' format a GET on the generated keys will return 5) HTTPS proposal Thanks, Tim.

What is the "value" of a Template - i.e. what is returned for a GET on a template. For the following example - register of a template: OBJECT_TYPE:enum:0x00000006:TEMPLATE TEMPLATE_ATTRIBUTE:stru:4 END_STRUCTURE:stru:4 TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 This is what I think is "correct" - call this VENDOR-A: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-B: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Object Type ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Unique Identifier ATTRIBUTE_VALUE:text:e176df8d-16de-4bed-8031-0ef7932f8740 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-C: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Object Type ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_INDEX:int4:0x00000000 ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Initial Date ATTRIBUTE_VALUE:date:0x000000004f967840:Tue Apr 24 19:54:08 2012 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 There are other variations on the theme - but the general concept should be clear. We can argue whether or not the Name belongs in the template - and my argument for that is rather simple - it isn't there for other objects - they are all attributes - and there is no way a template should be treated differently. The concept of the "value" of the template containing attributes other than those which form part of what the template contributes to objects created with reference to the template is (in my view at least) simply unsupportable. Views? Tim.

I understand the difference between Get and Get Attributes on a Template just as Tim writes. In my server, a Get on a Template object returns those attributes applied by the template. I also include any attributes implicitly created for the object. I'll give an example here and please let me know if this is incorrect: First I create the template with just a few attributes, and a few implicitly added attributes are sent back by the server in the Template Attribute in the Response Message: <BatchItem type="Structure"> <Operation type="Enumeration" value="Create" /> <RequestPayload type="Structure"> <ObjectType type="Enumeration" value="0x00000006" /> <TemplateAttribute type="Structure"> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Algorithm" /> <AttributeValue type="Enumeration" value="0x00000003" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Length" /> <AttributeValue type="Integer" value="256" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Name" /> <AttributeValue type="Structure"> <NameValue type="TextString" value="Template-1" /> <NameType type="Enumeration" value="0x00000001" /> </AttributeValue> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Contact Information" /> <AttributeValue type="TextString" value="Jim Flood" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="x-Security Group" /> <AttributeValue type="TextString" value="Portland" /> </Attribute> </TemplateAttribute> </RequestPayload> </BatchItem> <BatchItem type="Structure"> <Operation type="Enumeration" value="Create" /> <ResultStatus type="Enumeration" value="Success" /> <ResponsePayload type="Structure"> <UniqueIdentifier type="TextString" value="YHvy/gbcZUtpx1pQSXjMlw==" /> <TemplateAttribute type="Structure"> <Attribute type="Structure"> <AttributeName type="TextString" value="Operation Policy Name" /> <AttributeValue type="TextString" value="default" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Usage Mask" /> <AttributeValue type="Integer" value="12" /> </Attribute> </TemplateAttribute> </ResponsePayload> </BatchItem> Note that Operation Policy Name and Cryptographic Usage Mask are now also part of this template, i.e. they will be applied to any object created with this template. If I issue a Get Attributes on this object, I see the full list of attributes: <BatchItem type="Structure"> <Operation type="Enumeration" value="GetAttributes" /> <RequestPayload type="Structure" /> </BatchItem> <BatchItem type="Structure"> <Operation type="Enumeration" value="GetAttributes" /> <ResultStatus type="Enumeration" value="Success" /> <ResponsePayload type="Structure"> <UniqueIdentifier type="TextString" value="YHvy/gbcZUtpx1pQSXjMlw==" /> <Attribute type="Structure"> <AttributeName type="TextString" value="Contact Information" /> <AttributeValue type="TextString" value="Jim Flood" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Algorithm" /> <AttributeValue type="Enumeration" value="0x00000003" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Length" /> <AttributeValue type="Integer" value="256" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Usage Mask" /> <AttributeValue type="Integer" value="12" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Initial Date" /> <AttributeValue type="DateTime" value="2012-05-08 18:06:15Z" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Last Change Date" /> <AttributeValue type="DateTime" value="2012-05-08 18:06:15Z" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Name" /> <AttributeIndex type="Integer" value="0" /> <AttributeValue type="Structure"> <NameValue type="TextString" value="Template-1" /> <NameType type="Enumeration" value="0x00000001" /> </AttributeValue> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Object Type" /> <AttributeValue type="Enumeration" value="0x00000006" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Operation Policy Name" /> <AttributeValue type="TextString" value="default" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="State" /> <AttributeValue type="Enumeration" value="0x00000002" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Unique Identifier" /> <AttributeValue type="TextString" value="YHvy/gbcZUtpx1pQSXjMlw==" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="x-Security Group" /> <AttributeIndex type="Integer" value="0" /> <AttributeValue type="TextString" value="Portland" /> </Attribute> </ResponsePayload> </BatchItem> But if I issue a Get on the object, I only see those attributes that would be applied to an object created with this Template: <BatchItem type="Structure"> <Operation type="Enumeration" value="Get" /> <RequestPayload type="Structure" /> </BatchItem> <BatchItem type="Structure"> <Operation type="Enumeration" value="Get" /> <ResultStatus type="Enumeration" value="Success" /> <ResponsePayload type="Structure"> <UniqueIdentifier type="TextString" value="YHvy/gbcZUtpx1pQSXjMlw==" /> <Template type="Structure"> <Attribute type="Structure"> <AttributeName type="TextString" value="Contact Information" /> <AttributeValue type="TextString" value="Jim Flood" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Algorithm" /> <AttributeValue type="Enumeration" value="0x00000003" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Length" /> <AttributeValue type="Integer" value="256" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Cryptographic Usage Mask" /> <AttributeValue type="Integer" value="12" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="Operation Policy Name" /> <AttributeValue type="TextString" value="default" /> </Attribute> <Attribute type="Structure"> <AttributeName type="TextString" value="x-Security Group" /> <AttributeIndex type="Integer" value="0" /> <AttributeValue type="TextString" value="Portland" /> </Attribute> </Template> </ResponsePayload> </BatchItem> I am interested in any feedback on this example, since I have not yet performed any interoperability testing. Jim Flood On 5/3/2012 6:59 AM, Tim Hudson wrote: What is the "value" of a Template - i.e. what is returned for a GET on a template. For the following example - register of a template: OBJECT_TYPE:enum:0x00000006:TEMPLATE TEMPLATE_ATTRIBUTE:stru:4 END_STRUCTURE:stru:4 TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 This is what I think is "correct" - call this VENDOR-A: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-B: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Usage Mask ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Object Type ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Unique Identifier ATTRIBUTE_VALUE:text:e176df8d-16de-4bed-8031-0ef7932f8740 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-C: TEMPLATE:stru:4 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Object Type ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Algorithm ATTRIBUTE_VALUE:enum:0x00000003:AES END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Cryptographic Length ATTRIBUTE_VALUE:int4:0x00000100 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Name ATTRIBUTE_INDEX:int4:0x00000000 ATTRIBUTE_VALUE:stru:6 NAME_VALUE:text:Template1 NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING END_STRUCTURE:stru:6 END_STRUCTURE:stru:5 ATTRIBUTE:stru:5 ATTRIBUTE_NAME:text:Initial Date ATTRIBUTE_VALUE:date:0x000000004f967840:Tue Apr 24 19:54:08 2012 END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 There are other variations on the theme - but the general concept should be clear. We can argue whether or not the Name belongs in the template - and my argument for that is rather simple - it isn't there for other objects - they are all attributes - and there is no way a template should be treated differently. The concept of the "value" of the template containing attributes other than those which form part of what the template contributes to objects created with reference to the template is (in my view at least) simply unsupportable. Views? Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

On page 15 of kmip-spec-v1.1-csprd01 it reads, "The Attribute Index SHALL always be specified. To indicate that the receiving server SHALL ignore the specified Attribute Index, the Attribute Index SHALL be set to -1." Is this only used for new attributes, for example in a Create request? Or can it be used for existing attributes, for example on a Delete Attribute or Modify Attribute request, and if so, only for single-instance attributes, or also for multiple instance attributes and in that case referring to index 0? It also reads, repeating one sentence from above for emphasis, "Attributes that have a single instance have an Attribute Index of 0, which is assumed *if the Attribute Index is not specified*. The Attribute Index *SHALL always be specified* [emphasis added]". Don't those two sentences contradict each other? My understanding is that: * For new attributes, a 1.0 client is *not* expected to send an index, but a 1.1 client *is* expected to send index -1 (then, is it an error if a 1.1 client does not send index -1?) * For existing attributes specified by the *client*, e.g. in a delete attribute or modify attribute request, a 1.0 client is not expected to send an index for single instance attributes (but it is acceptable to send index 0), and *may* send an index for multiple instance attributes (where index 0 is assumed if the index is not sent.) A 1.1 client *is* expected to send an index, sending 0 or -1 for a single instance attribute, and any index other than -1 for a multiple index attribute. * For any attribute sent by a 1.1 server, when sending to a 1.0 client, attribute indexes can be omitted for single instance attributes. When sending to a 1.1 client, the 1.1 server sends index -1 for any single instance attributes, and an index >= 0 for any multiple instance attribute. Is this correct? Regards, Jim Flood

Tim, I am in sympathy with the goal of getting on the same page regarding the behavior of GET.  The spec is now overly terse regarding GET behavior for all objects, and is generally silent about how operations on TEMPLATEs behave. The original intent of GET was that it would retrieve the body of a cryptographic object.  So for SYMMETRIC_KEY, it would mean the key material.  But TEMPLATE is not a cryptographic object, it's just a managed object.  What would it mean to retrieve its "body"?  It doesn't have one, at least not in the sense that cryptographic objects do.  And I think that's where the confusion arises.  Perhaps it would be useful to introduce the idea of TRANSITIVE ATTRIBUTEs to the discussion.  A TRANSITIVE ATTRIBUTE would be one that transfers from a TEMPLATE to the objects to which the TEMPLATE is applied.  I think this discussion is heading in the direction of a behavior of "GET on a TEMPLATE SHOULD return only the TRANSITIVE ATTRIBUTEs contained in that ATTRIBUTE."  Or something like that.  And I'm in favor of such a clarification. If we are going to head in that direction, we would be amiss if we did not also clarify what is returned from some additional operations on TEMPLATEs.  I'm thinking of operations like GET ATTRIBUTE LIST and GET ATTRIBUTES (with no attribute names specified).  If we go with the above proposal on GET, I think GET ATTRIBUTE LIST should return the names of ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE), and that GET ATTRIBUTES(no names) should similarly return ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE). As an example, the list of INTRANSITIVE attributes would include things like the NAME of the TEMPLATE and its INITIAL DATE.  The list of TRANSITIVE attributes would include things like CRYPTOGRAPHIC ALGORITHM and CRYPTOGRAPHIC LENGTH. I can flesh this out a bit more, if this meets with general agreement. Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         kmip-interop-tech@lists.oasis-open.org Date:         05/03/2012 09:00 AM Subject:         [kmip-interop-tech] Templates Sent by:         <kmip-interop-tech@lists.oasis-open.org> What is the "value" of a Template - i.e. what is returned for a GET on a template. For the following example - register of a template: OBJECT_TYPE:enum:0x00000006:TEMPLATE TEMPLATE_ATTRIBUTE:stru:4 END_STRUCTURE:stru:4 TEMPLATE:stru:4  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Algorithm    ATTRIBUTE_VALUE:enum:0x00000003  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Length    ATTRIBUTE_VALUE:int4:0x00000100  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Usage Mask    ATTRIBUTE_VALUE:int4:0x0000000c  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Name    ATTRIBUTE_VALUE:stru:6      NAME_VALUE:text:Template1      NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING    END_STRUCTURE:stru:6  END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 This is what I think is "correct" - call this VENDOR-A:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Usage Mask          ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-B:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Usage Mask          ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Object Type          ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Name          ATTRIBUTE_VALUE:stru:6            NAME_VALUE:text:Template1            NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING          END_STRUCTURE:stru:6        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Unique Identifier          ATTRIBUTE_VALUE:text:e176df8d-16de-4bed-8031-0ef7932f8740        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-C:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Object Type          ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Name          ATTRIBUTE_INDEX:int4:0x00000000          ATTRIBUTE_VALUE:stru:6            NAME_VALUE:text:Template1            NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING          END_STRUCTURE:stru:6        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Initial Date          ATTRIBUTE_VALUE:date:0x000000004f967840:Tue Apr 24 19:54:08 2012        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 There are other variations on the theme - but the general concept should be clear. We can argue whether or not the Name belongs in the template - and my argument for that is rather simple - it isn't there for other objects - they are all attributes - and there is no way a template should be treated differently. The concept of the "value" of the template containing attributes other than those which form part of what the template contributes to objects created with reference to the template is (in my view at least) simply unsupportable. Views? Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

I have a related question on transitive attributes : A key can be created with a Template Attribute that specifies multiple templates, as well as individual attributes, and can include implicitly-added attributes (according to server policy.) A Re-Key can also specify template and attributes, and also includes any carry-over attributes from the source key managed object. Of these transitive attributes, as I interpret the spec, the last single-instance attribute found in the resolution of the request payload (i.e. after searching all templates and then looking at all individual attributes in the Template Attribute), is the one used. For example, if one or more templates include Contact Information, and then the Template Attribute includes one or more Contact Information attributes, since this is a single-instance attribute, the very last one found in the request payload is the one used in the new object. This has precedence over carry-over attributes from a source object on a Re-Key, too. Of these attributes which are multiple-instance, all instances of the attributes collect and they are *all* added to the created object. If several templates each have a particular multiple-instance custom attribute x-Something , for example, and multiple x-Something attributes are also included in the request Template Attribute, and the source of a Re-Key has one or more x-Something attributes, then the resulting new object will have all of those added to it. That is, for single-instance attributes that are transitive, the last one found in the request payload (which includes templates first, and next, immediate attributes) is the one given to the new object, and any previous ones are ignored, without error. For multiple-instance attributes, all of the attributes in the request payload and in the source object, if any, are included in the new object. I guess this is not an interpretation of the spec as written, but more how I imagine how it should be, if the spec described this in detail. Is this a reasonable assumption for how the server should operate? Regards, Jim Flood On 5/16/2012 4:07 AM, Bruce Rich wrote: Tim, I am in sympathy with the goal of getting on the same page regarding the behavior of GET.  The spec is now overly terse regarding GET behavior for all objects, and is generally silent about how operations on TEMPLATEs behave. The original intent of GET was that it would retrieve the body of a cryptographic object.  So for SYMMETRIC_KEY, it would mean the key material.  But TEMPLATE is not a cryptographic object, it's just a managed object.  What would it mean to retrieve its body ?  It doesn't have one, at least not in the sense that cryptographic objects do.  And I think that's where the confusion arises.  Perhaps it would be useful to introduce the idea of TRANSITIVE ATTRIBUTEs to the discussion.  A TRANSITIVE ATTRIBUTE would be one that transfers from a TEMPLATE to the objects to which the TEMPLATE is applied.  I think this discussion is heading in the direction of a behavior of GET on a TEMPLATE SHOULD return only the TRANSITIVE ATTRIBUTEs contained in that ATTRIBUTE.  Or something like that.  And I'm in favor of such a clarification. If we are going to head in that direction, we would be amiss if we did not also clarify what is returned from some additional operations on TEMPLATEs.  I'm thinking of operations like GET ATTRIBUTE LIST and GET ATTRIBUTES (with no attribute names specified).  If we go with the above proposal on GET, I think GET ATTRIBUTE LIST should return the names of ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE), and that GET ATTRIBUTES(no names) should similarly return ALL attributes associated with the TEMPLATE (both TRANSITIVE and INTRANSITIVE). As an example, the list of INTRANSITIVE attributes would include things like the NAME of the TEMPLATE and its INITIAL DATE.  The list of TRANSITIVE attributes would include things like CRYPTOGRAPHIC ALGORITHM and CRYPTOGRAPHIC LENGTH. I can flesh this out a bit more, if this meets with general agreement. Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         kmip-interop-tech@lists.oasis-open.org Date:         05/03/2012 09:00 AM Subject:         [kmip-interop-tech] Templates Sent by:         <kmip-interop-tech@lists.oasis-open.org> What is the value of a Template - i.e. what is returned for a GET on a template. For the following example - register of a template: OBJECT_TYPE:enum:0x00000006:TEMPLATE TEMPLATE_ATTRIBUTE:stru:4 END_STRUCTURE:stru:4 TEMPLATE:stru:4  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Algorithm    ATTRIBUTE_VALUE:enum:0x00000003  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Length    ATTRIBUTE_VALUE:int4:0x00000100  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Cryptographic Usage Mask    ATTRIBUTE_VALUE:int4:0x0000000c  END_STRUCTURE:stru:5  ATTRIBUTE:stru:5    ATTRIBUTE_NAME:text:Name    ATTRIBUTE_VALUE:stru:6      NAME_VALUE:text:Template1      NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING    END_STRUCTURE:stru:6  END_STRUCTURE:stru:5 END_STRUCTURE:stru:4 This is what I think is correct - call this VENDOR-A:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Usage Mask          ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-B:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Usage Mask          ATTRIBUTE_VALUE:int4:0x0000000c:DECRYPT ENCRYPT        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Object Type          ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Name          ATTRIBUTE_VALUE:stru:6            NAME_VALUE:text:Template1            NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING          END_STRUCTURE:stru:6        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Unique Identifier          ATTRIBUTE_VALUE:text:e176df8d-16de-4bed-8031-0ef7932f8740        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 Here is an example of something I consider not correct - call this VENDOR-C:      TEMPLATE:stru:4        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Object Type          ATTRIBUTE_VALUE:enum:0x00000006:TEMPLATE        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Algorithm          ATTRIBUTE_VALUE:enum:0x00000003:AES        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Cryptographic Length          ATTRIBUTE_VALUE:int4:0x00000100        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Name          ATTRIBUTE_INDEX:int4:0x00000000          ATTRIBUTE_VALUE:stru:6            NAME_VALUE:text:Template1            NAME_TYPE:enum:0x00000001:UNINTERPRETED_TEXT_STRING          END_STRUCTURE:stru:6        END_STRUCTURE:stru:5        ATTRIBUTE:stru:5          ATTRIBUTE_NAME:text:Initial Date          ATTRIBUTE_VALUE:date:0x000000004f967840:Tue Apr 24 19:54:08 2012        END_STRUCTURE:stru:5      END_STRUCTURE:stru:4 There are other variations on the theme - but the general concept should be clear. We can argue whether or not the Name belongs in the template - and my argument for that is rather simple - it isn't there for other objects - they are all attributes - and there is no way a template should be treated differently. The concept of the value of the template containing attributes other than those which form part of what the template contributes to objects created with reference to the template is (in my view at least) simply unsupportable. Views? Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

Now that a couple of outstanding items have been confirmed the consolidated test results spreadsheet from the face to face is attached. Please confirm these results match your respective views of the status as the results had to be correlated between different vendor reports to get a summary view where there were conflicting reports on the status of a test. As always, any errors in the spreadsheet should either be noted to myself and Mathias or alternatively to the kmip-interop-tech mailing list. The graphs from the face to face are in the "Charts" sheet in the spreadsheet. Thanks, Tim. Attachment: RSA-2012-InteropResults-MASTER_v1.0c.xls Description: MS-Excel spreadsheet

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) what is the correct return from a GET on a TEMPLATE 2) planning for next round of interop testing mid-July [9th-20th] 3) feedback on the Jan interop summary spreadsheet. 4) HTTPS proposal Thanks, Tim.

Hi Folks, I'm planning to join today's call to discuss future interop locations. RSA 2013 is already in our pipeline. It would be good to poll the group to see if there might be interest in holding one at an upcoming fall event: Gartner Catalyst 20-23 August San Diego http://www.gartner.com/technology/summits/na/catalyst/ Cloud Connect 10-13 September Chicago http://www.cloudconnectevent.com/chicago/ International Cloud Symposium 10-12 October Washington DC area http://events.oasis-open.org/home/cloud/2011/
Original Message----- From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of Tim Hudson Sent: Thursday, May 17, 2012 7:06 AM To: kmip-interop-tech@lists.oasis-open.org Subject: [kmip-interop-tech] This weeks call The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) what is the correct return from a GET on a TEMPLATE 2) planning for next round of interop testing mid-July [9th-20th] 3) feedback on the Jan interop summary spreadsheet. 4) HTTPS proposal Thanks, Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

The CA and server certificate for the C Server has been updated (it expires today). The updated (resigned) certificates are below. The interop server is set to ignore the expiry dates on incoming client certificates so your existing credentials should continue to operate correctly. If you need updated credentials or if have any issues with connecting then drop me a note. For reference the Cryptsoft C server supports all KMIP 1.0 and KMIP 1.1 test cases except 15.3 (round robin group handling). Thanks, Tim. CA.pem -----BEGIN CERTIFICATE----- MIIDkDCCAvmgAwIBAgIJAN/GfHIFQWnvMA0GCSqGSIb3DQEBBQUAMIGNMQswCQYD VQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx GjAYBgNVBAoTEUNyeXB0c29mdCBQdHkgTHRkMRgwFgYDVQQLEw9LTUlQIEludGVy b3AgQ0ExIDAeBgkqhkiG9w0BCQEWEXRqaEBjcnlwdHNvZnQuY29tMB4XDTEwMDUy MTA2MjgwMVoXDTIyMDUxOTA4NDkxOVowgY0xCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTEaMBgGA1UEChMRQ3J5cHRz b2Z0IFB0eSBMdGQxGDAWBgNVBAsTD0tNSVAgSW50ZXJvcCBDQTEgMB4GCSqGSIb3 DQEJARYRdGpoQGNyeXB0c29mdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANTCi5G2zUsmVGiwoAnFFyTeq3u9WS4brm6kE8VHdUnGYy8s4BqZlQhidq1N yrZpJaVg9g6/wzmWLOm/ZmGO4mHD8SM3SoKEJsLLtdTftJazK/fca03QI5ngLjvD jWYnDI1W+LJNhNz/vDOpeRCSIdh/HX5BSpkWKcmtFixJBY1lAgMBAAGjgfUwgfIw HQYDVR0OBBYEFNKF7uf28JMj4gFMU3fJNaMGXSksMIHCBgNVHSMEgbowgbeAFNKF 7uf28JMj4gFMU3fJNaMGXSksoYGTpIGQMIGNMQswCQYDVQQGEwJBVTETMBEGA1UE CBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUxGjAYBgNVBAoTEUNyeXB0 c29mdCBQdHkgTHRkMRgwFgYDVQQLEw9LTUlQIEludGVyb3AgQ0ExIDAeBgkqhkiG 9w0BCQEWEXRqaEBjcnlwdHNvZnQuY29tggkA38Z8cgVBae8wDAYDVR0TBAUwAwEB /zANBgkqhkiG9w0BAQUFAAOBgQA1vbYxUI7iDMavWpKY5VeopMrPVQ0aK8/DjF2t QMv5mOeflcqHFm8uFHjZoszM6wj/jx6wBeC1lvBgBGSH5wap86D6hjB0HtqTxOzW 9Pdxh4sD+KrEFKyi06VM8NsJti/1PeL+LNyXjux2rXqWiE7b4OaClQHhDurB7Pn6 jFWz/g== -----END CERTIFICATE----- server.pem -----BEGIN CERTIFICATE----- MIIDLTCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADCBjTELMAkGA1UEBhMCQVUx EzARBgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMRowGAYDVQQK ExFDcnlwdHNvZnQgUHR5IEx0ZDEYMBYGA1UECxMPS01JUCBJbnRlcm9wIENBMSAw HgYJKoZIhvcNAQkBFhF0amhAY3J5cHRzb2Z0LmNvbTAeFw0xMDA1MjEwNjI4MTRa Fw0xNzA1MjAwOTAxNTFaMIGtMQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5z bGFuZDERMA8GA1UEBxMIQnJpc2JhbmUxGjAYBgNVBAoTEUNyeXB0c29mdCBQdHkg THRkMRgwFgYDVQQLEw9LTUlQIEludGVyb3AgQ0ExHjAcBgNVBAMTFWludGVyb3Au Y3J5cHRzb2Z0LmNvbTEgMB4GCSqGSIb3DQEJARYRdGpoQGNyeXB0c29mdC5jb20w gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMLt5Al3Nam/pFvNNFp7117GqtpE U5hYz9xq8O7Pcpc49sKv1wTgqE+qN9cFTE+dDRVMFtLVbWon87Ahf/681MrIuEBt QdVzlVNSwnpzWxBeePBQhP/NWhUygSfSozBg3v0jjULOV1Ye+k+ERqdiKaXWP/rn q5+UdM9WMgjrrckdAgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8W HU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBTFxiJy5hIV ExQNtOYb6O81Xa7tPjAfBgNVHSMEGDAWgBTShe7n9vCTI+IBTFN3yTWjBl0pLDAN BgkqhkiG9w0BAQUFAAOBgQBoiz71NAS9vbTSxrl4NMTPBwAxTJPLZV1YMa8nwXX4 bkV3bwp4UY9EHxiQ9UzNyzwD+Gd5QOOQI6mN6s/hBCqiLzOxJvb1oS1Gf4AX0SEj hkmMbhFEYkQPdQ7FyDB/9tLZoZ26APh+D+FXoENsSRfawPnO1NQqpb2od2X38ScK IQ== -----END CERTIFICATE-----

As there are no specific agenda items for this week I've cancelled the interop call for this week. As always please send suggested agenda items to either myself or the list in advance. The informal interop testing is continuing between vendors with various servers updated and I an tracking the status where I'm aware of the testing results. The Cryptsoft C, IBM Development, and Quintessence Labs servers are all handling the current (updated) KMIP 1.1 draft (as previously reported by each vendor to the list and on the interop calls). It is likely that on the main call Bob will again ask for the status of vendors prepared to make statements of use for KMIP 1.1 and I'd suggest based on previous statements of use that multi-vendor interoperability testing is one of the prerequisites for making such a statement. The status from the last meeting was that we are still on target for the next round of interop testing mid-July [9th-20th] Thanks, Tim.

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this weeks call: 1) statements of use details 2) planning for next round of interop testing mid-July [9th-20th] 3) other items Thanks, Tim.

Attached is a spreadsheet which contains the list of profiles and the first 4 of the 42 profiles on separate sheets. The number of profiles and the specific requirements against each profile in KMIP 1.1 is substantially different to KMIP 1.0 Which profiles we plan to perform interoperability testing on and how to go about that testing is on the agenda for this weeks interop call. Thanks, Tim. Attachment: kmip-profiles-v1.1-draft1.xls Description: MS-Excel spreadsheet

The Cryptsoft C Server has been updated to include additional support for the X_509 key format type and to support the PEM certificate request type as required in the conformance sections in various KMIP 1.1 profiles. For PEM format the server accepts a range of different inputs given that nothing is actually stated in the specification as to what is expected. Thanks, Tim.

Attached is a draft Cryptsoft Statement of Use for KMIP 1.1 for review. Could each vendor mentioned in the statement of use confirm that the statements being made match their understanding particularly the following two statements: The Cryptsoft KMIP client has successfully been used in interoperation with the Cryptsoft KMIP server and with KMIP server implementations by IBM, SafeNet, Thales and Quintessence Labs. KMIP client implementations by HP, IBM, NetApp, SafeNet, Thales and Quintessence Labs have successfully been used in interoperation with the Cryptsoft KMIP server. One item that isn't clear is whether or not listing the testing that used KMIP 1.0 is appropriate for a statement of use (although the statement remains strictly correct in its current wording). The conformance clauses in the profiles are something that you will each need to check carefully to be able to make a statement of use. We had to implement a couple of additional capabilities in the Cryptsoft servers to be able to meet the conformance clauses of a number of the profiles as the set of test cases we have currently do not cover all the conformance clauses across all the profiles. Separately if any other vendor is interesting in testing TLSv1.2 interoperability support please let me know as we have not enabled TLSv1.2 on the interop servers as yet (those are separate systems). Thanks, Tim. Attachment: SOU-Cryptsoft-19-Jun-2012-draft1.pdf Description: Adobe PDF document

QuintessenceLabs' draft SOU is attached. John >
Original Message----- > From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop- > tech@lists.oasis-open.org] On Behalf Of Tim Hudson > Sent: Tuesday, 19 June 2012 8:26 PM > To: kmip-interop-tech@lists.oasis-open.org > Subject: [kmip-interop-tech] Statement of Use > > Attached is a draft Cryptsoft Statement of Use for KMIP 1.1 for review. > > Could each vendor mentioned in the statement of use confirm that the > statements being made match their understanding particularly the > following two statements: > > The Cryptsoft KMIP client has successfully been used in interoperation > with the Cryptsoft KMIP server and with KMIP server implementations by > IBM, SafeNet, Thales and Quintessence Labs. > > KMIP client implementations by HP, IBM, NetApp, SafeNet, Thales and > Quintessence Labs have successfully been used in interoperation with the > Cryptsoft KMIP server. > > One item that isn't clear is whether or not listing the testing that > used KMIP 1.0 is appropriate for a statement of use (although the > statement remains strictly correct in its current wording). > > The conformance clauses in the profiles are something that you will each > need to check carefully to be able to make a statement of use. We had to > implement a couple of additional capabilities in the Cryptsoft servers > to be able to meet the conformance clauses of a number of the profiles > as the set of test cases we have currently do not cover all the > conformance clauses across all the profiles. > > Separately if any other vendor is interesting in testing TLSv1.2 > interoperability support please let me know as we have not enabled > TLSv1.2 on the interop servers as yet (those are separate systems). > > Thanks, > Tim. Attachment: QLABS-SOU.pdf Description: QLABS-SOU.pdf

Attached is the IBM draft SoU. Regards, Mathias From: John Leiseboer <jl@quintessencelabs.com> To: "kmip-interop-tech@lists.oasis-open.org" <kmip-interop-tech@lists.oasis-open.org> Date: 25.06.2012 02:40 Subject: RE: [kmip-interop-tech] Statement of Use Sent by: <kmip-interop-tech@lists.oasis-open.org> QuintessenceLabs' draft SOU is attached. John >
Original Message----- > From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop- > tech@lists.oasis-open.org] On Behalf Of Tim Hudson > Sent: Tuesday, 19 June 2012 8:26 PM > To: kmip-interop-tech@lists.oasis-open.org > Subject: [kmip-interop-tech] Statement of Use > > Attached is a draft Cryptsoft Statement of Use for KMIP 1.1 for review. > > Could each vendor mentioned in the statement of use confirm that the > statements being made match their understanding particularly the > following two statements: > > The Cryptsoft KMIP client has successfully been used in interoperation > with the Cryptsoft KMIP server and with KMIP server implementations by > IBM, SafeNet, Thales and Quintessence Labs. > > KMIP client implementations by HP, IBM, NetApp, SafeNet, Thales and > Quintessence Labs have successfully been used in interoperation with the > Cryptsoft KMIP server. > > One item that isn't clear is whether or not listing the testing that > used KMIP 1.0 is appropriate for a statement of use (although the > statement remains strictly correct in its current wording). > > The conformance clauses in the profiles are something that you will each > need to check carefully to be able to make a statement of use. We had to > implement a couple of additional capabilities in the Cryptsoft servers > to be able to meet the conformance clauses of a number of the profiles > as the set of test cases we have currently do not cover all the > conformance clauses across all the profiles. > > Separately if any other vendor is interesting in testing TLSv1.2 > interoperability support please let me know as we have not enabled > TLSv1.2 on the interop servers as yet (those are separate systems). > > Thanks, > Tim. Attachment: IBM_KMIP_v1.1_Statement_of_Use-draft-20120808.pdf Description: Binary data

Updated QuintessenceLabs Statement of Use is attached. Regards, John ----------------------------------------------------------------------- John Leiseboer QuintessenceLabs Pty Ltd Chief Technology Officer Suite 23, Physics Building #38 Phone: +61 7 5494 9291 (Qld) Science Road Phone: +61 2 6125 9498 (ACT) Australian National University Mobile: +61 409 487 510 Acton ACT 0200 Fax: +61 2 6125 7180 AUSTRALIA Email: jl@quintessencelabs.com www.quintessencelabs.com ----------------------------------------------------------------------- Attachment: QLABS-SOU.pdf Description: QLABS-SOU.pdf

Do we have the final URL web links for the 1.1 documents? I was told to hold off on submission until they posted them by Subhash. Thanks! Bob L.
Original Message----- From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of John Leiseboer Sent: Sunday, August 12, 2012 6:09 PM To: kmip-interop-tech@lists.oasis-open.org Subject: RE: [kmip-interop-tech] Statement of Use Updated QuintessenceLabs Statement of Use is attached. Regards, John ----------------------------------------------------------------------- John Leiseboer QuintessenceLabs Pty Ltd Chief Technology Officer Suite 23, Physics Building #38 Phone: +61 7 5494 9291 (Qld) Science Road Phone: +61 2 6125 9498 (ACT) Australian National University Mobile: +61 409 487 510 Acton ACT 0200 Fax: +61 2 6125 7180 AUSTRALIA Email: jl@quintessencelabs.com www.quintessencelabs.com -----------------------------------------------------------------------

Not yet. Bob in fact sent another reminder to TC admin but it looks like they are busy. Thanks, -Subhash. On 8/13/12 2:19 PM, "Lockhart, Robert" <Robert.Lockhart@thalesesec.com> wrote: >Do we have the final URL web links for the 1.1 documents? I was told to >hold off on submission until they posted them by Subhash. > >Thanks! > >Bob L. > >
Original Message----- >From: kmip-interop-tech@lists.oasis-open.org >[ mailto:kmip-interop-tech@lists.oasis-open.org ] On Behalf Of John >Leiseboer >Sent: Sunday, August 12, 2012 6:09 PM >To: kmip-interop-tech@lists.oasis-open.org >Subject: RE: [kmip-interop-tech] Statement of Use > >Updated QuintessenceLabs Statement of Use is attached. > >Regards, >John > >----------------------------------------------------------------------- >John Leiseboer QuintessenceLabs Pty Ltd >Chief Technology Officer Suite 23, Physics Building #38 >Phone: +61 7 5494 9291 (Qld) Science Road >Phone: +61 2 6125 9498 (ACT) Australian National University >Mobile: +61 409 487 510 Acton ACT 0200 >Fax: +61 2 6125 7180 AUSTRALIA >Email: jl@quintessencelabs.com www.quintessencelabs.com >----------------------------------------------------------------------- > > > >

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this week: 1) Statements of Use 2) planning for next round of interop testing mid-July [9th-20th] 3) HTTPS proposal 4) Any status update on GET for TEMPLATE Thanks, Tim.

I've received a couple of requests to see if we can move the interop testing back a week. That works I think better for the preparation from our point of view too so could those participating please let me know in the next day or so whether or not moving the interop testing from 9-20th July to 16-27th July would be an issue. As always the Cryptsoft interop servers remain available for testing all the time and if you need credentials for access and do not already have them please contact me so we can arrange those. Thanks, Tim.

New proposed dates are good for QuintessenceLabs. John >
Original Message----- > From: kmip-interop-tech@lists.oasis-open.org [ mailto:kmip-interop- > tech@lists.oasis-open.org] On Behalf Of Tim Hudson > Sent: Friday, 29 June 2012 9:43 AM > To: kmip-interop-tech@lists.oasis-open.org > Subject: [kmip-interop-tech] July 2012 interop schedule > > I've received a couple of requests to see if we can move the interop > testing back a week. > > That works I think better for the preparation from our point of view too > so could those participating please let me know in the next day or so > whether or not moving the interop testing from 9-20th July to 16-27th > July would be an issue. > > As always the Cryptsoft interop servers remain available for testing all > the time and if you need credentials for access and do not already have > them please contact me so we can arrange those. > > Thanks, > Tim. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis- > open.org > For additional commands, e-mail: kmip-interop-tech-help@lists.oasis- > open.org >

New dates are good for us so count Thales in if you already hadn't. Bob L. Robert A. (Bob) Lockhart Chief Solution Architect - Key Management THALES e-Security, Inc. ________________________________________ From: kmip-interop-tech@lists.oasis-open.org [kmip-interop-tech@lists.oasis-open.org] On Behalf Of Tim Hudson [tjh@cryptsoft.com] Sent: Thursday, June 28, 2012 16:42 To: kmip-interop-tech@lists.oasis-open.org Subject: [kmip-interop-tech] July 2012 interop schedule I've received a couple of requests to see if we can move the interop testing back a week. That works I think better for the preparation from our point of view too so could those participating please let me know in the next day or so whether or not moving the interop testing from 9-20th July to 16-27th July would be an issue. As always the Cryptsoft interop servers remain available for testing all the time and if you need credentials for access and do not already have them please contact me so we can arrange those. Thanks, Tim. --------------------------------------------------------------------- To unsubscribe, e-mail: kmip-interop-tech-unsubscribe@lists.oasis-open.org For additional commands, e-mail: kmip-interop-tech-help@lists.oasis-open.org

All the vendors who have current committed to participate have indicated the new dates of 16-27th of July are suitable so that is now the new target date for this round of interoperability testing. Thanks for the quick feedback and for everyone being willing to adjust the date to accommodate other vendors schedules. If there are suggestions on ways to improve the collection and reporting of the results please send them either to myself or to the list as a whole. Absent any feedback we will use the same approach we did in January with each vendor filling in a results spreadsheet. Based on last round I think it is important to plan to re-run the tests near the end of the second week to verify results. If everyone could confirm their systems are reachable and that the correct ports are open for access that should help with getting the testing operating. For those vendors behind corporate firewalls please ensure you can get port 5696 opened for outgoing access as most vendors are now using the officially allocated port. Thanks, Tim. On 29/06/2012 9:42 AM, Tim Hudson wrote: > I've received a couple of requests to see if we can move the interop > testing back a week. > > That works I think better for the preparation from our point of view too > so could those participating please let me know in the next day or so > whether or not moving the interop testing from 9-20th July to 16-27th > July would be an issue. > > As always the Cryptsoft interop servers remain available for testing all > the time and if you need credentials for access and do not already have > them please contact me so we can arrange those. > > Thanks, > Tim. > >

The KMIP interop-tech call is on again this week on the same schedule as the main TC calls starting 30 minutes before the main call. The dial-in number for the call is the same as the main call number. If you don't have those details then drop me an email and I'll forward them. The agenda for this week: 1) Updates on Statements of Use 2) Confirming readiness for interop testing mid-July [16th-27th] 3) Any status update on GET for TEMPLATE Thanks, Tim.

If each vendor could send out a note confirming they are ready to commence testing that would be ideal and please note which test cases are covered (where applicable). So far we have Thales and Cryptsoft servers confirmed in emails over the weekend with their current set of test cases noted. From a Cryptsoft perspective, both C and Java servers are online at the usual locations and C and Java clients with the full suite of test cases are ready to run against each server. The C server has all test cases except 15.3 and the Java server has all test cases and for both servers these are available under KMIP 1.0 and KMIP 1.1 protocol versions. I'll circulate the reporting spreadsheets tomorrow. Depending on the level of interactions we may have a call this week 30 minutes before the usual main KMIP TC call time (even though the KMIP main call is not on this week). I'll send out details on that at least 24 hours before the call if it is on. If you are participating in the interop and this time would not work for you please let me know. Thanks, Tim.

On behalf of Mahadev at NetApp (please reply to Mahadev directly as he is not yet on the kmip-interop-tech list). NetApp is participating in this round of interop testing and they have noted the following requirements on servers: The server must respond to ICMP ping requests The server should be on port 5696 The server needs to allow creation of managed objects where the Object Group is any of the following: "1575077598-1574897331" "135065831-135065812" "1781035901-00000000" "1786421228-1786420284" If you have not previously provided credentials to NetApp or you are not currently performing testing with NetApp then please provide the necessary details directly to Mahadev so they can commence testing. I've previously designated the two NetApp test cases as: NetApp-1 - Locate, Register, GetAttributes, etc NetApp-2 - Locate, GetAttributes, etc As these test cases match the product usage and do not as yet match any of the documented test cases (something which is on the list of things to include in the next round of updates to the test case document). Thanks, Tim.

Attached is an updated spreadsheet for recording results. It is similar to what we used back in January with a few updates based on feedback from the last round of testing. Where a test result does not match the test cases it needs to be compared to confirm that it is within the range of options allowed by the specification. Please work so that client and server vendors agree on that status and if there are issues either raise with myself, or Mathias, or with the entire group - whichever you are comfortable with. If we can aim to have the results circulated once the first round of testing has completed that would be great - the objective is to be able to get the combined results out to the interop group a few days after completion of the testing. As per previous interop events please preserve your logs so that where there are any disagreements about the interpretation things can be easily resolved. The request and response messages in ASCII hex are the common format which each vendor is able to process currently so include that as well as whatever other human readable formats are supported. The conformance statements in the specifications and the base profiles are the important items to work thought as all clients and servers are required to support those base items in order to be considered compliant KMIP clients or servers. The two test cases for NetApp are marked at the bottom of the list and should be noted for testing purposes. I've filled in the Unsupported items based on each vendors public announcement of functionality so defect reports on items that are known as unsupported should be left out of any results. Those lists should be accurate - but if each vendor could confirm that it would be great so that we are all working on the one spreadsheet version for result recording. I expect we will do the usual multiple rounds of testing as vendors update servers based on any issues raised so please do prepare for re-running tests and expect to perform a final round of confirmation late next week for those vendors who produce updated server versions. Thanks, Tim. Attachment: KMIPInteropResults-Jul2012-MASTER_v1.0a_Blank.xls Description: MS-Excel spreadsheet