RE: [SPAM] - RE: [kmip] First stab at a conformance profile - Bayesian Filter detected spam

Bob -

 

One of my main interests is an off-line profile for key 
exchange; I think that was actually targeted for post 1.0; I also think the 
discussions around tape backup usage probably come close.  I don't know 
that we have to have a conformance profile for every possible usage but the main 
ones, like what you show below, I think are needed.

 

- Peter

From: Robert Lockhart 
[mailto:] 
Sent: 2009-07-26 12:54 
PM
To: Bruce Rich; 
Subject: [SPAM] 
- RE: [kmip] First stab at a conformance profile - Bayesian Filter detected 
spam

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.