[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [kmip-comment] Comments for KMIP Specification 1.0 Committee Draft 10 / Public Review 02 18 March 2010
hi - we'll review these comments (at least at a high-level) in our call today. regards, Bob -----Original Message----- From: Tony.Stieber@wellsfargo.com [mailto:Tony.Stieber@wellsfargo.com] Sent: Friday, May 14, 2010 9:42 PM To: kmip-comment@lists.oasis-open.org Subject: [kmip-comment] Comments for KMIP Specification 1.0 Committee Draft 10 / Public Review 02 18 March 2010 Comments for KMIP Specification 1.0 Committee Draft 10 / Public Review 02 18 March 2010 1.1 Terminology Although SP800-57-1 is referenced for definitions, the document's own Appendix D is not. p9 "Digest (or hash)" is defined using "hash function" which itself is not defined nor used elsewhere in the document. "Hashing algorithm" may also be known as "hash algorithm" or "hash function". Cryptographically hash functions have several secure if they have the described properties and p10 "Key management" is defined using "IV" which itself is not defined under terminology but is in Appendix D. "Key wrapping (wrapping)" is a method of encrypting and/or MACing/signing keys using a cryptographic algorithm (not key). Alternatively use SP800-57-1 "A method of encrypting keys (along with associated integrity information) that provides both confidentiality and integrity protection using a symmetric key." 2 Objects Line 184 A reference to "9.1.1.4 Item Value" where the object primitive object types are defined would be very useful. Line 237 Strike "typically" and add "and as large as 15,360 bits". Examples should not merely be typical, but also indicate edge cases; examples are often used as real world test cases and thus become part of the specification. Although some key lengths are less common, KMIP should still be able to support them. Line 238 TDES keys range from 112 to 192 bits (depending upon key length and the presence of parity bits). Line 239 AES keys are exactly 128, 192, or 256 bits in length. Examples should not merely be typical, but also indicate edge cases; examples are often used as real world test cases and thus become part of the specification. Although some key lengths are less common, KMIP should still be able to support them. Line 459 2.2.7 Secret Data Although secret data can be stored, there seems to be no provision for generation of secret data. How would arbitrary random data be created? Line 552 First instance of "PGP" is used, which may refer to a company, product, or protocol. The term "OpenPGP" refers to the IETF protocol standard in RFC 4880. Note that OpenPGP uses both binary and ASCII encoded format, either one or the other should be specified, or a mechanism for detecting or specifying both are needed. See also lines 562, 1117, 1134, 1757, 1790, 2036 Line 592 In the future if the SHA-256 requirement must be changed, how would it be specified and still retain backwards compatibility? Line 1355 Table 155: Destroy Response Payload Does a response imply that the object has been destroyed, or does the Result Reason clarify? Operational system may need significant time to destroy all copies of an object, especially those which were written to off-line storage. Some operational systems may not be able to destroy an object at all due to system limitations, such as write-only storage. If a server can attempt but cannot guarantee Destroy, how should it respond, Operation Pending/Feature not supported? If the server eventually succeeds should it respond as Success/Operation not supported? Lack of guaranteed Destroy is in conflict with the Line 1346 SHALL requirement, but it would still be useful to be able to attempt Destroy. Line 1693 A single bit error in a Boolean value may result a valid, but incorrect value. Consider setting multiple bits to indicate values, such as adding parity bits. Line 1697 Are nulls allowed at all? If not then it should be stated. A note about illegal UTF-8 encodings such as CO 80 as implemented in Java and other languages may be prudent as well. Line 1703 Consider encoding Intervals as Long Integers to match Date-Time values to avoid type conversion when doing offsets. 1769 9.1.3.2.12 Cryptographic Algorithm Enumeration Consider adding standardized symmetric ciphers such as Blowfish, Camellia, CAST5, RC2, RC4, Twofish, and the Elgamal encryption public key cipher. OpenPGP and TLS support most of these ciphers. Line 1771 9.1.3.2.13 Block Cipher Mode Enumeration CFB has variants. For example OpenSSL implements CFB1, CFB8, and CFB128 which is related using a shift register size for self-synchronization. http://www.openssl.org/docs/apps/enc.html Line 1757 9.1.3.2.6 Certificate Type Enumeration Consider adding SSH. Although SSH doesn't use certificates, it is a public key cryptographic system and some metadata is present in the public key. Line 1775 9.1.3.2.15 Hashing Algorithm Enumeration Consider adding MDC2, RIPE-MD/160, Tiger, Whirlpool. Although these hash algorithms are less common, they are found in some environments. Line 2036 PGP - Pretty Good Privacy specified in RFC 1991 RFC 1991 is now obsolete and has been replaced with OpenPGP RFC 4880 (via RFC 2440). Note also that "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation. OpenPGP refers to the IETF protocol standard. Line 2055 UTC UTC in English means "Coordinated Universal Time" not "Universal Time, Coordinated" which is an unofficial backronym. See http://www.nist.gov/physlab/div847/utcnist.cfm for an explanation under the question "Why is UTC used as the acronym for Coordinated Universal Time instead of CUT? Line 2056 UTF UTF-8 is specified in RFC 3629. By itself "UTF" is one of many Unicode transformational formats including UTF-8, UTF-16, UTF-32 which are very different from each other. -- Tony Stieber, Enterprise Security Architecture Team TGS - ESAT This message may contain confidential tony.stieber@wellsfargo.com and/or privileged information. If you tel:+1-612-667-4366 are not the addressee or authorized to fax:+1-612-667-7037 receive this for the addressee, you must MAC N9301-01J not use, copy, disclose, or take any Minneapolis, MN 55479 USA action based on this message or any 255 2nd Avenue South information herein. If you have received OpenPGP SHA1 fingerprint this message in error, please advise the 7EE5 B722 66FB 5960 2AAA sender immediately by reply e-mail and 2961 2FC0 1A80 1891 1480 delete this message. Thank you for your ------------------------ cooperation. -- This publicly archived list offers a means to provide input to the OASIS Key Management Interoperability Protocol (KMIP) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: kmip-comment-subscribe@lists.oasis-open.org Unsubscribe: kmip-comment-unsubscribe@lists.oasis-open.org List help: kmip-comment-help@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/kmip-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]