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
- From: Bruce Rich <brich@us.ibm.com>
- To: "Furlong, Judith" <judith.furlong@emc.com>
- Date: Wed, 22 May 2013 22:36:50 -0500
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
Bruce,
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.
Judy
From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org]
On Behalf Of Bruce Rich
Sent: Monday, May 20, 2013 6:28 PM
To: kmip@lists.oasis-open.org
Subject: [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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]