Meeting Minutes for February 21, 2020 (F2F Day Two) - oasis-tcs/kmip GitHub Wiki

Meeting Commenced at 9:05 AM PST

Due to an IT issue we had to suspend rollcall until the issues with the remote audio were resolved.

Restarted roll call at 9:27 AM PST

Welcome and Roll Call (Tony C)

  • Quorum achieved

Approve F2F Day Two Agenda

Motion to approve F2F Day Two Agenda

  • Tim H moves, Tim C seconds, No objections, abstentions, or comments. Agenda approved

Motion to discuss the concerns raised by Quintessence Labs regarding how some of the Interop results were reported in the Interop 2020 Results presented on Day One of the F2F

  • John L moves, Tim H seconds, No objections, abstentions, or comments. Motion approved

Interop 2020 Revisited

  • Revisited Interop 2020 discussion from Day One to address concerns Quintessence Labs (Q-Labs) raised with the reporting of some of the Interop results. Specifically the concerns are with the results presented in slides 14 and 16 of the Interop Results presentation (RSA2020 Interop Review_v3.pdf) presented on Day One of the KMIP TC F2F.

  • The Interop Test results used to create this Interop summary presentation were reviewed and approved within the KMIP Interop sub technical committee, but the actual slides that presented the summary of the Interop event were not distributed to the KMIP Interop participants for review prior to being presented to the full KMIP TC at Day One of the KMIP TC F2F.

  • Judy F asked if these Interop Summary presentation would be presented or used in any way at the OASIS booth at the RSAC 2020 show next week. Tony C confirmed that the presentation would not be used at the booth either as a presentation or as any of the display materials.

  • A very lengthy discussion of the concerns of over the presentation of the Interop results and the scope of the Interop event including whether profile conformance testing was in scope for the event ensued.

  • John L requested that the Interop Results presentation not be posted to the OASIS site until it could be reviewed and approved by the KMIP Interop sub technical committee.

    • Tim H noted that given that the Interop Results presentation had already been presented at Day One of the KMIP F2F it had to be posted to the OASIS site since the OASIS rules require all OASIS TC meetings, presentations given at meetings, etc. to be publicly visible.  

  • When it became apparent that it would not be possible to resolve the issue without having significant impact on the planned agenda planned for Day 2 of the KMIP TC F2F, Judy F (TC Co-Chair) recommended that the issue resolution be taken up in the KMIP Interop sub technical committee, that the TC make the necessary motions to approval participation in the OASIS booth at the RSAC 2020 show the subsequent week, and that the TC move forward with the planned Day 2 of the KMIP TC F2F agenda.

Motion to approve vendor participation in the KMIP Interop Event at RSA Conference 2020

  • Tim H moves, Tim C seconds, No objections, abstentions, or comments. Motion approved

Motion to have the issues raised about the presentation of Interop results and Interop scope resolved in the KMIP Interop sub technical committee

  • Tim C moves, Kyle W seconds. No objections, abstentions, or comments. Motion approved

Break

Interop 2021 (Tony C)

  • The TC must agree to hold an interop event in order to allow OASIS to secure a booth for RSAC 2021. Looks like it would be a max of eight participants for a ‘pavilion’ booth.

Motion to hold a KMIP Interop event at RSAC 2021

  • Mark J moves, Greg S seconds. No objections, abstentions, or comments. Motion approved.

  • The TC then discussed electing an Interop Lead. Tim H nominates Tony C and Tony C accepted.

Motion to (re)elect Tony Cox as the Interop Lead for the Interop 2021 event

  • Greg S moves, Mark J seconds. No objections, abstentions, or comments. Tony C re-elected Interop Lead.

Name Representation (Bruce R)

Name Representation.pdf

  • Bruce R discussed how names are currently represented in KMIP.

  • He noted that Name has an odd structure which allows different representations but most KMIP implementations use TextString.

  • KMIP also has Alternative Name if more name constructs are needed.

  • Bruce R prosed changing KMIP to simply Name changing it from a structure to just TextString. Alternative name would remain as is.

  • Mark J commented that he was happy for this simplification. This is more of a server issue than that of a client.

Motion to move forward with Spec deltas for simplifying the Name representation to just TextString

  • Tony C moves and Kyle seconds. No objections, abstentions, or comments. Motion approved.

Link Representation (Bruce R)

