[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
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 Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]