RE: [kmip] Locating Certificates Using KMIP

Tim

I read through the PKCS#11 text again -- you indicated that KMIP was missing the following….

The items contained there are what are used for the equivalent of the Locate operation in a PKCS#11 context. We are missing

The CKA_ISSUER and CKA_SERIAL_NUMBER attributes are for compatibility with PKCS #7 and Privacy Enhanced Mail (RFC1421). Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki.

The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY attributes are used to store the hashes of the public keys of the subject and the issuer. They are particularly important when only the URL is available to be able to correlate a certificate with a private key and when searching for the certificate of the issuer.

In KMIP we have a Certificate Issuer attribute which can be used as the equivalent for CKA_ISSUER. Likewise we have the Certificate Identifier attribute in KMIP which contains the Issuer Name and Serial Number for the certificate. This attribute could be used to substitute for the CKA_SERIAL_NUMBER.

As to the hashes of the keys KMIP has the Digest attribute which could be applied to keys or certificate objects. If you are searching for a specific Subject or Issuer Public key in a KM Server wouldn't you be doing the locate against the stored keys and not the stored certificates? If you need the associated certificate for a specific public key then you use the Link attribute to find it.

Judy

From: Tim Hudson [mailto:tjh@cryptsoft.com]
Sent: Wednesday, August 03, 2011 5:45 PM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Locating Certificates Using KMIP

On 4/08/2011 6:10 AM, judith.furlong@emc.com wrote:

I haven't seen anyone post use cases for how they wish to locate Certificates to the reflector so I figured I'd start the discussion by looking at what we can do today with the KMIP v1.0 specification and what we may be able to do with some proposed changes for v1.1.

Looking at PKCS#11 is rather useful in this context - see http://www.cryptsoft.com/pkcs11doc/v220/ and specifically http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__6__CERTIFICATE__OBJECTS.html which outlines the attributes associated with X.509 certificates.

The text out of that section is reproduced below to aid in the discussion.

X.509 certificate objects (certificate type CKC_X_509) hold X.509 public key certificates. The following table defines the X.509 certificate object attributes, in addition to the common attributes defined for this object class:

Table 24, X.509 Certificate Object Attributes

Attribute	Data type	Meaning
CKA_SUBJECT¹	Byte array	DER-encoding of the certificate subject name
CKA_ID	Byte array	Key identifier for public/private key pair (default empty)
CKA_ISSUER	Byte array	DER-encoding of the certificate issuer name (default empty)
CKA_SERIAL_NUMBER	Byte array	DER-encoding of the certificate serial number (default empty)
CKA_VALUE¹	Byte array	BER-encoding of the certificate
CKA_URL³	RFC2279 string	If not empty this attribute gives the URL where the complete certificate can be obtained (default empty)
CKA_HASH_OF_SUBJECT_PUBLIC_KEY⁴	Byte array	SHA-1 hash of the subject public key (default empty)
CKA_HASH_OF_ISSUER_PUBLIC_KEY⁴	Byte array	SHA-1 hash of the issuer public key (default empty)
CKA_JAVA_MIDP_SECURITY_DOMAIN	CK_ULONG	Java MIDP security domain: 0 = unspecified (default value), 1 = manufacturer, 2 = operator, 3 = third party

¹Must be specified when the object is created.²Must be specified when the object is created. Must be non-empty if CKA_URL is empty.

³Must be non-empty if CKA_VALUE is empty.

⁴Can only be empty if CKA_URL is empty.

Only the CKA_ID, CKA_ISSUER, and CKA_SERIAL_NUMBER attributes may be modified after the object is created.

The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not). (Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity.)

It is intended in the interests of interoperability that the subject name and key identifier for a certificate will be the same as those for the corresponding public and private keys (though it is not required that all be stored in the same token). However, Cryptoki does not enforce this association, or even the uniqueness of the key identifier for a given subject; in particular, an application may leave the key identifier empty.

The CKA_ISSUER and CKA_SERIAL_NUMBER attributes are for compatibility with PKCS #7 and Privacy Enhanced Mail (RFC1421). Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki.

The CKA_URL attribute enables the support for storage of the URL where the certificate can be found instead of the certificate itself. Storage of a URL instead of the complete certificate is often used in mobile environments.

The CKA_HASH_OF_SUBJECT_PUBLIC_KEY and CKA_HASH_OF_ISSUER_PUBLIC_KEY attributes are used to store the hashes of the public keys of the subject and the issuer. They are particularly important when only the URL is available to be able to correlate a certificate with a private key and when searching for the certificate of the issuer.

The CKA_JAVA_MIDP_SECURITY_DOMAIN attribute associates a certificate with a Java MIDP security domain.

The following is a sample template for creating an X.509 certificate object:

CK_OBJECT_CLASS class = CKO_CERTIFICATE;

CK_CERTIFICATE_TYPE certType = CKC_X_509;

CK_UTF8CHAR label[] = "A certificate object";

CK_BYTE subject[] = {... };

CK_BYTE id[] = { 123 };

CK_BYTE certificate[] = {... };

CK_BBOOL true = CK_TRUE;

CK_ATTRIBUTE template[] = {

    {CKA_CLASS, &class, sizeof(class)}

    {CKA_CERTIFICATE_TYPE, &certType, sizeof(certType)};

    CKA_TOKEN, &true, sizeof(true)}

, {

    CKA_LABEL, label, sizeof(label) - 1}

, {

    CKA_SUBJECT, subject, sizeof(subject)}

, {

    CKA_ID, id, sizeof(id)}

, {

    CKA_VALUE, certificate, sizeof(certificate)}

};

kmip message