OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [kmip] Possible error in KMIP 1.4 spec


That error was actually introduced back in version 1.2 of the specification (1.0 and 1.1 had it correctly worded).

The original wording was "The Total value is copied from the existing key, and the Count value is set to the Total value." adding the "in the new key" as per ReKeyKeyPair doesn't hurt although that isn't done for the rest of the items in the table - they are all in the context of the new key unless otherwise stated.

Tim.


On Tue, Apr 3, 2018 at 2:45 PM, Warren Armstrong <WA@quintessencelabs.com> wrote:

Hi all,

 

I’ve just run across what I believe to be an error in the KMIP 1.4 standard, which is also present in the KMIP 2.0 draft (WD03). I have been unable to find an errata anywhere, so I thought it best to inform the group via this email list.

 

The problem is in section 4.4 (Re-key), specifically in Table 173. (KMIP 2.0: Section  6.1.36  Table 248).

The entry for “Usage Limits” says:

 

“The Total value is copied

from the existing key, and

the Count value in the

existing key is set to the

Total value.”

 

As per Section 3.21 (KMIP 2.0: 4.50), the interpretation of the Count value is “the currently remaining number of Usage Limits Units allowed to be

protected by the object.”.  Thus, setting Count = Total is equivalent to a reset.  I suspect that the intention was to apply this reset to the new object,

not the existing object – I suspect the wording of section 4.4 should rather be:

 

“The Total value is copied

from the existing key, and

the Count value in the

new key is set to the

Total value.”

 

This would also bring the operation’s semantics into line with Rekey Key Pair.

 

(I also note in passing that the link from the public page: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip to the KMIP 1.4 spec is broken)

 

Cheers,

Dr Warren Armstrong | Software Architect | QuintessenceLabs

E: wa@quintessencelabs.com | W: quintessencelabs.com

AU: Unit 1, Lower Ground | 15 Denison St | Deakin, ACT 2600 | T: +61 2 6260 4922

US: Suite 220 | 175 Bernal Rd | San Jose, CA 95119 | T: +1 650 870 9920

 

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]