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] Groups - kmip-spec-v1.1-os-bar--re-everything.doc uploaded

Thanks for the feedback, Judy.

Text was added to rekey and rekeykeypair because the operations never said anything about regenerating/changing any key material.  The spec only talked about adjusting attributes and made an unexplained analogy to Create. If refreshing the key material is central to the operation, it deserves to be unambiguously called out.

On the ReCertify operation, we have two certificates in question, one the X509Certificate and the other the KMIP Certificate object.  I meant the latter, not the former.  And the attributes I mentioned were KMIP Attributes.  My intent was to deal with KMIP things, not the RFCs.

And you are right.  New terms need clear definitions.  I can supply text for that, as needed.

The statements in the spec about operations being required/optional were superceded by the introduction of profiles, and all such text should have been removed from the spec.  One asserts compliance to a profile, and the profile defines the required operations, objects and attributes.

You mentioned "extensiveness of changes"...I proposed new behaviors as "SHOULD", which mandates no immediate changes, and I am clarifying APIs around the behavior of existing testcases, so I do not subscribe to the idea that these are particularly extensive.

We may have time to discuss these tomorrow, but in case we don't, I thought you deserved a prompt response.

Bruce A Rich
brich at-sign us dot ibm dot com

From:        "Furlong, Judith" <judith.furlong@emc.com>
To:        Bruce Rich/Austin/IBM@IBMUS, "kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
Date:        05/22/2013 03:57 PM
Subject:        RE: [kmip] Groups - kmip-spec-v1.1-os-bar--re-everything.doc uploaded

I have been reading through the changes you are proposing the specification and also the slide deck that Tim posted on the subject.  I know we will be discussing this at tomorrow’s call but wanted to send on some comment ahead of time.
I know your intention is to clarify the text contained within the Specification, but some of the edits that you have made especially in the Rekey Key Pair and the Re-Certify area actually makes things more confusing and in some cases actually change the intended purpose of the operation.  For example, you introduced new terminology ‘key lifecycle attributes’ and ‘certificate lifecycle attributes’ which are not defined elsewhere in the specification.  How is a reader to know which ‘attributes’ fall into these categories or not?  In you edits to Rekey Key Pair you added new text “with new key material for each key in the pair” isn’t this stating the obvious – asymmetric key pairs are mathematically related - you cannot generate/regenerate the public/private parts separate from each other.  In the Re-certify edits you talk about using this operation to “simultaneously adjust certificate lifecycle attributes in the replacement certificate”.  This changes the intent of this function.  Re-Certify corresponds to Certificate Renewal in the RFC3647/RFC4949 terms which is the issuance of a new certificate to a subject where the only things that change are the serial number and certificate validity dates.  While validity dates could certainly be referred to as ‘certificate lifecycle attributes’ there may be other attributes that one might need to change (like private key validity which goes into a certificate extension) that could also be categorized as ‘certificate lifecycle attributes’.  To change a certificate extension value one would be doing a Certificate Update (not a Certificate Renewal) and in KMIP one does that by using the Certify operation. {Note this is all covered in Section 3.39 of the Usage Guide – I know you have raised concerns that the UG is non-normative, however it does contain info on what folks were thinking at the time certain functionality was added into the KMIP Specification.  We could always move clarifying text in the UG into the Spec to make it normative.}
I also don’t understand the edit to Certify/Re-Certify removing the text that indicated that these are optional operations for the KMIP server to support.  These are not the only operations marked as optional in the specification and the text you removed is factual.
Given where we are in the KMIP 1.2 effort and the extensiveness of your changes, where it is going to take some time to work through revisions that will be acceptable to all, I really feel that these changes are not something that we should take on for KMIP 1.2.  Instead we should address them as one of the first set of work items for KMIP vNext.  I would suggest that we also split these up into multiple topics – not just the re* edits but also look to improve the error cases/messages, find a consistent way to mark operations as optional or not, etc.
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Bruce Rich
Monday, May 20, 2013 6:28 PM
[kmip] Groups - kmip-spec-v1.1-os-bar--re-everything.doc uploaded

Submitter's message
Building off the rekey and rekeykeypair proposal, here's the "fools rush in where angels fear to tread" refactoring of all the re* operations (rekey, rekeykeypair, recertify) to narrow the APIs in the hope of simplifying them enough to facilitate interoperability. And yes, I even removed some text from certify. I do not believe that any testcases were injured in the process of this surgery.
-- Mr. Bruce Rich

Document Name: kmip-spec-v1.1-os-bar--re-everything.doc

Update to 1.1 spec to refactor the re* operations.

Download Latest Revision
Public Download Link

Submitter: Mr. Bruce Rich
: OASIS Key Management Interoperability Protocol (KMIP) TC
: Drafts
Date submitted
: 2013-05-20 15:27:48


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