This is the email trail that I mentioned during the KMIP TC call
today. Bruce and I would certainly like to hear from other TC members on this topic
especially about which topics below need to be addressed in the KMIP 1.1
release.
Thanks
Judy
Judith Furlong | Principal 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: Thursday, July 29, 2010 6:34 AM
To: Furlong, Judith; kmip@lists.oasis-open.org
Subject: RE: [kmip] KMIP spec clarifications for Pub/Priv Key and
Certificate
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