Link Representation.pdf

  • Bruce outlined the issues with Link where very different Link types are bundled together.

  • There are single instance links which are actually multi instanced

  • Security models which restrict specific attributes can be broken

  • Many KMIP instances cannot locate on partial structures. For example, you can’t ask for all Certificate links.

  • Bruce proposed a change to KMIP where each Link Type becomes a new attribute and can be used clarify the name of the different Link Types like whether they are single vs multi instance

  • Mark J asked about what would happen to an object created with Links in KMIP 2.x but then accessed using this new Links approach in KMIP 3.x?

  • Servers would need to support both the old and new representations of Link in order to satisfy clients operating at different KMIP versions.

  • A lot of this will be left to the server implementation. KMIP is silent on this.

  • KMIP does expect a server to deliver responses to client in the KMIP version the client make the request in.

Motion to move forward with this proposal and produce KMIP Spec deltas for the new Link Representation

  • Tim H moves, Kyle seconds. No objections, abstentions, or comments. Motion approved.

Name Lifecycle (Tim H)

Name Lifecycle.pdf

  • Tim led the TC in a discussion on name lifecycle.

  • KMIP has different ‘names’ for things. There is also a lifecycle where things can be ‘renamed’. This lifecycle is not like UID.

  • Users of KMIP often expect what they have ‘named’ stays with the value and of course that is not always the case. The names could be changed.

  • In KMIP today, Link references to objects are by identifier.

  • Proposal is to introduce a NameReference concept where objects can be looked up by name. Link reference to object by name. Existing Link reference by identifier would continue to be supported.

  • TC members raised questions and comments on the proposal:

  • John L noted that there were many opportunities for things to get out of sync. He asked if we should deprecate the Links by identifier option all together.

    • Tim H noted that rules could be put in place to describe when to use one reference type versus the other.

    • There was agreement in the TC that any rules will need be very clear in the Spec as to what needs to be done based on lifecycle.

  • It may be tricky for ‘related’/linked objects like public/private key

    • Will need to change names for these type of objects in a transactional safe manner

  • Definitely will need more error code to handle the failure cases

  • Agreement that we will to work through a Name Lifecycle as a TC

  • Tim H moved on to present the second problem in his presentation related to keys in a referenced object. If you destroy the original object you don’t want to lose the reference to the keys that are destroyed and may be needed.

  • Tim posed the question if the TC should tackle a ‘hold’ concept which could put an operation like destroy on hold in KMIP 3.0?

  • This would essentially put a hold on some state transitions, but it was noted that in KMIP we seem to be missing the trigger for some of the state transitions which will need to be addressed.

  • This won’t change behavior of Create where links get created.

  • Judy pointed out that Application Specific Information also have been used as a way to ‘name’ keys as well and may be another area we can revisit.

    • Tim H agreed

Motion to move forward with this proposal and produce KMIP Spec deltas for Name Lifecycle and the ‘hold’ concept

  • Kyle W moves, Greg S seconds. No objections, abstentions, or comments. Motion approved.

Lunch

Grouping Objects (Tim H)

Grouping Objects.pdf

  • Tim H discussed how existing KMIP versions handle groups of objects.

  • Technically KMIP v1.x and v2.x really do not group objects. We allow objects to be put into groups, but it’s a recommendation not a requirement. Currently we have an Object Group attribute which is defined as a TextString, but there are no semantics.

  • Mark J pointed out there is no way to query for groups and P6R has a number of customers asking for how to make groups.

  • In today’s KMIP implementations there is a range of interoperable and inconsistent handling of groups. KMIP needs to move back to consistent and interoperable ways to reference groups.

  • Tim noted that in order to support automation we need the ability in KMIP to create, destroy and enumerate groups. He proposed:

  • Adding a System Object of type Group

  • Replace Object Group with Group which is either a Reference or NameReference

  • Add Link Type of Group Link (or new Group Link attribute)

  • TC members raised questions and comment on the proposal:

  • John L asked if there was current a way to find all members of a group.

    • Yes, this can be done via Locate with all named reference or reference to the group.

  • If you destroying a group would members still think they are part of something? Dangling references?

  • Destroying group and how server handles how this occurs will be left as an implementation decision of the server.

  • Destroy doesn’t remove metadata so deleting a group does not delete objects that were members of that group.

