OASIS Key Management Interoperability Protocol (KMIP) TC

 View Only

  • 1.  Additional modifications to the KMIP specification and usage guide

    Posted 09-07-2009 07:56 
    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


  • 2.  Re: [kmip] Additional modifications to the KMIP specification and usageguide

    Posted 09-09-2009 01:50 

    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



  • 3.  RE: [kmip] Additional modifications to the KMIP specification andusage guide

    Posted 09-09-2009 16:48 
    




    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

    

    

    
From: Bruce Rich [mailto:brich@us.ibm.com]
    Sent: Tuesday, September 08, 2009 6:50 PM
    To: Fitzgerald, 
Indra
    Cc: kmip@lists.oasis-open.org
    Subject: Re: [kmip] 
Additional modifications to the KMIP specification and usage 
guide

    


    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


  • 4.  RE: [kmip] Additional modifications to the KMIP specification and usage guide

    Posted 09-09-2009 20:24 
    Regarding Item 10 -- the proposal for the new Certificate Issuer
attribute has been posted to the OASIS site -- see
http://www.oasis-open.org/committees/document.php?document_id=34119

Judy


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content