Peter,
I agree that conformance needs to mean
something. I was merely looking at the current specification to see
if it says anything that reads on the current discussion point. It
seems to indicate that all managed objects are optional.
If we want KMIP conformance claims to
be meaningful, it may mean that we either change the specification, or
that we introduce profiles over the top of the specification. (This
was basically the approach used with the Web Services specs, where WS-I
introduced profiles of the specs that had meaningful, interoperable subsets).
<possibleRatHole>
I would love it if KMIPv1 did not require
support of Key Wrapping Specification (as not needed over SSL-protected
session), but if I say that I support any ManagedObject on the Query
Objects call, then it looks like I need to (with some set of CryptographicParameters).
The current Query doesn't seem to allow me to tell clients not to
ask for or to send wrapped keys.
I would also love it if KMIPv1 did not
require support of the Derive Key operation (with 7 defined derivation
mechanisms), but if I say that I support SymmetricKey on the Query Objects
call, then it looks like I need to, as Query doesn't have a way for me
to report this either. This would simply be a matter of adding Derive
Key to the optional operations list that Query Operations can report on.
</possibleRatHole>
Bruce A Rich
brich at-sign us dot ibm dot com
From:
"Zelechoski, Peter" <>
To:
Bruce Rich/Austin/IBM@IBMUS
Cc:
<>, <>
Date:
05/14/2009 08:38 AM
Subject:
RE: [kmip] question regarding conformance
statement for KMIP
Bruce -
OK, I understand what you are
saying. However, I wonder about a standard with no required exchanges
for claiming conformance. There should be something the system must
handle to claim conformance. If you can answer "not supported"
to every object and still say you are conformant, you have delivered nothing
of value and that waters down the claims of truly conformant systems.
- Peter
From: Bruce Rich [mailto:]
Sent: 2009-05-14 8:27 AM
To: Zelechoski, Peter
Cc: ;
Subject: RE: [kmip] question regarding conformance statement for KMIP
Peter,
I'm not sure what you meant by "mandatory object". It would
seem that all objects are optional, as the server's response to a Query
Objects operation specifies those objects that the server supports, and
all the managed objects are potential entries in that list. So if a server
does not wish to support registration of SplitKey, then it would simply
omit SplitKey from the list of objects that it claims it will support (if
the client bothers to ask via Query Objects).
Bruce A Rich
brich at-sign us dot ibm dot com
From:
"Zelechoski, Peter"
<>
To:
<>
Cc:
<>
Date:
05/13/2009 08:57 PM
Subject:
RE: [kmip] question regarding conformance
statement for KMIP
Robert -
My opinion is that an implementation that wants to claim compliance to
the standard would be required to respond accurately to all
required/mandatory objects. A response of "not supported"
would only be
appropriate for an optional object.
- Peter
-----Original Message-----
From: [mailto:]
Sent: 2009-05-13 7:36 PM
To:
Subject: [kmip] question regarding conformance statement for KMIP
Hi -
Rather than convening a meeting on conformance (as I'd suggested a
couple of meetings ago), I'd like to pose the question I've been
wondering about and see if there is an issue or not:
- Should we modify
the language in Section 5 of the Usage Guide to
clarify what "support all objects etc" means? In particular,
do we need
to clarify whether this means a) the server has to implement all
mandatory objects etc or b) the server has to understand requests
related to all mandatory objects etc (but can return back an "object
not
supported" message).
In drafting the conformance language currently included in the Usage
Guide, I followed the advice expressed in the Conformance Testing
document available at http://xml.coverpages.org/conform20000112.html:
that is, "the requirements or criteria for conformance must be specified
in the standard or specification. This is usually in a conformance
clause or conformance statement..."
The conformance statement in section 5 of the KMIP Usage Guide
distinguishes between conformance requirements for KMIP servers and
clients:
"Server implementations of the KMIP protocol must support all objects,
attributes, operations and profiles not specified as "optional"
in the
KMIP Specification in order to be conformant to the specification.
Server implementations that do not support objects, attributes,
operations and profiles defined as "optional" can claim KMIP
conformance, though they may be limited in terms of interoperability
with other KMIP implementations.
Client implementations of the KMIP protocol may implement any subset of
the KMIP protocol. For example, a client may implement only the Get and
Locate operations for symmetric keys. In order to claim conformance,
however, such a client must implement all aspects of any elements of the
protocol (objects, attributes, operations, profiles) that it claims to
support. In the example of Get/Locate support for symmetric keys,
therefore, a conforming client implementation must support all required
attributes for symmetric keys."
In re-reading the conformance statement for server implementations, it
looks to me that I made it more restrictive than I intended - that the
language should perhaps have been something like:
"Server implementations of the KMIP protocol shall accept and respond
to
client requests for all objects, operations and profiles not specified
as 'optional' in the KMIP Specification in order to be conformant to the
specification; a conformant response can be 'this object etc is not
supported.'"
But perhaps it's better to have the more restrictive language, after
all?
I'd appreciate your thoughts!
Regards,
Bob
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
