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 andusage guide
- From: "Fitzgerald, Indra" <indra.fitzgerald@hp.com>
- To: Bruce Rich <brich@us.ibm.com>
- Date: Wed, 9 Sep 2009 16:47:31 +0000
Hi Bruce,
We would be including ECMQV for completeness. Adding this
key structure to the spec should not mandate vendors to implement or support
this transparent key structure. Similarly, we have included the split key object
in the spec, but do not expect all vendors to support this
object.
Perhaps we need to include a note in Matt's Conformance
proposal to clarify that vendors are not expected to support all the Transparent
Key Structures listed in the spec, but only those that are required by the
applicable profile.
Regards,
Indra
One minor quibble: I'm a
little reluctant to see #1, the ECMQV Key Structure type, given the IPR claims
around the algorithm. I'd really be queasy if it were a
mandatory-to-implement. If no one else objects, I guess it's OK. But
it feels like the camel's nose is in the tent.
Bruce A Rich
brich at-sign us dot ibm dot
com
From:
| "Fitzgerald, Indra"
<indra.fitzgerald@hp.com>
|
To:
| "kmip@lists.oasis-open.org"
<kmip@lists.oasis-open.org>
|
Date:
| 09/07/2009 02:55 AM
|
Subject:
| [kmip] Additional modifications to the
KMIP specification and usage guide |
All,
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
9.1.3.2.11, add ECMQV. The transparent structure is the same as for ECDH and
ECDSA.
2. Add HMAC-SHA224 and HMAC-SHA384 to the list in
9.1.3.2.11.
3. In 9.1.3.2.14, reshuffle and add SHA-224 to the list
sequentially.
4. In 9.1.3.2.17, 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
proposals.
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 http://www.ietf.org/id/draft-housley-aes-key-wrap-with-pad-04.txt)
7. Add another Block Cipher Mode Enumeration: XTS.
8. Add
Certificate Request Type Enumeration CRMF to 9.1.3.2.20.
9. Change the
attribute name 'Certificate Issuer' to 'Certificate Identifier'.
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 Deactivated).
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 changes.
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
know.
Regards,
Indra
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]