OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only
  • 1.  Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 06-27-2013 20:06
    Submitter's message Converted from draft proposal to OASIS template incorporating updates from Stan Feather and inclusion of references to KMIP 1.2 documents. Editorial and formatting cleanup. -- Tim Hudson Document Name : kmip-tape-lib-profile-v1 0-wd01-review.doc Description Tape Library Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 13:05:29


  • 2.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 06-28-2013 18:57
    In 3.1.7, the client is shown as querying the ApplicationNamespaces that the server supports, and the server is shown as returning LIBRARY-LTO as a namespace that it supports. According to the spec, this means solely that the server is capable of filling in an Application Specific Information attribute with info if the client passes in LIBRARY-LTO as the namespace and an empty info field Since the client does not do that in this profile or in any examples that I can find, this is completely extraneous to the flow, so should be removed. Clients can certainly store completely-filled-in ASIs for any namespace whether the server Query indicates support for that namespace or not. If we leave this extra stuff in this profile, it looks like the server needs to do it, when the spec says it doesn't.   Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         kmip@lists.oasis-open.org Date:         06/27/2013 03:06 PM Subject:         [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded Sent by:         <kmip@lists.oasis-open.org> Submitter's message Converted from draft proposal to OASIS template incorporating updates from Stan Feather and inclusion of references to KMIP 1.2 documents. Editorial and formatting cleanup. -- Tim Hudson Document Name : kmip-tape-lib-profile-v1 0-wd01-review.doc Description Tape Library Profile Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2013-06-27 13:05:29


  • 3.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 06-28-2013 20:16
    > According to the spec, this means solely that the server is capable of filling in an Application Specific Information attribute with > info if the client passes in LIBRARY-LTO as the namespace and an empty info field Bruce, where do you think the specification actually states that? What the specification states is that if a server "supports" an application name space then it shall be returned in the query operation. It does not state that the server shall not return the application name space in Query where the client is providing the information. In 3.36 - the definition of ASI: "In that case, if the server supports this namespace (as indicated by the Query operation in Section 4.25), then it SHALL return a suitable Application Data value." In 12.1 - the definition of Query: "The Application Namespace fields in the response contain the namespaces that the server SHALL generate values for if requested by the client (see Section 3.36)." Nothing in either of those sections state what you are indicating. I can see how you get there reading between the lines. However, in the context of this profile is making it clear that this is a requirement on servers when conforming to this profile to report the application name spaces listed within the profile. Whether or not that is a requirement in the base specification is an interesting discussion - however in profiles we state the actual conformance clauses - which can (and are) narrower than the specification text. That is the purpose of the profiles - to make the behaviours clear. A server can conform to the specification and not conform to a given profile. It's great to have your feedback on this - it would have been useful to have had that feedback earlier - as that aspect of the profile is unchanged from the earlier versions uploaded back in April. It however tends to indicate that there are interpretations of the base specification in this area which may need to be expanded. It doesn't impact the profile itself. Tim.


  • 4.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 07-01-2013 20:43
    Tim, The 1.1 KMIP spec says it on lines 1017-1021.  The most current draft of 1.2 says it on lines 1059-1063 (from which you excerpted some text below). The full text says: Clients MAY request to set (i.e., using any of the operations that result in new Managed Object(s) on the server or adding/modifying the attribute of an existing Managed Object) an instance of this attribute with a particular Application Namespace while omitting Application Data. In that case, if the server supports this   namespace (as indicated by the Query operation in Section 4.25), then it SHALL return a suitable   Application Data value. If the server does not support this namespace, then an error SHALL be returned. In the larger context that I quoted, it is (more) clear that the server announcing "support" of this namespace via Query is related to its ability to fill in the rest of the information if the client sends only the namespace. Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         Bruce Rich/Austin/IBM@IBMUS Cc:         Feather <stan.feather@hp.com>, kmip@lists.oasis-open.org Date:         06/28/2013 03:16 PM Subject:         Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded Sent by:         <kmip@lists.oasis-open.org> > According to the spec, this means solely that the server is capable of filling in an Application Specific Information attribute with > info if the client passes in LIBRARY-LTO as the namespace and an empty info field Bruce, where do you think the specification actually states that? What the specification states is that if a server "supports" an application name space then it shall be returned in the query operation. It does not state that the server shall not return the application name space in Query where the client is providing the information. In 3.36 - the definition of ASI: "In that case, if the server supports this namespace (as indicated by the Query operation in Section 4.25), then it SHALL return a suitable Application Data value." In 12.1 - the definition of Query: "The Application Namespace fields in the response contain the namespaces that the server SHALL generate values for if requested by the client (see Section 3.36)." Nothing in either of those sections state what you are indicating. I can see how you get there reading between the lines. However, in the context of this profile is making it clear that this is a requirement on servers when conforming to this profile to report the application name spaces listed within the profile. Whether or not that is a requirement in the base specification is an interesting discussion - however in profiles we state the actual conformance clauses - which can (and are) narrower than the specification text. That is the purpose of the profiles - to make the behaviours clear. A server can conform to the specification and not conform to a given profile. It's great to have your feedback on this - it would have been useful to have had that feedback earlier - as that aspect of the profile is unchanged from the earlier versions uploaded back in April.  It however tends to indicate that there are interpretations of the base specification in this area which may need to be expanded. It doesn't impact the profile itself. Tim. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


  • 5.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 07-01-2013 21:02
    On 2/07/2013 6:42 AM, Bruce Rich wrote: Tim, In the larger context that I quoted, it is (more) clear that the server announcing support of this namespace via Query is related to its ability to fill in the rest of the information if the client sends only the namespace. Actually it doesn't state what support means at all. And the definitive text for that should be in the definition of the attribute. I see what you want it to state - and how to infer that meaning - but that isn't what the text actually says and other meanings are not reasonably precluded. It does not state that you shall not return an application name space from the query response when the application name space is supported but the client needs to specify the identifier. The term support has not be exclusively tied to handling Application Data not specified by the client. There are numerous errors in the specification text if this is the interpretation that you expected. There is also an error in table 120 states Application Data is Required . That is an error - as the text clearly states the the Application Data can be omitted. Bruce, I think one of the challenges here is that no one so far has actually put forward any real world example of server-side provided Application Data values with a name space description and details as to how the server is meant to provide the value. That use case simple isn't present/visible. There is use of Application Specific Information in shipping product from multiple vendors - but not with server provided Application Data values. Filling in that gap I think would be the right starting point. Tim.


  • 6.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 07-02-2013 16:31
    Tim, I agree that it would be great for the spec to be clarified in the area of ASI. Absent that, what does the server mean when it answers "LIBRARY-LTO" on a Query Application Namespaces request?   If it means only that the server can store and retrieve the values that the client(s) sent it, then that's a trivial thing for a server to do, and if a server supports ASI at all, then it could support them for all possible namespaces, so it becomes problematic for the server to answer what namespaces it supports on Query, as it could support ALL namespaces.  The spec says this about "support" in Query, The Application Namespace fields in the response contain the namespaces that the server SHALL  1645 generate values for if requested by the client (see Section 3.36). These fields SHALL only be returned in  1646 the response if the request contains a Query Application Namespaces value in the Query Function field. 1647 So it clearly says that a server responding with a namespace on Query is all about being able to fill in blanks ("generate values" is not just returning what the client stored).  I don't know why you think this is unclear. If "support" means more than just retrieval (possibly that the server knows how to fill in the "information" part of an ASI attribute, given only the namespace and the key UUID), then I have yet to see clear specification for how the server figures out what the ASI value should be.  It would have to do it from the information it has, which is the key material, and the LTO information in the UsageGuide on calculating the "information" part of an ASI seems to be about the cartridge/tape label, so the server is the wrong actor to fill this in.  The spec says this about "support" in Application Specific Information: Clients MAY request to set (i.e., using any of the operations that result in new Managed Object(s) on the  1059 server or adding/modifying the attribute of an existing Managed Object) an instance of this attribute with a  1060 particular Application Namespace while omitting Application Data. In that case, if the server supports this  1061 namespace (as indicated by the Query operation in Section 4.25), then it SHALL return a suitable  1062 Application Data value. If the server does not support this namespace, then an error SHALL be returned.  1063 So this part of the spec (in particular, line 1061) says that "support" is indicated by the server's response to Query.  I don't know why you think this is unclear.  One advertises that one's server "supports" "generation of values" if said server replies any namespaces on a Query response. I think the ASI specification is still incomplete, but it didn't matter a whole lot until one tries to harden it in a profile.  Now that this profile makes it mandatory to implement, it is critical to have "it" spelled out, hence my objection to this profile draft.  I think the profile is premature, given the lack of clarity in the spec. Or we can simply modify the profile to take out the part where the server answers "LIBRARY-LTO" on the Query Application Namespaces (which was my original request). Otherwise, as the profile now stands, from what the spec says, the server has committed itself to being able to "generate values", not just returned stored values, and this profile does not exercise the "generation" aspect at all. Bruce A Rich brich at-sign us dot ibm dot com From:         Tim Hudson <tjh@cryptsoft.com> To:         Bruce Rich/Austin/IBM@IBMUS Cc:         Feather <stan.feather@hp.com>, kmip@lists.oasis-open.org Date:         07/01/2013 04:01 PM Subject:         Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded On 2/07/2013 6:42 AM, Bruce Rich wrote: Tim, In the larger context that I quoted, it is (more) clear that the server announcing "support" of this namespace via Query is related to its ability to fill in the rest of the information if the client sends only the namespace. Actually it doesn't state what "support" means at all. And the definitive text for that should be in the definition of the attribute. I see what you want it to state - and how to infer that meaning - but that isn't what the text actually says and other meanings are not reasonably precluded. It does not state that you shall not return an application name space from the query response when the application name space is supported but the client needs to specify the identifier. The term "support" has not be exclusively tied to handling Application Data not specified by the client. There are numerous errors in the specification text if this is the interpretation that you expected. There is also an error in table 120 states Application Data is "Required". That is an error - as the text clearly states the the Application Data can be omitted. Bruce, I think one of the challenges here is that no one so far has actually put forward any real world example of server-side provided Application Data values with a name space description and details as to how the server is meant to provide the value. That use case simple isn't present/visible. There is use of Application Specific Information in shipping product from multiple vendors - but not with server provided Application Data values. Filling in that gap I think would be the right starting point. Tim.


  • 7.  Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 07-02-2013 20:19
    Excellent discussion - and it is indeed hitting the point - that server provided values for ASI is very much underspecified. How about removing it? Is anyone using it? Does anyone plan to use it? The point I'm making is that query response does not state you cannot return values in the query response for application name spaces which are client-side only. It states you must include the ones which support the (underspecified) server-side, but it does not state you cannot include others. There is also a specific error code returned when an application name space isn't supported - allowing for clients to ignore checking the query response. The usage guide talks about "recognized" rather than "supported". On removing the requirement for the name spaces to be listed in the Query response - I'll defer to Stan and Rod (there are three editors on the profile) for how to handle that. Thanks, Tim.


  • 8.  RE: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded

    Posted 07-03-2013 00:15
    Bruce, Tim, The tape profile is intended to harden the requirements for client-generated identifiers stored in ASI data. Since the spec also allows server-generated ASI data, I thought it was important to mention server-generated names in the profile, but that portion may still be weak. Regardless, I don't think servers should be required to create identifiers in ASI data for the LIBRARY-LTO namespace. The server MAY do that, but SHALL is too strong. Yet, the Query response in 3.1.8 does make that requirement. I didn't catch that, and I'm glad you pointed it out. To fix that, we can modify that line in the 3.1.8 test case, easily enough. It's also possible to change Query and ASI in the spec to better define ASI. I'm not sure spec changes are necessary, but I'll help with whatever the group believes is necessary to achieve the clarity we need. Stan


  • 9.  Application Specific Information

    Posted 07-03-2013 01:24
    Given that this area is underspecified I've taken a walk through attempting to see how it could work. The assumptions as I understand it are: 1) use of ASI is for clients where the unique identifier is unable to be stored for later use in operations 2) server-side allocation of ASI ApplicationData information can only be dependent on information from the certificate or contained within the request message 3) server -side allocation of ASI ApplicationData only occurs during the operations which create objects (that is what is stated in the specification) and it does not otherwise occur. That combination seems to contradict - in that ASI is about clients which cannot store details (otherwise they could simply store the UniqueIdentifier and work from that like non-ASI clients) - but if a client is unable to store values then there is no mechanism for a Locate to be performed for server-side ASI ApplicationData allocation as the creation of the server side values does not occur during locate (only on operations which create objects). This to me at least looks like there is no current mechanism for ASI with server-side to be usable for its intended purpose. This doesn't apply to client-side ASI ApplicationData allocation - that works cleanly and is currently deployed and we now have a profile showing its use in a clear life-cycle. If no one is using it and no one can see how to use it without basically requiring a client to store a value (and in which case it should be storing the UniqueIdentifier and simply not using ASI at all or using Name or Alternative Name under KMIP 1.2) then I think this is open to being able to be safely deprecated in KMIP 1.2 (and then subsequently removed in KMIP 2.x). Others thoughts? Tim.