kmip — archive

[Sean Turner]

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