OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [kmip] Additional modifications to the KMIP specification and usage guide

Regarding Item 10 -- the proposal for the new Certificate Issuer
attribute has been posted to the OASIS site -- see


-----Original Message-----
From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com] 
Sent: Monday, September 07, 2009 3:55 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Additional modifications to the KMIP specification and
usage guide


Last week I uploaded two proposals. One proposal addresses the Create
Key Pair concern and the other addresses a few modifications to the Key
Value Type. Judy also uploaded the Revocation Reason Code proposal.
Please let us know if you have any comments.

During the numerous email exchanges with Sean and Judy, the following
modifications were discussed for the KMIP specification and Usage Guide:

1. In 2.1.7 and, add ECMQV. The transparent structure is the
same as for ECDH and ECDSA.

2. Add HMAC-SHA224 and HMAC-SHA384 to the list in

3. In, reshuffle and add SHA-224 to the list sequentially.

4. In, add "Unspecified" and "Remove from CRL" as revocation
reasons to line up with X.509/RFC5280. Remove "Revoked By creator" and
"Revoked By Administrator". See Judy's Revocation Reason Codes

5. Add an additional Key Value Type for ECPrivateKey. See the Key Value
Type proposal.

6. Add another Block Cipher Mode Enumeration: AESKeyWrapPadding (as
described in

7. Add another Block Cipher Mode Enumeration: XTS.

8. Add Certificate Request Type Enumeration CRMF to 

9. Change the attribute name 'Certificate Issuer' to 'Certificate

10. Add a new 'Certificate Issuer' attribute and include the Issuer DN
from the Issuer field of the certificate and any name formats from the
Issuer Alternative Name extension. A proposal will follow.

11. Delete the paragraph between Table 56 and Table 57 to avoid any
debate about setting the non-repudiation/digital signature bits.

12. Delete the following sentences from the spec: lines 852-854 and
951-952. We do not want to implicitly change the state of an object
after a re-key or a re-certify. The spec currently requires the
attributes of the old key (after a re-key) or certificate (after a
re-certify) to be changed similar to performing a Revoke with Revocation
Reason of Superseded (i.e., the object's state will be changed to

13. Include a mapping table in the Usage Guide, by taking table 191
(Recommended Curves for ECDSA and ECDH) and adding one additional column
to show how the bit string and the OID map to one another.

The following will only be changed if there is strong demand for these

14. Some parameters in the spec, such as D, P, and Q, should be lower
case letters. This would be inline with the NIST standards.

15. There has been discussions to split up 3DES to two algorithms: 2-key
3DES and 3-key 3DES. KMIP currently relies on the Cryptographic Key
Length attribute to determine whether it is 2-key or 3-key 3DES.

If anyone has any concerns with the above modifications, please let us


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]