RE: [kmip] KMIP spec clarifications for Pub/Priv Key and Certificate

Bruce

I was reviewing your email below to determine how to address your concerns. I believe we can groups the topics your raised into a few categories -- this might help to structure the proposals that are required to address this work.

Topic 1 covers the crypto length of cryptographic key materials such as public private keys:

For PublicKey and PrivateKey objects:
1) How do we represent the CryptographicLengths of these objects? The actual lengths of the cryptographic material may vary, depending on input parameters, but users thinking they have a 1024-bit key pair will be quite dismayed if our length calculator reports anything other than what was input to the generation process. This becomes more problematic for keys that arrive via Register, rather than CreateKeyPair.
Would propose that the lengths should be what the keypair generator would require as input, rather than a mechanical evaluation of the key itself. This may require some "fuzzy logic"...it's 1024-bitish...the spec should clearly instruct the server implementers what to do and what the limits might be on their flexibility.

I'm not sure if the topic requires the specification to be amended, but I do believe the guidance for how to deal with the fuzziness of asymmetric key lengths is needed. I believe the Usage Guide would be document where this guidance should be added. So a proposal for new section for the Usage Guide which describes how server implementations should handle crypto lengths is required to address this topic.

Topic 2 identifies the Signature Algorithm as a missing attribute for Certificate objects.

For Certificate objects:
1) Do all Certificates have a CryptographicAlgorithm? If so, what is it? None of the current algorithms seem to relate to the actual signature on the certificate.
Would propose that the algorithm of the Certificate is the algorithm of the enclosed public key.

We need a proposal for adding a new Signature Algorithm attribute into the KMIP specification that will allow us to capture algorithm types such as RSA with SHA-256 or DSA with SHA-1. I would suggest this is a general attribute that can be used in conjunction with certificate but also with other KMIP capabilities -- for example some of the new proposed work around trust establishment and message protection involve using signed messages and data so one will need to define the signature algorithm used in these cases as well.

Topic 3 discussed what is an appropriate 'Length' for a Certificate?

2) Do all Certificates have a CryptographicLength? If so, what is it? I do not believe that the bitlength of the encoded certificate is very interesting...
Would propose that the length of the Certificate is the length of the enclosed public key (as interpreted above).

Well certificates do have lengths in the ASN.1 sense, not specifically a Cryptographic Length. But certificates lengths vary greatly depending upon the number of extensions and the size of the subject public key contained in the certificate as well as the key size associated with the private key used by the CA to digitally sign the certificate (in other words the signature on the certificate varies in length).

I don't think we should make the Certificate length the same as that of the Subject Public Key that it contains. We already have attributes for recording the length of the public and private keys (see Topic 1 above).

Why do you believe that we need to specify a length for the Certificate and why can't it be the ASN.1 length of the Certificate?

Topic 4 is focused on how to translate the ASN.1 encoded names found with the certificate Subject and Issuer fields and the Subject Alternative Name and Issuer Alternative Name certificate extensions into the string format specified in the KMIP structures.

3) The CertificateSubject is a structure with the distinguished name of the subject, along with alternate names. Both of these are simply listed as text strings, but no mechanism is suggested for producing these strings from the underlying ASN.1 in the certificate. We may luck out on producing the former, but the latter is the road less travelled, and may produce more mismatches. (Not to mention that one may loses some context in knowing what kind of alternate name this was, if I remember correctly. Simply rendering as a text string may lose the fact that this alternate name was the DNS Name, for example).
Would propose that a TC member might take this one as a work item, if we are addressing only in 1.1. (And I suspect a production rule is really needed even for the dn.)
4) Similar comments regarding CertificateIssuer.

I'm not sure if changes are necessary to the KMIP specification that will depend upon the method and format used for the translation, but I certainly could see guidance being included in the Usage Guide. A proposal for a method for translating the different name formats from ASN.1 into the string format used in KMIP is required to address this topic. I would also suggest that whatever method of translation is used is also included as part of the Interop use cases developed for v1.1 of the KMIP specification.

Please let me know what you think of this categorization and let me know if I missed anything.

I'd also be interested in hearing comments from the rest of the TC members on these topics.

Thanks

Judy

From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: Wednesday, March 10, 2010 11:38 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] KMIP spec clarifications for Pub/Priv Key and Certificate

There are some portions of the KMIP spec that deal with Certificates and Public and Private keys that are still a little mysterious to me. It could be that these are addressed somewhere than the spec, and someone can point me to the relevant text. Failing that, we either need to clarify now, or potentially in the 1.1 spec/profile where Asymmetric comes into play

For PublicKey and PrivateKey objects:
1) How do we represent the CryptographicLengths of these objects? The actual lengths of the cryptographic material may vary, depending on input parameters, but users thinking they have a 1024-bit key pair will be quite dismayed if our length calculator reports anything other than what was input to the generation process. This becomes more problematic for keys that arrive via Register, rather than CreateKeyPair.
Would propose that the lengths should be what the keypair generator would require as input, rather than a mechanical evaluation of the key itself. This may require some "fuzzy logic"...it's 1024-bitish...the spec should clearly instruct the server implementers what to do and what the limits might be on their flexibility.

For Certificate objects:
1) Do all Certificates have a CryptographicAlgorithm? If so, what is it? None of the current algorithms seem to relate to the actual signature on the certificate.
Would propose that the algorithm of the Certificate is the algorithm of the enclosed public key.
2) Do all Certificates have a CryptographicLength? If so, what is it? I do not believe that the bitlength of the encoded certificate is very interesting...
Would propose that the length of the Certificate is the length of the enclosed public key (as interpreted above).
3) The CertificateSubject is a structure with the distinguished name of the subject, along with alternate names. Both of these are simply listed as text strings, but no mechanism is suggested for producing these strings from the underlying ASN.1 in the certificate. We may luck out on producing the former, but the latter is the road less travelled, and may produce more mismatches. (Not to mention that one may loses some context in knowing what kind of alternate name this was, if I remember correctly. Simply rendering as a text string may lose the fact that this alternate name was the DNS Name, for example).
Would propose that a TC member might take this one as a work item, if we are addressing only in 1.1. (And I suspect a production rule is really needed even for the dn.)
4) Similar comments regarding CertificateIssuer.

Bruce A Rich
brich at-sign us dot ibm dot com

kmip message