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: Groups - Rekey strawperson uploaded

Submitter's message
As I mentioned on the call last week, one of the work items that I think would be helpful is to crisp up the specification of the Rekey, RekeyKeyPair, and ReCertify APIs to remove some of the ambiguity, and hopefully arrive at more interoperable implementations.

The specification left portions of these operations at too high a level, and although we have test cases for the most common expected scenarios, there are many questions that one may ask for which the spec has no clear answer.

I've been discussing this proposal (off-list) a bit, and thought it might be more helpful to bring it to the list and give a concrete illustration of what I'm thinking about.

The attached note links to the my draft revamp of Rekey. Perhaps this would allay some fears (or not) and show where I am trying to go.

Please note that where I have put in new behavior, it is designated SHOULD, not SHALL, so it is less prescriptive than I would like, but grandfathers current implementations.

What I did was to narrow the scope of Rekey to just the key and its lifecycle, so although the Attribute-Template allows anything to go in, I narrowed the set of things the server would do.
I talked about the relationship between the attributes of the current key and the input attributes.
I removed the analogy to Create, as it seemed too high a level of analogy to be useful.
I allowed the UsageLimit to be adjusted for the new key, as it fits under the umbrella of key lifecycle.
I fixed the text so that TestCase 9.4 is clearly legal, whereas before it seemed to violate the specific text of the spec.

Now we have a clear-enough specification to answer such questions as:
Q1) Can I change the algorithm or keylength on a Rekey...it's a required input on Create, and Rekey is supposed to be "analogous"...
A1) No, Rekey only refreshes the key material and deals with lifecycle issues.

Q2) What happens if I pass in a new value for a multi-valued attribute as part of my Rekey request? Will it get applied to the new key?
A2) The server SHOULD ignore it.

Q3) What happens if I pass in a new value for a single-valued attribute (like ContactInformation) as part of my Rekey request? Will it get applied to the new key?
A3) The server SHOULD ignore it. The caller SHOULD addAttribute/modifyAttribute after the Rekey

Q4) What happens if I pass in a different UsageLimit as part of my Rekey request? Will it get honored?
Q4) Yes. Such an attribute relates to the new key material, and cannot be modified later, so the server SHALL process it now.

Q5) TestCase 9.4 shows the passing of Activation, ProcessStart, ProtectStop and Deactivation, but no offset was supplied. Lines 1155-6 of the 1.1 spec say: "If no Offset is specified, the Activation Date, Process Start Date, Protect Stop Date and Deactivation Date are copied from the existing key". Yet in the testcase the resulting key shows that the new values for these attributes were applied. Why is this not an error?
A5) The spec now clearly allows the lifecycle attributes to be overriden if offset is omitted.

Bruce A Rich
brich at-sign us dot ibm dot com
-- Mr. Bruce Rich
Document Name: Rekey strawperson

A concrete talking-point update to Rekey
Download Latest Revision
Public Download Link

Submitter: Mr. Bruce Rich
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Folder: Drafts
Date submitted: 2013-05-09 11:31:59

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