kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [kmip] KMIP spec clarifications for Pub/Priv Key and Certificate
- From: Bruce Rich <brich@us.ibm.com>
- To: <Furlong_Judith@emc.com>, kmip@lists.oasis-open.org
- Date: Thu, 29 Jul 2010 05:33:39 -0500
Judy,
Thanks for taking some time to look
into these items.
Your proposal to put a lot of this into
the Usage Guide leaves me a little edgy. With server-to-server looming
in the background, I would like some assurance that cryptographic objects
will look the same no matter what server is currently housing them, and
Usage Guide commentary may not be sufficient to accomplish the "I"
in KMIP.
I am also a little concerned that no
one else has joined this discussion, as it would be good to have more eyes
on this.
Here are my topic-by-topic responses:
Topic 1...cryptographic length of public/private
keys.
OK,
a re-reading of the current text in the spec would indicate that we're
probably good, if we include a fuzziness discussion to the UsageGuide
Topic 2...cryptographic algorithm of
certificates
Agree
that signing algs need to be added. I'm reluctant to see them mixed
in with key algs, and having enums for all possible signing combinations
seems clunky. This almost feels like CryptographicParameters, a composite
object, except we have a Digest plus a key. Perhaps a new SigningParameters
composite attribute?
Topic 3...cryptographic length of certificates
One
admittedly non-normative table indicates that Certificates have a cryptographic
length, so it would be good to say what it is. I'm OK with either
the encoded length in bytes (although other objects have bits) or the length
of the enclosed public key in bits or a new attribute that just has ByteLength
(the certificate body might not all be considered "cryptographic",
so ByteLength would sidestep that point, and is somewhat self-describing).
And I'm not even going to bring up the octet vs byte controversy
again. Oops...
Topic 4...ASN.1 to String conversions
Do
not think that these were correctly typed as String in the original spec,
so am really reluctant to relegate this to the Usage Guide. I don't
see how we can avoid at least having an enum for the type, as well as some
mechanism for ASN.1-to-string for the value. If we go that route, that
would be a spec change for sure.
Bruce A Rich
brich at-sign us dot ibm dot com
From:
<Furlong_Judith@emc.com>
To:
Bruce Rich/Austin/IBM@IBMUS,
<kmip@lists.oasis-open.org>
Date:
07/09/2010 03:29 PM
Subject:
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: Furlong_Judith@emc.com
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]