Comments for KMIP Specification 1.0 Committee Draft 10 / PublicReview 02 18 March 2010

[<Tony.Stieber@wellsfargo.com>]

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.