RE: [kmip] streamlining the KMIP Baseline Server definition

["John Leiseboer" <jleiseboer@bigpond.com>]

I'd like to suggest that the required functionality in the KMIP Baseline
Server profile be much more reduced - just require support for the Query
and Get Versions operations. Anything more than this set of
functionality specifies features or functionality that I think properly
belong to vendors, not the standards document. By supporting just this
minimal set, it is possible for any compliant client to communicate with
any compliant server to determine what set of functionality the two
agree on.

The profiles document would be a better place to specify "standard"
profiles for behaviour beyond this minimal "discovery" set.

I suggest that we make the following changes ('x' means delete, '+'
means add):

1.	Supports the following objects: 
x a.	Attribute (see 2.1.1)
x b.	Credential (see 2.1.2)
x c.	Key Block (see 2.1.3)
x d.	Key Value (see 2.1.4)
x e.	Template-Attribute Structure (see 2.1.8)

2.	Supports the following attributes: 
x a.	Unique Identifier (see 3.1)
x b.	Name (see 3.2)
x c.	Object Type (see 3.3)
x d.	Cryptographic Algorithm (see 3.4)
x e.	Cryptographic Length (see 3.5)
x f.	Cryptographic Parameters (see 3.6)
x g.	Digest (see 3.12)
x h.	Default Operation Policy (see 3.13.2)
x i.	Cryptographic Usage Mask (see 3.14)
x j.	State (see 3.17)
x k.	Initial Date (see 3.18)
x l.	Activation Date (see 3.19)
x m.	Deactivation Date (see 3.22)
x n.	Compromise Occurrence Date (see 3.24)
x o.	Compromise Date (see 3.25)
x p.	Revocation Reason (see 3.26)
x q.	Last Change Date (see 3.33)

x 3.	Supports the ID Placeholder (see 4)

4.	Supports the following client-to-server operations: 
x a.	Locate (see 4.9)
x b.	Check (see 4.10)
x c.	Get (see 4.11)
x d.	Get Attribute (see 4.12)
x e.	Get Attribute List (see 4.13)
x f.	Add Attribute (see 4.14)
x g.	Modify Attribute (see 4.15)
x h.	Delete Attribute (see 4.16)
x i.	Activate (see 4.19)
x j.	Revoke (see 4.20)
x k.	Destroy (see 4.21)
l.	Query (see 4.25)
m.	Discover Versions (see 4.26)

5.	Supports the following message contents: 
a.	Protocol Version (see 6.1)
b.	Operation (see 6.2)
c.	Maximum Response Size (see 6.3)
d.	Unique Batch Item ID (see 6.4)
e.	Time Stamp (see 6.5)
+	Authentication (see 6.6)
f.	Asynchronous Indicator (see 6.7)
g.	Result Status (see 6.9)
h.	Result Reason (see 6.10)
i.	Batch Order Option (see 6.12)
j.	Batch Error Continuation Option (see 6.13)
k.	Batch Count (see 6.14)
l.	Batch Item (see 6.15)

6.	Supports Message Format (see 7)

7.	Supports Authentication (see 8)

8.	Supports the TTLV encoding (see 9.1)

9.	Supports the transport requirements (see 10)

10.	Supports Error Handling (see 11) for any supported object,
attribute, or operation

11.	Optionally supports any clause within this specification that is
not listed above

12.	Optionally supports extensions outside the scope of this
standard (e.g., vendor extensions, conformance profiles) that do not
contradict any requirements within this standard

13.	Supports at least one of the profiles defined in the KMIP
Profiles Specification [KMIP-Prof].

John Leiseboer

