[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip-comment] Issue with KMIP 1.1 Profiles document
Bruce, When we were reviewing the comments on the KMIP spec at the last KMIP TC call (March 22nd) your comment about the RAW key format in the Asym Profiles prompted a vague recollection on my part that this was added to the Asym Profile as a result of some comments. So I went back through versions of the profile and the reflector to see if I could when this format was added and what prompted the addition -- I was successful in finding the history on the topic and I've pasted the email from Sean Turner which discusses the proposed change to the profile and the rationale for the change. I'm not sure that we want to change the decision made at the last KMIP TC call to remove the RAW key format from the profile but I wanted to at least provide the background to the reason for why it was included to the profile. There is a side effect for dropping support of the RAW key format and going with only the PKCS1 format -- This means that KM Servers complying with the profiles will only need to support RSA asymmetric key material (PKCS1 only covers RSA asymmetric key material) which at this point in time seems to be reasonable. If there is a desire to mandate support for non-RSA asymmetric key material (e.g. DSA, D-H) then we'd need to either retain the RAW format or specific other key formats (e.g. Transparent or Opaque) to allow non-RSA key material to be passed. Judy ************************ -----Original Message----- This has also got me to thinking about whether the key format types for the RSA private and public keys should be PKCS1 and Raw not Transparent RSA private and Transparent RSA public. My thinking is that in the basic store cases the client generated their own keys and then uploaded them. The format the client is going have is probably PKCS1 (RSAPrivateKey) and then probably either SubjectPublicKeyInfo or RSAPublicKey.* I think that the Transparent RSA public/private keys are probably only going to be support when the KMIP Server makes the keys and then we'd want to give the client the option to pick how they'd want to receive them. I'm proposing that we make the following changes (5 in total) to the proposal: Change 1: 1.1.2 Conformance as a Basic Asymmetric Key Store 2.a: OLD: i. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) ii. Transparent RSA public key ([KMIP-Spec] 2.1.7.5) NEW: i. Raw ii. PKCS1 Change 2: 1.2.2 Conformance as a Basic Asymmetric Key and Certificate Store 2.a: OLD: i. PKCS1 ii. X.509 iii. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) iv. Transparent RSA public key ([KMIP-Spec] 2.1.7.5) NEW: i. Raw ii. PKCS1 iii. X.509 Change 3: 1.3.2 Conformance as a Basic Asymmetric Key Foundry and Server 2.a: OLD: i. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) ii. Transparent RSA public key ([KMIP-Spec] 2.1.7.5) NEW: i. Raw ii. PKCS1 iii. X.509 iv. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) v. Transparent RSA public key ([KMIP-Spec] 2.1.7.5) Change 4: 1.4.2 Conformance as a Basic Certificate Server 2.a OLD: i. PKCS1 ii. X.509 iii. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) iv. Transparent RSA public key ([KMIP-Spec] 2.1.7.5) NEW: i. Raw ii. PKCS1 iii. X.509 Change 5: 1.5.2 Conformance as a Basic Asymmetric Key Foundry and Server OLD: i. PKCS1 ii. X.509 iii. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) iv. Transparent RSA public key ([KMIP-Spec] 2.1.7.4) NEW: i. Raw ii. PKCS1 iii. X.509 iv. Transparent RSA private key ([KMIP-Spec] 2.1.7.4) v. Transparent RSA public key ([KMIP-Spec] 2.1.7.4) spt * OpenSSL spits out SubjectPublicKeyInfo if you extract the public key from the RSAPrivateKey structure. Sean Turner wrote: > Curious what others think about requiring support for PKCS1 instead of > Transparent RSA public/private in the Basic Asymmetric Key Store and the > Basic Asymmetric Key Foundry and Server profiles? Maybe we should > switch because when you generate RSA keys with things like OpenSSL it > automatically spits out the PKCS1 format. It would be less work for an > implementation to be compliant. > > spt > > Furlong_Judith@emc.com wrote: >> At yesterday's OASIS TC call I promised to send out an email to >> summarize the KMIP Asymmetric Key Profiles body of work and remind all >> of you on the committee to review and provide comments on the profiles >> document and the associated modification proposals via this email list. >> >> The "Basic Asymmetric Key Profiles" document was posted on November 5, >> 2009 to the KMIP OASIS TC site. >> Please see >> http://www.oasis-open.org/committees/document.php?document_id=35010 >> >> The Basic Asymmetric Key Profiles document includes five separate >> profiles namely: >> >> 1. Basic Asymmetric Key Store (section 1.1): Key pairs are generated >> external to the server and are sent to the server for storage (perhaps >> for key escrow reasons or for ease of distribution to other entities). >> This profile only requires support for the Register operation. No >> support for certificates imposed on server. >> >> 2. Basic Asymmetric Key and Certificate Store (section 1.2): Key pairs >> and certificates are generated external to the server and are sent to >> the server for storage (perhaps for key escrow reasons or for ease of >> distribution to other entities). This profile only requires support for >> the Register operation. [May need to make vaulting of dig sig/non-rep >> only keys optional to avoid controversy over whether this type of keys >> should be held away from the owner of the keys.] >> >> 3. Basic Asymmetric Key Foundry and Server (Section 1.3): 3. Key >> pairs (but not certificates) are generated by the server. This profile >> only requires support for the Create Key Pair and Rekey (which is >> modified supports asymmetric keys) operations. >> >> 4. Basic Certificate Server (Section 1.4): Key pairs are generated >> external to the server (aka locally at the client) but the client would >> contact the server to request a certificate to be generated -- either >> directly by the KM or the KM proxies the request to a CA. This profile >> would support Certify and Re-certify. [Optionally this profile could >> support register for the key pairs.] >> >> 5. Basic Asymmetric Key Foundry and Certificate Server (Section 1.5): >> Key pairs are generated by the server and the server would also handle >> getting the corresponding certificates generated (either using its own >> capabilities or by contacting a CA). This profile would include the >> Create Key Pair, Rekey (which is modified supports asymmetric keys), >> Certify and Re-certify operations. >> >> >> In support of the Basic Asymmetric Key Profiles document two proposals >> for modifying the KMIP Specification and supporting documents (e.g. >> Usage Guide) have been submitted: >> >> 1. Proposal for Supporting Rekey of Asymmetric Key Pairs was >> submitted on December 4, 2009 >> Please see >> http://www.oasis-open.org/committees/document.php?document_id=35444 >> >> The proposal describes a new KMIP operation for rekeying asymmetric key >> pairs and also >> outlines changes to the KMIP Spec and KMIP Usage Guide in light of the >> addition of this new operation. >> >> 2. Proposal for Making Submission of a Certificate Request in the >> Certify and Re-certify Operations Optional was submitted on December 3, >> 2009 >> Please see >> http://www.oasis-open.org/committees/document.php?document_id=35434 >> >> This proposal makes the inclusion of the Certificate Request attribute >> and the associated Certificate Request Type attribute in the Certify and >> Re-certify operations as non-mandatory. >> >> If anyone has questions please feel free to post to this mailing list or >> contact me directly. >> >> Judy Furlong >> >> |Principal Product Manager|EMC Product Security Office|RSA -The Security >> Division of EMC| >> |t: 508 249 3698|e: Furlong_Judith@emc.com| >> >> --------------------------------------------------------------------- >> 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 >> > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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 Judith Furlong | Consultant Product Manager | EMC Product Security Office | RSA , The Security Division of EMC | office: +1 508 249 3698 | email: Judith.Furlong@emc.com From: Bruce Rich [mailto:brich@us.ibm.com] The new asymmetric profiles all call out RAW as one of the REQUIRED key formats. This may be a copy-and-paste carry-over from the symmetric profiles where those keys do in fact have a RAW format. The PKCS1 format itself is so raw that you need the context or an attribute to tell you whether it's a public key or private, so asserting that one also needs to support asymmetric RAW format keys begs further definition. Furthermore, the use cases document shows no testcase that demonstrates interop with RAW format for asymmetric keys, so it is doubtful that those companies that need to attest to their support of the profile can actually point to any evidence of said support for asymmetric RAW format. To address this issue, I would suggest either that RAW format for asymmetric keys is defined (possibly in the protocol spec) and usage is illustrated in the use cases document, or that the RAW key format requirement is removed from the profiles document in sections 5.6.2, 5.7.2, 5.8.2, 5.9.2, 5.10.2, 5.16.2, 5.17.2, 5.18.2, 5.19.2, and 5.20.2. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]