kmip message
[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
- From: Bruce Rich <brich@us.ibm.com>
- To: <judith.furlong@emc.com>
- Date: Tue, 10 Apr 2012 15:40:34 -0500
Judy,
The heart of my observation on the profile
was that "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".
We should not have an ill-defined entity
as a required-to-implement object in a profile, and it's doubly-bad to
also lack a use-case documenting such usage. We could have documented
what we meant by asymmetric RAW format keys and illustrated in the usage
guide, and that would have been another way to address the issue. Symmetric
RAW keys are unencoded binary (no DER, no BER, no OID, etc), but I have
no idea what asymmetric RAW keys would be, so I would have no idea how
to interoperate with another party that claimed such support.
BTW, I think I agree with the part of
Sean's comments that deal with transparent keys, which are the bulk of
his comments. Sean did not say much about RAW keys, and I think their
inclusion in the profile predates his comments. I still do not agree
that RAW is a format that is well-defined for asymmetric keys, and in the
3 or 4 months that my comments have been part of the public record, no
one has put forward a proposal or a reference that would clarify things.
Bruce A Rich
brich at-sign us dot ibm dot com
From:
<judith.furlong@emc.com>
To:
Bruce Rich/Austin/IBM@IBMUS,
<kmip@lists.oasis-open.org>
Date:
04/04/2012 03:04 PM
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-----
From: Sean Turner [mailto:turners@ieca.com]
Sent: Thursday, February 04, 2010 9:30 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Asymmetric Key Profiles and Associated Proposed Changes
to KMIP
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]
Sent: Wednesday, February 08, 2012 11:40 AM
To: kmip-comment@lists.oasis-open.org
Subject: [kmip-comment] Issue with KMIP 1.1 Profiles document
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.
Bruce A Rich
brich at-sign us dot ibm dot com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]