> -----Original Message-----
> From: robert.griffin@rsa.com [mailto:robert.griffin@rsa.com]
> Sent: Friday, 9 September 2011 7:00 PM
> To: kmip@lists.oasis-open.org
> Subject: [kmip] streamlining the KMIP Baseline Server definition
> 
> hi -
> 
> as discussed in our call yesterday, it may be appropriate to remove
> some of the functionality currently specified in the KMIP Baseline
> Server profile in order to establish a more truly baseline set of
> functionality. I suggest we consider removing the following items from
> the definition:
> 
> Template Attribute Structure
> Activate
> Revoke
> 
> Please let me know what you think.
> 
> I've included the current Baseline Server definition below.
> 
> regards,
> 
> Bob
> 
> An implementation conforms to this profile as a KMIP Baseline Server
if
> it meets the following conditions:
> 
> Supports the following objects:
> 66 a. Attribute (see 2.1.1)
> 67 b. Credential (see 2.1.2)
> 68 c. Key Block (see 2.1.3)
> 69 d. Key Value (see 2.1.4)
> 70 e. Template-Attribute Structure (see 2.1.8)
> 71 2. Supports the following attributes:
> 72 a. Unique Identifier (see 3.1)
> 73 b. Name (see 3.2)
> 74 c. Object Type (see 3.3)
> 75 d. Cryptographic Algorithm (see 3.4)
> 76 e. Cryptographic Length (see 3.5)
> 77 f. Cryptographic Parameters (see 3.6)
> 78 g. Digest (see 3.12)
> 79 h. Default Operation Policy (see 3.13.2)
> 80 i. Cryptographic Usage Mask (see 3.14)
> 81 j. State (see 3.17)
> 82 k. Initial Date (see 3.18)
> 83 l. Activation Date (see 3.19)
> 84 m. Deactivation Date (see 3.22)
> 85 n. Compromise Occurrence Date (see 3.24)
> 86 o. Compromise Date (see 3.25)
> 87 p. Revocation Reason (see 3.26)
> 88 q. Last Change Date (see 3.33)
> 89 3. Supports the ID Placeholder (see 4)
> 90 4. Supports the following client-to-server operations:
> 91 a. Locate (see 4.9)
> 92 b. Check (see 4.10)
> 139
> 93 c. Get (see 4.11)
> 94 d. Get Attribute (see 4.12)
> 95 e. Get Attribute List (see 4.13)
> 96 f. Add Attribute (see 4.14)
> 97 g. Modify Attribute (see 4.15)
> 98 h. Delete Attribute (see 4.16)
> 99 i. Activate (see 4.19)
> 100 j. Revoke (see 4.20)
> 101 k. Destroy (see 4.21)
> 102 l. Query (see 4.25)
> 103 m. Discover Versions (see 4.26)
> 104 5. Supports the following message contents:
> 105 a. Protocol Version (see 6.1)
> 106 b. Operation (see 6.2)
> 107 c. Maximum Response Size (see 6.3)
> 108 d. Unique Batch Item ID (see 6.4)
> 109 e. Time Stamp (see 6.5)
> 110 f. Asynchronous Indicator (see 6.7)
> 111 g. Result Status (see 6.9)
> 112 h. Result Reason (see 6.10)
> 113 i. Batch Order Option (see 6.12)
> 114 j. Batch Error Continuation Option (see 6.13)
> 115 k. Batch Count (see 6.14)
> 116 l. Batch Item (see 6.15)
> 117 6. Supports Message Format (see 7)
> 118 7. Supports Authentication (see 8)
> 119 8. Supports the TTLV encoding (see 9.1)
> 120 9. Supports the transport requirements (see 10)
> 121 10. Supports Error Handling (see 11) for any supported object,
> attribute, or operation
> 122 11. Optionally supports any clause within this specification that
> is not listed above
> 123 12. Optionally supports extensions outside the scope of this
> standard (e.g., vendor extensions,
> 124 conformance profiles) that do not contradict any requirements
> within this standard
> 125 13. Supports at least one of the profiles defined in the KMIP
> Profiles Specification
> 
> ---------------------------------------------------------------------
> 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
> 
>