OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments for NIST


Howdy KMIP TC!

 

Per our meeting last week  -  here are the data points for our response back to NIST:

 

1.      The added complexity is not required and seems more attuned to deployment of systems that use keys as distinct from the key management system itself.  Having a Suspended State that has transitions back and forth from Active, Disabled, Compromised, and Destroyed creates complexity. It is arguable that the Suspended state is not a Key Management function but a authentication\authorization function outside the scope of Key Management. Additionally, addressing key state transitions from Active to Destroyed presents operational complexity in regards to connections, management, and implications for creating instability in systems by removing  disabled transition for key material from the process.

 

2.      State transitions should be one-directional, non-looping as reflected in the Key Management States.  Key management states need to be alignment with key state model to address key transitions.  Having A unidirectional model for key management states and a bi-directional model for key states creates systemic complexity and presents the opportunity for unstable states between keys and the systems that manage the keys.  A one-directional Model represents less complexity and greater likelihood for adoption.

 

3.      We have seen no justification for dropping the state of Destroyed/Compromised as it is already established and industry has taken steps to implement. As the key state model is a form of a data contract implemented by industry, it is imperative not to remove aspects of the data contract without a path of deprecation. Having a timeline for removing a given aspect of a data contract allows industry to adapt technology and take steps to implement changes within product release cycles.

 

 

Feel free to add more- once we have the content  - I plan on referring to the lines in the document that our comments reflect in order to reference what parts of the 800-57 Part 1, Rev 4 we are addressing

 

 

Thanks!

 

Chuck



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]