Sean
Regarding #1 -- I missed taking out the Transparent RSA key formats from
the list -- I just posted an update with this corrected. Transparent
RSA key formats only remain in the two Key Foundry related profiles.
Judy
Original Message-----
From: Sean Turner [mailto:turners@ieca.com]
Sent: Friday, March 05, 2010 8:50 AM
To: Furlong, Judith
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Asymmetric Key Profiles and Associated Proposed
Changes to KMIP
Judy,
On #3 - you're right.
One #1 - I was actually suggesting replacing Transparent RSA
public/private key with Raw/PKCS1. I can't see an entity that generates
their own key pair converting from what the defacto output is to the
KMIP format. But, I'm not going to fall on my sword on this, as there
may be from scratch implementations do.
spt
Furlong_Judith@emc.com wrote:
> Sean
>
> I've incorporated your proposed changes in the revision of the Basic
> Asymmetric Key Profiles document that I just posted with one noted
> exception.
>
> Ref Change 3 below -- This was for the Basic Asymmetric Key Foundry
and
> Server profile where no certificates are generated. Therefore I did
not
> add X.509 as a Key Format Type.
>
> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>
>