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] KMIP Conformance Decision Tree


Matt,
I concur with your Editorial Comments and support the PKCS#11 analogy.
 
The base KMIP Conformance Profile should specify essential communications/messaging, plus profile negotiation and/or query and capability disclosure.
All important usage domains (p1619.3 etc) would develop their own additional/optional Conformance Profiles.
 
Regards,
Steve Wierenga
HP


From: Matthew.Ball@Sun.COM [mailto:Matthew.Ball@Sun.COM]
Sent: Wednesday, August 26, 2009 10:33 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP Conformance Decision Tree

Hi Folks,

In looking at recent reflector discussion on conformance, I think we've reached a saturation of data and opinions, and need to distill this down to a set of simple decisions for the TC to make to move this issue forward.  This e-mail is an attempt at this.  Please feel free to fine tune it.

As I've said before, we need to make sure to meet the requirements within the OASIS Conformance Guidelines.

Open questions:
  1. Shall the KMIP specification include one or more than one Conformance Clause for the server Conformance Target? (I think we need at least one)
  2. Shall the KMIP specification include zero, one, or more than one Conformance Clause for the client Conformance Target?
  3. Shall the Conformance Clause(s) for the server Conformance Target(s) include a relatively minimal or maximal feature set?
If the group can answer these questions, then we can follow-up with a concrete proposal for the Conformance Section (which contains one or more Conformance Clauses).  We already have a couple such proposals, so it should just be a matter of tweaking the language somewhat.

[Matt's Editorial Comments:]

In reading the OASIS Conformance Guildelines, there are a couple notes:
  • The easiest approach would be to have only one Conformance Clause with only one corresponding Conformance Target (the server).  In this situation, a Conformance Claim would be a simple statement such as "product X is a conforming KMIP implementation"
  • The next easiest approach is to create a Conformance Clause for the server and a Conformance Clause for the client.  Then, a conformance statement would be like this:  "product x is a conforming KMIP Server implementation" or "product y is a conforming KMIP Client implementation"
  • If we decide on multiple Conformance Clauses for the server Conformance Target, then we run into a little trouble because there's really supposed to be a 1-to-1 correspondence between Conformance Clauses and Conformance Targets.  We'd have to start making up new names for different server Conformance Targets, like "KMIP Baseline Server", "KMIP Symmetric Key Server", "KMIP Financial Services Server", etc.  It's possible, but can make things a bit ugly.
My preference is to keep the Conformance Clause as simple as possible -- just have one Conformance Clause for a 'baseline' server Conformance Target.  This baseline server would be capable of basic communication and capability disclosure, but would not necessarily be able to do anything else.  All other 'profiles' would be given to other standards groups or KMIP subcommittees to work out.  Every such profile would be a superset of the baseline server Conformance Clause.

This model follows that of PKCS#11 fairly closely.  To claim compliance as a PKCS#11 provider, it's only necessary to implement a small subset of all PKCS#11 commands -- essentially the commands that allow the application to query the capabilities of the PKCS#11 provider.  Even so, most PKCS#11 providers still typically provide an extensive set of algorithms and in general have good interoperability.

Cheers,
-Matt


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