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: Re: [kmip] Issue with KMIP SoUs/conformance vs. Use Cases


The Use Case document does not cover all of the areas required to claim 
conformance - it is close - but not complete and has been a topic of discussion 
in the interop group. It has however allowed for a consistent set of baseline 
tests to be established between the various vendors.

I have a pile of tests outside of the use case document which I've been using 
(in addition to the use case document) which cover both OPAQUE and TRANSPARENT 
SYMMETRIC KEY types via the REGISTER operation (and returned appropriately in 
GET operations). The Cryptsoft KMIP client and Cryptsoft KMIP server do indeed 
support these (added relatively recently along with other KMIP functionality as 
various parts of the specification are completed).

I haven't seen anything in the documents which claim that the use cases are 
meant to offer complete coverage of the specification and I doubt that is an 
OASIS requirement so there is no need or requirement IMHO to change the documents.

For vendors who are uncomfortable with the Secret Data Profile issue it can 
simply be removed from the statement; for transparent symmetric key that just 
needs to be confirmed available in the implementation.

 From a Cryptsoft point of view the statement of use remains unchanged - interop 
testing using the use cases has been performed with the other named vendors and 
the various requirements of each of the profiles are indeed implemented.

Thanks,
Tim.




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