Bruce -
I think we are in agreement. Although you have been
able to assess what the implications are for you; I haven't gotten there
yet.
- Peter
From: Bruce Rich [mailto:]
Sent: 2009-05-14 10:17 AM
To: Zelechoski,
Peter
Cc:
Subject: RE: [kmip]
question regarding conformance statement for KMIP
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
