Resending to avoid
e-mail branch...
To minimize the
work, would folks object if we started with one profile, such as symmetric
key management, in v1 of the standard?
Larry H
From:
[mailto:]
Sent: Wednesday, July 29, 2009 2:21
PM
To: Bruce Rich
Cc: Robert Lockhart;
Subject: Re: [kmip] First stab at a
conformance profile
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:
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
From:
Robert Lockhart <>
To:
Bruce Rich/Austin/IBM@IBMUS, ""
<>
Date:
07/26/2009 12:57 PM
Subject:
RE: [kmip] First stab at a conformance
profile
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 []
Sent: Thursday,
July 23, 2009 7:24 AM
To:
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 . Commercial
matters detailed or referred to in this e-mail are subject to a written
contract signed for and on behalf of Thales.