Motion to move forward with this proposal and produce KMIP Spec deltas for Grouping Objects

  • Mark J moves, Greg S seconds. No objections or abstentions. Comments below. Motion approved.

  • Comments on Motion:

  • John L is happy with looking at a group concept, but he thinks of groups as a container and in this proposal, group is not a container.

  • Jim S noted that TC needs to address destroying an object and then creating a new object with same name in general and more specifically in this group concept.

    • Tim H noted the proposal was intended to be building blocks, which can be used to create more detailed concepts.

  • Tony C wanted a way to get rid of a group without removing all members from groups.

  • Mark J said we also need a way to move an object from one group to another.

    • Tony C and Mark J will consider bring proposals forward on these two topics.

Group Hierarchy (Bruce R)

Group Hierarchy.pdf

Bruce R presented on group hierarchy.

  • KMIP is currently silent on how groups are related to one another.

  • A simple proposal to make a hierarchy of groups is to add Parent Link to Groups

    • Parent (and Child) Links exist, If Group becomes an object (previously discussed proposal) this approach will just work.

  • Mark J asked how to find out what groups and object is a member?

    • This is not possible at the moment even with this proposal. It’s actually a bigger issue that we don’t have a way to follow a Link chain.

    • This series of proposals on groups are taking things in steps. Getting building blocks in place and then we can get the more higher-level concepts (like finding out what groups an object is a member) working.

Motion to move forward with this proposal and produce KMIP Spec deltas for Group Hierarchy

  • Tim C moves, Tim H seconds. No objections, abstentions, or comments. Motion approved.

Lists of Groups (Tim H)

Lists of Groups.pdf

  • Tim H presented the List of Groups proposal

    • Object Groups is a structure. If we do the other groups related proposals discussed in the F2F we need to make sure to update Object Groups appropriately.

Motion to move forward with this proposal and produce KMIP Spec deltas for List of Groups

  • Mark J moves, Kyle W seconds. No objections, abstentions, or comments. Motion approved.

Break

Other Objects (Other System Objects) (Tim H)

Other System Objects.pdf

  • Tim presented other candidates that could be system objects: Object Defaults, Rights, Groups, System (aka the system itself).

    • We have hung a lot off Query and maybe we can find an alternative if we had system objects.

    • Adding a Defaults System Object takes it out of Query, but not sure what to pin defaults against.

    • Same goes for Right(s)

  • Really need to figure out how to address the mess Query has become. We don’t have a way to talk to the System outside of Query.

    • More detailed proposals are needed

  • No motions needed for this presentation

Meeting Review (Tony C & Judy F)

  • TC revisited items tabled from yesterday’s meeting.

  • What happens when links breaks?

    • We covered some of this in the presentations today. It still remains as a problem, but let’s see what comes of the proposals and deal with in the context of these proposals.

  • We deferred motions on the Automation Architecture (Object Classes, System Object) and User Handling (Clients and Credentials as Users) proposals which were presented on Day One of the KMIP F2F until the TC was able to hear several of the presentation on Day Two.

    • Tony C asked if there were any objections with making single motion to move these proposals to the KMIP Spec delta phase. No objections were raised.

Motion to move forward with the proposals and produce KMIP Spec deltas for the Automation Architecture and User Handling proposals.

  • Bruce R moves, Tim C seconds. No objections, abstentions, or comments. Motion approved.

  • TC revisited the question of the version of KMIP NG (e.g. v2.2 or v3).

    • Given the extent of the proposals that have been reviewed and approved to more forwarding during the KMIP F2F the consensus is that the next version is a major version KMIP 3.0.

    • TC also discussed obtaining the starter documents for the KMIP 3.0 documentation set from TC Admin. Did a quick roll call to ensure that all the existing KMIP 2.1 editors were willing to continue in those roles for KMIP 3.0 and all of them agreed.

Motion declaring that the next KMIP version will be KMIP 3.0, request for the KMIP co-chairs to ask TC Admin to provide the KMIP 3.0 documentation templates and approve all KMIP 2.1 document editors continue in those roles for KMIP 3.0.

  • Tim H moves, Tim C seconds. No objections, abstentions, or comments. Motion approved.

Close (Tony C)

Call for Additional Attendees

  • None

Next Meeting

  • Cancel meeting for next two week

  • Next meeting March 12, 2020

Motion to thank Utimaco for hosting the KMIP TC Face-to-Face meeting at their facilities.

  • Tony C moves, Judy F seconds. No objections, abstentions, or comments. Motion approved.

Motion to adjourn

  • Tim H moves, Kyle seconds. No objections, abstentions, or comments. Meeting adjourned

Meeting Adjourned at 2:21 PM PST