Comments on kmip-1.0-spec-ed-0.98 from 7/29

[Sean Turner <turners@ieca.com>]

Here are some comments on the kmip-1.0-spec-ed-0.98 from 7/29:

In 2.1.3, pointer from transparent keys should be to 2.1.7 not 2.1.6.

To aid the reader can we add pointers for the tables that say that the 
structure is an enumeration to the appropriate tables in Sec 9?

If Key Value (2.1.4) and Key Wrapping Data (2.1.5) are only ever part of 
Key Block should the sections be made subsections to 2.1.3?

Key Value (2.1.4) indicates that it is only ever used in Key Block 
(2.1.3).  Is this also true of Key Wrapping Data (2.1.5)?  If so could 
we add the same text to 2.1.5?

In 2.1.8, the reference in the name row is broken (it's to section 0).

In 2.2, a reference is broken (it's to section 0).

Sec 3.9 unclear what the last sentence in the 1st paragraph means. The 
certificate subject shouldn't change during a renewal.  Renewals involve 
keeping the same private key and extending the lifetime.

Sec 3.12, we should probably align with PKIX and specify that when 
encipherOnly or decipherOnly is set that keyEncipherment must also be set.

Sec 3.12, I would delete the paragraph between Table 56 and Table 57 to 
avoid any debate about setting the non-repudation/digital signature 
bits.  Some certificate policies have avoided all of it by setting the 
digital signature bit also provides non-repudiation services.

Sec 3.20, add that the mechanism to indicate that special permission has 
been granted is beyond the scope of the protocol.

Sec 3.22, it seems a bit harsh to force the compromise ocurrance date to 
be the entire usage period if you don't when the compromise occurred. 
It's supposed to be an approximate time so shouldn't we just delete the 
2nd sentence?

Sec 4.*, for requests that have no required objects should we add 
something that says at least one of the objects must be present?  It 
makes it clear that for an implementation to conform it can't issue and 
empty request/response.

Sec 4.*, I think we need to add some text that says something about the 
client only being able to use operations on the entries it 
owns/controls.  There's some language in the revocation, destroy, 
archive, and recover operations, but what a data mining operation where 
I just send locates operations for all the keys on the server and then 
issue a request to get all the keys for whatever IDs it got back.

Sec 4.7, revoking the certificate after re-certify is unnecessary in 
some cases.  This should be left to the certificate policy and not 
specified in the protocol.

Cheers,

spt