Hi Folks,
Thoughts:
- Remember: OASIS requires that the specification contain at least
one Conformance Clause. This needs to contain at least one
"conformance profile", or in OASIS terms, a "Conformance Target" (see
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html)
- I don't have a problem with specifying the server as the only
Conformance Target within the KMIP specification, and leaving out the
client requirements. A similar precedent exists within INCITS/T10
(i.e. SCSI), where the requirements (in general) only apply to the
'device server' (e.g., disk drive, tape drive) and not to the
'application client' (e.g., SCSI interface card on host system). This
would simplify the specification and reduce the bickering.
Cheers,
-Matt
Bruce Rich wrote:
OF6D0437FB.DDBB7E6E-ON86257602.006C4A55-86257602.006E1697@us.ibm.com"
type="cite">
Bob,
I like the idea of the 3 profiles
that
you mention, at least in the abstract. However, since the devil is
in the details, we'd have to hammer out a consensus on "bare minimum"
for these cases.
I like the idea of the profiles
being
separate from the spec, but since the spec itself has some language
about
what things are required, there would have to be some surgery done to
it
before finalizing.
I am fine with NOT continuing to
hammer
out a conformance profile for the proof of concept, although such a
beast
may serve well as an interop guide for the F2F in September.
I guess I'm unconvinced about the
utility
of client conformance, but perhaps the presentation that you mentioned
below would motivate that in sufficient detail to convince me. Absent
that motivation, it seems like (except in the Server To Client Only
profile)
the client only needs to be able to deal with responses to whatever
requests
it has made, and thus just a breakout of necessary datatypes per
request/response
is needed. The only exceptions to that rule would be if the server
does other than exactly what the client requested.
Bruce A Rich
brich at-sign us dot ibm dot com
After doing a lot of thinking on this I
personally don't see any conformance profiles belonging within the
standard
itself. There is no reason we couldn't establish guidelines that
are published as a separate document and referenced by the
specification.
This would allow anyone who wants to use
the standard to define a conformance profile without too many
limitations.
It also allows them to use KMIP in other standards so that a basic
definition can be in a profile and the detailed usage resides in their
primary document which they may charge for (it is anyones choice
whether
or not to use something they have to pay for).
This doesn't mean that we leave all
conformance
profiles to external organizations. The way I see it is we define
2 or 3 basic conformance profiles such as:
1. Symmetric Key Management Profile
- bare minimum for managing symmetric keys
2. Assymetric Key Management Profile
- bare minimum for managing assymetic keys
3. Server to Client Only profile (e.g.
as mentioned before thermostats, utility meters, etc...)
This leaves the standard open enough for
anyone that wants to, to create their own profile and potentially have
it posted on the OASIS web site once approved by the TC or the
appropriate
subcommittee if created.
My original concept of the table was
just
an at a glance table for people who knew basically what they needed to
be able to look at. They could then determine if they needed to look
deeper into the specific requirements of the profile. Specifics were
not meant to be defined in the table. It would get very ugly very
fast as Bruce found out. And no Bruce, whily you may have personal
problems (I don't know of any but I can't speak for anyone else) I
think
you were right that the table doesn't suit the overall definition
required
in a profile. That is why detailed definition should be listed in
the follow on sections for server & client.
It might be good to have a PoC Profile
which
defined what is tested in the PoC but I don't think it is required
unless
Bruce or someone else wants to continue to figure out the specific
requirements
(see his email below).
Things that could be covered by a
profile
include:
* Required objects, attributes,
operations
and messaging
* Required elements of each required or
optional object, attribute or operation
* Minimum and maximum number of
repeatable
elements supported
* Transport requirements (including
physical
connectivity, protocols, default ports, etc...)
* Authentication mechanism (e.g.
certificates,
device id & password, etc...)
* Server mutatable elements of objects
and
attributes
The profile should contain all of this
information
or should document where this information can be found if in external
documents
(e.g. IEEE Std 1619.3-20xx, ASC X9f, etc...).
I would be glad to put together a
presentation
on how we could use templates to our benefit and to help ensure that
KMIP
is widely accepted. The presentation would also contain information
on why each of the above would be good to include in the profiles and
not
in the specification itself.
Also just because we allow things to be
defined in a profile doesn't mean we can not set minimum requirements
for
how it is used (e.g. Transport must be secured using a protocol such as
TLS or HTTPS with minimum level of authentication & security).
This
would allow KMIP to be used on other transports that have no concept of
HTTPS or TLS but have security built in that meets or exceeds the
minimum
requirements we set.
Bob L.
Robert A. (Bob)
Lockhart
Senior Solutions Architect
THALES Information
Systems
Security
From: Bruce Rich
[brich@us.ibm.com]
Sent: Thursday, July 23, 2009 7:24 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] First stab at a conformance profile
Dear TC,
I took a pass at trying to take the Proof-Of-Concept and represent it
as
a conformance profile. You should find this in the KMIP document
repository as Conformance_Clause_Proposal_V3_POC_Profile_V1.pdf
I thought I'd be presenting a simpler profile than the POC profile, but
before I propose a simpler profile, I'd like to see if it's even
possible
to take the conformance proposal as it currently stands and see how one
would express the POC.
This way, people can see the conformance implications of something
that's
at least vaguely familiar before I venture into something more
controversial.
Although you can read the document and see comments inserted at various
spots, the summary is that I found I had several problems:
1) The difference between NOT SUPPORTED and OPTIONAL is vague, at least
in my head. I seem to be doing a mental coin toss every time I try
to decide which flavor of (!(REQUIRED)) I want. This may be a personal
problem, or might be a conformance proposal problem. I think it's
the latter (but that may be another symptom of my personal problem :-).
2) The conformance profile is still too coarse-grained. I think we
need visibility into the enumerations on what types are supported by
implementations.
For example it's too coarse-grained to say I support Derive Key or
I don't. I could have an implementation that supported only
HASH-derived
keys, and not the other types of key derivation. The conformance
profile should allow this kind of expressiveness.
3) I really don't understand the client conformance column. If the
client doesn't make requests of particular types, then it is not going
to have to handle the responses that deal with those particular types.
It almost seems that the client column is a requester library and
not an actor in the scenario.
Bruce A Rich
brich at-sign us dot ibm dot com
The information
contained in
this e-mail is confidential. It may also be privileged. It is only
intended
for the stated addressee(s) and access to it by any other person is
unauthorized.
If you are not an addressee or the intended addressee, you must not
disclose,
copy, circulate or in any other way use or rely on the information
contained
in this e-mail. Such unauthorized use may be unlawful. If you have
received
this e-mail in error please delete it (and all copies) from your
system,
please also inform us immediately on +1 (781) 994 4000 or email
ussales@thalesesec.com.
Commercial matters detailed or referred to in this e-mail are subject
to
a written contract signed for and on behalf of Thales.
|