OASIS Key Management Interoperability Protocol (KMIP) TC

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. In v1.0 of KMIP we have four attributes which are specifically related to certificates: Certificate Type, Certificate Identifier, Certificate Subject and Certificate Issuer. In addition there are other attributes such as Digest, Cryptographic Algorithm, Cryptographic Length and Cryptographic Parameters which are also specified in v1.0 as applying to certificates. Leaving the Cryptographic Algorithm, Cryptographic Length and Cryptographic Parameters attributes aside for the moment let's look at the type of queries we can make using the Locate operation to find certificates with any of the five other attributes: * Using Certificate Type one could ask for all X.509 or all PGP certificates which are available. * Using Certificate Identifier you can locate a specific certificate. * Using Certificate Issuer you can find all the certificates that were issued by a specific CA. This would be useful if the CA was compromised and your trying find all the affected certificates. * Certificate Subject can be used to find all certificate which are associated with a specific entity (aka the subject of the certificate). * Digest could be used to find a specific certificate with a specified digest (aka fingerprint). You can also do more complex searches by specifying multiple attributes in the Locate command. This way you can pare down the list of results. Examples include: * You can combine Certificate Type with Certificate Subject to find all the X.509 or PGP certificates belong to a specific entity. * You could combine Certificate Subject and Certificate Issuer to find all the certificates issued by a specific CA to a specific entity. For the v1.1 specification we were looking to clarify the confusion associated with what the Cryptographic Algorithm, Cryptographic Length and Cryptographic Parameters attributes mean in the context of certificates. The Digital Signature Algorithm proposal which I submitted added a new attribute that would be associated with a Certificate (in the future (post v1.1) it may be an attribute used in other KMIP contexts) that would identify the signature alorithm used in signing the certificate. So with this attribute you could now use the Locate operation to find all certificates signed using a specific digital signature algorithm. Or in a compound locate you could find all certificates issued by a specific CA (Certificate Issuer) and signed using a specific algorithm (Digital Signature Algorithm). Now the Digital Signature Algorithm proposal went a step further stating that Cryptographic Algorithm attribute would no longer be associated with Certificates. This was a reasonable approach since Digital Signature Algorithm is a more accurate description of the algorithm associated with the certificate object itself. But if you want to record what algorithm is associated with the Subject Public Key contained in the certificate, dropping this attribute now result in a limitation. We could clarify the specification to state that both the Digital Signature Algorithm and the Cryptographic Algorithm attributes are associated with certificates. The Digital Signature Algorithm attribute would hold the signature algorithm used in signing the certificate (specified in the signature field of the certificate) and the Cryptographic Algorithm attribute would hold the asymmetric algorithm associated with the subject public key (specified in the subjectPublicKeyInfo field of the certificate). With this approach you could then search for all certificates containing subject public keys for a certain algorithm (e.g. RSA) by specifying the Cryptographic Algorithm attribute. I also submitted a proposal that clarified what the Cryptographic Length means in the context of Certificates. This proposal suggested that this attribute contain the length of the certificate itself, but based on the discussion during the call last week there didn't seem to be a great demand for knowing the length of the certificate itself. However there was interest in finding certificate containing subject public keys of a certain length (e.g. find all 1024 bit RSA keys). If this is the case then we could propose that the Cryptographic Length associated with a Certificate contain the length of the subject public key contained in the certificate. This would be in-line with the suggestion in the previous paragraph of having the Cryptographic Algorithm associated with the certificate contain the algorithm of the subject public key contained in the certificate. The question I have for the TC is whether anyone has a strong use case for having an attribute to contain the length of the certificate itself? If there are use cases then we can introduce a new attribute 'Certificate Length' to carry this value. That leaves the Cryptographic Parameters attribute for which no proposal has been submitted. I would suggest that we keep all the 'Cryptographic *' attributes in-line for certificates and specify that the Cryptographic Parameters attribute contain the parameters associated with the Subject Public Key contained in the certificate. I'd be interested in hearing folks opinions on these revised changes to the v1.1 specification prior to redrafting the Digital Signature Algorithm and Certificate Length proposals. Are there other Locate related issues for certificates that we need to consider and are there additional attributes we should associate with certificates? Are there Locate related issues for objects other then certificates that need to be discussed? Judy Judith Furlong Consultant Product Manager EMC Product Security Office RSA , The Security Division of EMC office: +1 508 249 3698 email: Judith.Furlong@emc.com< mailto:Furlong_Judith@emc.com >

