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

 

Judith Furlong | Principal Product Manager | EMC Product Security
Office | RSA , The Security Division of EMC | office: +1 508 249 3698 |
email: 

 

From: Bruce Rich
[mailto:] 

Sent: Wednesday, March 10, 2010 11:38 PM

To: 

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