[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Public Review of KMIP Specifications
Hello Mary, I was trying to understand the process of how we submit comments as members. I asked this yesterday and didn't hear to use JIRA. I expect many people to review this thoroughly for the first time and submit many comments. We have been informal in how we resolved comments up until now and I think this could be problematic if we are inundated with hundreds of comments like in Indra's attached email. If these comments or any comments were entered in JIRA, I never heard about it. How do we use the JIRA issue tracking system? How do we make documents a "component"? Are the editors going to enter JIRA issues for each comment from non-TC members? Thanks, Scott -----Original Message----- From: Mary McRae [mailto:mary.mcrae@oasis-open.org] Sent: Thursday, December 10, 2009 1:51 PM To: Scott Kipp Cc: kmip@lists.oasis-open.org; OASIS TAB Subject: Re: [kmip] Public Review of KMIP Specifications Hi Scott, I'm not sure who you're addressing your message to. Non-TC members will submit their comments via the TC comment list as required by the OASIS TC Process. TC members can make use of the JIRA issue tracking system - just make each of the documents a 'component' and that will allow for easy sorting/filtering. For comments received via the comment list, someone on the TC would need to create a corresponding issue. The ODF TC actually posts a periodic note to the comment list which lets people know that their comments will be entered into the issues tracker and that they can track their status themselves. I haven't seen this to be a big issue with most TCs; maybe you're anticipating many more issues to be raised. In any case, the TC is required to produce a comment resolution log which includes the comment submitter, brief description of the issue, and its resolution before moving forward to the next level of approval. Again, this can be easily generated out of JIRA. I hope that helps. Regards, Mary On Dec 10, 2009, at 12:49 PM, Scott Kipp wrote: > Dear KMIP Commenters, > > I'm involved in five standards organizations and there is no standard way to submit comments across these bodies. Since we are in the process of reviewing 4 documents by tens of companies, tracking and resolving comments (probably hundreds and possibly thousands) in many formats across the four documents could be very time consuming for the group and especially the editors. If some companies submit comments in pdf, others in word and some in html, we will have a difficult time tracking the resolution of comments. > > I propose that we use the attached spreadsheet to submit comments against the pdf version of the document. The spreadsheet has a separate worksheet for each document so that each editor can individually address their comments. > > The comments are split into technical and editorial. Editorial comments are basic grammatical corrections that editors don't need the group input on. Technical comments require the groups input and approval for inclusion. > > I have provided two sample comments to explain the process. You should add the name of your company in place of the "Company Name" in the first column so that you will be able to track your comments through the process. Then label the comment technical (T) or Editorial (E) in the second column. The next three columns identify the location of the comment. Then you need to add the description of the comment and the proposed solution of the comment. > > During comment resolution, the editor or chair of the document will include the resolution and we'll be able to track and understand what happened to the comment. This tracking is very important because I have been in some standards that take a year to resolve comments and this spreadsheet helps track the comments down after many moons. There is also a Status worksheet that can summarize how many technical comments we have and how many have been resolved or deferred. > > I hope we can resolve our comments quicker than many months and this spreadsheet will help. This is one way to track comments and I am open to tracking them in a different manner. We should agree to use one method. > > Any other suggestions or can we agree to use this spreadsheet? > > Thanks, > Scott Kipp > Standards Jockey > > -----Original Message----- > From: Mary McRae [mailto:mary.mcrae@oasis-open.org] > Sent: Monday, November 30, 2009 10:48 PM > To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org > Cc: kmip@lists.oasis-open.org; OASIS TAB > Subject: [kmip] Public Review of KMIP Specifications > > To OASIS members, Public Announce Lists: > > The OASIS Key Management Interoperability Protocol (KMIP) TC has recently approved the following specifications as Committee Drafts and approved them for public review: > > Key Management Interoperability Protocol Specification Version 1.0 > Key Management Interoperability Protocol Profiles Version 1.0 > Key Management Interoperability Protocol Use Cases Version 1.0 > Key Management Interoperability Protocol Usage Guide Version 1.0 > > The public review starts today, 1 December 2009, and ends 30 January 2010. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. We also welcome interested parties to join the KMIP TC as it continues work on the next version of KMIP in such areas as asymmetric profiles, server-to-server communication, and other important areas. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. > > More non-normative information about the specification and the technical committee may be found at the public home page of the TC at: > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at: > http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip. > > Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at: > http://lists.oasis-open.org/archives/kmip-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. > > The specification document and related files are available here: > > Key Management Interoperability Protocol Specification Version 1.0 > Editable Source: (Authoritative) > http://docs.oasis-open.org/kmip/spec/v1.0/cd06/kmip-spec-1.0-cd-06.doc > PDF: > http://docs.oasis-open.org/kmip/spec/v1.0/cd06/kmip-spec-1.0-cd-06.pdf > HTML: > http://docs.oasis-open.org/kmip/spec/v1.0/cd06/kmip-spec-1.0-cd-06.html > > > Key Management Interoperability Protocol Profiles Version 1.0 > Editable Source: (Authoritative) > http://docs.oasis-open.org/kmip/profiles/v1.0/cd04/kmip-profiles-1.0-cd-04.doc > PDF: > http://docs.oasis-open.org/kmip/profiles/v1.0/cd04/kmip-profiles-1.0-cd-04.pdf > HTML: > http://docs.oasis-open.org/kmip/profiles/v1.0/cd04/kmip-profiles-1.0-cd-04.html > > > Key Management Interoperability Protocol Use Cases Version 1.0 > Editable Source: (Authoritative) > http://docs.oasis-open.org/kmip/usecases/v1.0/cd05/kmip-usecases-1.0-cd-05.doc > PDF: > http://docs.oasis-open.org/kmip/usecases/v1.0/cd05/kmip-usecases-1.0-cd-05.pdf > HTML: > http://docs.oasis-open.org/kmip/usecases/v1.0/cd05/kmip-usecases-1.0-cd-05.html > > > Key Management Interoperability Protocol Usage Guide Version 1.0 > Editable Source: (Authoritative) > http://docs.oasis-open.org/kmip/ug/v1.0/cd05/kmip-ug-1.0-cd-05.doc > PDF: > http://docs.oasis-open.org/kmip/ug/v1.0/cd05/kmip-ug-1.0-cd-05.pdf > HTML: > http://docs.oasis-open.org/kmip/ug/v1.0/cd05/kmip-ug-1.0-cd-05.html > > > OASIS and the KMIP TC welcome your comments. > > > Mary P McRae > Director, Standards Development > Technical Committee Administrator > OASIS: Advancing open standards for the information society > email: mary.mcrae@oasis-open.org > web: www.oasis-open.org > twitter: @fiberartisan #oasisopen > phone: 1.603.232.9090 > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > <KMIP Comments Template.xls>--------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--- Begin Message ---
- From: "Fitzgerald, Indra" <indra.fitzgerald@hp.com>
- To: "kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
- Date: Tue, 30 Jun 2009 17:10:26 -0600
All, During last weeks call, I was asked to send out the comments I exchanged with Robert. Below is a list of outstanding concerns and comments. Please let us know if you have any comments, agree or disagree, and if you would like to see additional clarification and examples in the spec or Usage Guide. Regards, Indra 1. p.14, 2.1.7.1: Clarify in the Usage Guide that Transparent Symmetric Key is essentially the same as Raw key type. Raw key type allows clients to avoid keeping the octet key in a structure. 2. p.22,3.2, line 352: Name Type includes extension for vendor-specific implementation. Vendor-specific attributes or operations are avoided in the spec and Usage Guide. For example, the Usage Guide specifies that if clients require unique identifiers in a special form, out-of-bound registration/configuration can be used to communicate this to the server. We should use a similar approach for server-created Application Data (as part of the Application Specific Information attribute). Instead of relying on implied, side-effect functionality, the spec should either make server-generated Application Data vendor-specific or require clients to explicitly request the server to generate Application Data by setting an option specific for this purpose. As currently specified (in the proposal), the attribute is confusing, complex, and will lead to interoperability issues. 3. Secret Data is considered to be a Cryptographic Object. The problem is that this may not always be the case. The client could register a password without using it for crypto purposes (such as key derivation). If Secret Data is considered to be a Crypto Object, certain attributes must always have a value. For example, if the password is just an ordinary password string and not used for key derivation, clients are still expected to set the Crypto Usage Mask to 00000000000000 (the spec specifies that this attribute must always have a value for Cryptographic Objects). This can get confusing and it would make sense to clarify this in the Usage Guide. 4. Provide additional guidance and clarification on how to specify Custom Attributes in a message. If required, an example could be provided in the Usage Guide. The spec currently states the following: "The tag type Custom Attribute cannot identify the particular attribute; hence, such an attribute can only appear in an Attribute Structure with its name as defined in Section 2.1.1." We should clarify that Attribute Name (as defined in Section 2.1.1) should be x-<custom attribute> or y-<custom attribute> and not Custom Attribute. The table should be updated accordingly. 5. p.45, 4.2, line 774: Cryptographic Length should be a required attribute for the Create operation. It is required by Register, Create Key Pair, and Derive Key. 6. p.49, 4.3: Should we provide guidance on how to register a key pair? During Create Key Pair, the server is expected to set certain attributes. For example, the link attribute will be set and certain attributes, such as Cryptographic Parameters, must be set to the same value for both public and private key. All this occurs transparently and clients may not realize that the server is setting these attributes. It may be helpful to include an example of registering a key pair using the Register operation in the Usage Guide. 7. p.49, 4.4, line 831: States that during a re-key, attributes are changed similarly to performing a Revoke with Revocation Reason of Superseded. According to p. 34, line 562, issuing a Revoke with Revocation Reason other than Compromised causes the state to transition from Active to Deactivated state. This will not work for most clients. Protect Stop Date usually occurs prior to reaching the Deactivation Date. Clients would usually perform a rekey, expect the new key to be used for protect purposes, and continue using the old key for processing purposes until it reaches the Deactivation Date. 8. p.54, 4.6: Three concerns regarding Certify and Re-certify: a. The table needs to include the CA to be used to sign the Certificate Request. We are currently assuming that there exists only one CA on the server, unless the Certificate Issuer attribute is supposed to be used for this purpose. If this is the case, we need to add clarification. If this is not the case, this needs to be discussed. Should we allow the CA name to be specified or do we require one of the following: CA public key UID, CA private key UID, or certificate UID? b. Creating a Certificate Request requires the private key. We are assuming that the client stores the key pair outside of the server and has the capability to create a Certificate Request. Should the protocol cover the case where the key pair is stored by the server and the Certificate Request can be created by the server? This would not only be more convenient for clients, but would also benefit dumb clients who do not have the capability to create Certificate Requests. c. Line 918 states that if the information in the Certificate Request conflicts with the attributes specified in Template-Attribute, the information in the Certificate Request takes precedence. Should we provide additional guidance/clarification in the Usage Guide? This may affect Certificate Subject, Cryptographic Algorithm, and Crypto Length. I am not sure what other attributes can be explicitly specified under Attributes inside Certificate Request. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]