Of course, PGP keys make this all the more complex. :) In the PGP world, keys (which would be equivalent to the term "certificate" for the purposes of this thread) can have many IDs (read "subjects") associated with them, each of which may or may not be signed in a verifiable way (i.e. by a key/cert you trust). So, Judy, when you talk about searching for the certificate subject below, in the context of PGP keys, there may be many such IDs associated with one particular cryptographic object. Participants in the PGP universe of keys are typically doing lookups against key servers to find the public keys of recipients for messages (usually emails). I would say that those searches comprise about 95% of all searches done for PGP keys. The rest would be looking up your own key by various attributes, but most often by your own identity. For the purposes of KMIP, having the Locate call by Certificate Subject take only one value is probably sufficient, as most of the time you are only looking up a key for one particular ID (an email address or the like). However the KMIP servers would need to be aware that each key can contain many IDs, and one could argue that the KMIP protocol should also make all these IDs available for clients. The only other way to get at them would be to crack open the PGP key block itself once it was downloaded, which probably isn't ideal. In regards to the Certificate Length versus Cryptographic Length issue, I think it makes perfect sense to have the two be separate values. Knowing that the key represented by this certificate is 1024 bits while the certificate itself is 2943 bytes long makes complete sense. (Of course, the units change in there; if that's not explicitly stated it should be). -= Mike =- On 8/3/11 1:10 PM, "judith.furlong@emc.com" <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. > >In v1.0 of KMIP we have four attributes which are specifically related to >certificates: Certificate Type, Certificate Identifier, Certificate >Subject and Certificate Issuer. In addition there are other attributes >such as Digest, Cryptographic Algorithm, Cryptographic Length and >Cryptographic Parameters which are also specified in v1.0 as applying to >certificates. Leaving the Cryptographic Algorithm, Cryptographic Length >and Cryptographic Parameters attributes aside for the moment let's look >at the type of queries we can make using the Locate operation to find >certificates with any of the five other attributes: >* Using Certificate Type one could ask for all X.509 or all PGP >certificates which are available. >* Using Certificate Identifier you can locate a specific >certificate. >* Using Certificate Issuer you can find all the certificates that >were issued by a specific CA. This would be useful if the CA was >compromised and your trying find all the affected certificates. >* Certificate Subject can be used to find all certificate which are >associated with a specific entity (aka the subject of the certificate). >* Digest could be used to find a specific certificate with a >specified digest (aka fingerprint). >You can also do more complex searches by specifying multiple attributes >in the Locate command. This way you can pare down the list of results. >Examples include: >* You can combine Certificate Type with Certificate Subject to find >all the X.509 or PGP certificates belong to a specific entity. >* You could combine Certificate Subject and Certificate Issuer to >find all the certificates issued by a specific CA to a specific entity. > >For the v1.1 specification we were looking to clarify the confusion >associated with what the Cryptographic Algorithm, Cryptographic Length >and Cryptographic Parameters attributes mean in the context of >certificates. The Digital Signature Algorithm proposal which I submitted >added a new attribute that would be associated with a Certificate (in the >future (post v1.1) it may be an attribute used in other KMIP contexts) >that would identify the signature alorithm used in signing the >certificate. So with this attribute you could now use the Locate >operation to find all certificates signed using a specific digital >signature algorithm. Or in a compound locate you could find all >certificates issued by a specific CA (Certificate Issuer) and signed >using a specific algorithm (Digital Signature Algorithm). > >Now the Digital Signature Algorithm proposal went a step further stating >that Cryptographic Algorithm attribute would no longer be associated with >Certificates. This was a reasonable approach since Digital Signature >Algorithm is a more accurate description of the algorithm associated with >the certificate object itself. But if you want to record what algorithm >is associated with the Subject Public Key contained in the certificate, >dropping this attribute now result in a limitation. We could clarify the >specification to state that both the Digital Signature Algorithm and the >Cryptographic Algorithm attributes are associated with certificates. The >Digital Signature Algorithm attribute would hold the signature algorithm >used in signing the certificate (specified in the signature field of the >certificate) and the Cryptographic Algorithm attribute would hold the >asymmetric algorithm associated with the subject public key (specified in >the subjectPublicKeyInfo field of the certificate). With this approach >you could then search for all certificates containing subject public keys >for a certain algorithm (e.g. RSA) by specifying the Cryptographic >Algorithm attribute. > >I also submitted a proposal that clarified what the Cryptographic Length >means in the context of Certificates. This proposal suggested that this >attribute contain the length of the certificate itself, but based on the >discussion during the call last week there didn't seem to be a great >demand for knowing the length of the certificate itself. However there >was interest in finding certificate containing subject public keys of a >certain length (e.g. find all 1024 bit RSA keys). If this is the case >then we could propose that the Cryptographic Length associated with a >Certificate contain the length of the subject public key contained in the >certificate. This would be in-line with the suggestion in the previous >paragraph of having the Cryptographic Algorithm associated with the >certificate contain the algorithm of the subject public key contained in >the certificate. The question I have for the TC is whether anyone has a >strong use case for having an attribute to contain the length of the >certificate itself? If there are use cases then we can introduce a new >attribute 'Certificate Length' to carry this value. > >That leaves the Cryptographic Parameters attribute for which no proposal >has been submitted. I would suggest that we keep all the 'Cryptographic >*' attributes in-line for certificates and specify that the Cryptographic >Parameters attribute contain the parameters associated with the Subject >Public Key contained in the certificate. > >I'd be interested in hearing folks opinions on these revised changes to >the v1.1 specification prior to redrafting the Digital Signature >Algorithm and Certificate Length proposals. > >Are there other Locate related issues for certificates that we need to >consider and are there additional attributes we should associate with >certificates? > >Are there Locate related issues for objects other then certificates that >need to be discussed? > >Judy > >Judith Furlong Consultant Product Manager EMC Product Security Office > RSA , The Security Division of EMC office: +1 508 249 3698 email: >Judith.Furlong@emc.com< mailto:Furlong_Judith@emc.com > > > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

On 4/08/2011 6:10 AM, judith.furlong@emc.com wrote: 67FA5EE5B93F8547BF3E1214E526B30A7478D627@MX30A.corp.emc.com type= cite > 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 1 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 1 Byte array BER-encoding of the certificate CKA_URL 3 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 4 Byte array SHA-1 hash of the subject public key (default empty) CKA_HASH_OF_ISSUER_PUBLIC_KEY 4 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 1 Must be specified when the object is created. 2 Must be specified when the object is created. Must be non-empty if CKA_URL is empty. 3 Must be non-empty if CKA_VALUE is empty. 4 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)} }; 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.

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 1 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 1 Byte array BER-encoding of the certificate CKA_URL 3 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 4 Byte array SHA-1 hash of the subject public key (default empty) CKA_HASH_OF_ISSUER_PUBLIC_KEY 4 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 1 Must be specified when the object is created. 2 Must be specified when the object is created. Must be non-empty if CKA_URL is empty. 3 Must be non-empty if CKA_VALUE is empty. 4 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)} }; 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.

> I read through the PKCS#11 text again -- you indicated that KMIP was missing the following…. And it is missing - KMIP does not have the DER encoded version of the issuer or serial number. It has the currently unspecified textstring representation. If we define a fixed mandatory mapping for how the textstring representation is provided for Subject, Issuer, and SerialNumber then we will have the equivalent for those items - which is what your recently sent proposal update does. I was commenting on KMIP 1.0 which does not have that text but I see I wasn't clear on that context in my email. There is no current requirement that a KMIP user must store the associated public keys for a certificate and it would be interesting to see views on requiring that there be associated public key objects for each certificate in order to support lookups based on the hash of the public key. Currently Digest is insufficiently specified to be useful for this purpose - as how the digest if formed hasn't been detailed for contexts where the key value isn't in a 'raw' format. See last weeks discussion on the topic - so that item too needs to be sorted out. So I agree there is a path towards being able to handle this in KMIP that seems logical - but it requires further items to be specified. Tim.